We lost two afternoons to menu changes before we fixed how we do them
A client asked us to add one link to their main navigation. Same link, six of their sites. It should have been a ten minute job. It was not, and the reason it was not is the same reason it goes wrong for everybody else.
The short version
We look after more than 30 WordPress sites. A menu change on six of them turned into an afternoon, then a second afternoon two weeks later when we found out one of the edits had been silently thrown away and another pointed at a page somebody had unpublished. The tedious part was never the typing. It was the logging in, and the fact that nothing tells you when a menu edit has gone wrong. The ten minute check further down will tell you whether your own sites have the same problem.
It is never actually one menu
The request was one line in an email. Add a Care plans link to the main navigation, between Services and About. Six sites, same client, same link.
Here is what that job really is. Open the password manager. Find the first site. Log in. Wait for wp-admin. Appearance, then Menus. Work out which of the four menus in the dropdown is the one the header actually uses, because two of them are called Main and Main Menu and one has not been touched since 2021. Add the item. Drag it up seven rows, past the point where the browser starts auto-scrolling and overshoots. Save. Check the front end. Then do it five more times.
That is forty minutes of nothing. No judgement, no skill, no decision. And because it is forty minutes of nothing, it is the job that gets put off, done at the end of the day, or handed to whoever is free, which is where the second afternoon comes from.
The four ways a menu change actually goes wrong
None of these are exotic. They are the ordinary failures, and what they have in common is that the menu editor tells you nothing when they happen.
1. Somebody else’s edit vanishes and nobody is told
This is the one that cost us the second afternoon. WordPress does not save menu items individually. It saves the whole menu as one object. So if you open the menu screen, get pulled into a call, and somebody else edits that menu while your screen is sitting open, your save overwrites everything they did.
It does not warn you. It does not warn them. The menu looks completely normal afterwards, it is just missing the thing that was added an hour ago. We only found ours because the client asked why the link they had approved was gone again.
2. The link that points at a page somebody unpublished
A menu entry keeps pointing at a page after that page is moved back to draft, trashed or deleted. The entry still looks completely normal in the menu editor. On the live site it returns a 404.
Nobody on your team clicks their own navigation. The person who finds it is a visitor, or the client, and by then it has been broken for a fortnight.
3. The theme update that quietly clears the menu location
A menu has to be assigned to a theme location before the theme will render it. Theme and page builder updates can clear that assignment, and menu locations resetting is the most commonly reported problem after a major theme update.
The menu still exists, with every item intact. The theme just has nothing assigned to its header slot, so the navigation disappears from the front end and the menu screen looks perfectly healthy. On block themes the same thing happens differently: an update replaces the Navigation block in the header template.
4. You did fix it, and the site is showing you an old copy
The menu saved, the change is correct, and the front end still shows the old navigation. That is cache, and there are usually three of them: the browser, a caching plugin, and a CDN. Clear them in that order.
The variant that wastes the most time is when the menu is right everywhere except one page, usually the homepage. That page is on a different template, with its own header, pointing at a different menu. You have been editing the correct menu. It is just not the one that page uses.
The ten minute check for your own sites
Pick your three busiest client sites and do this. It takes about three minutes each and it is the fastest way to find out whether you have been carrying any of the above without knowing.
- Open the live site, not wp-admin. Click every item in the main navigation, including the ones nested under a dropdown. You are looking for a 404 or a redirect you did not expect.
- Check the footer menu too. Almost nobody does, which is exactly why broken links live there longest.
- Open Appearance, then Menus, then Manage Locations. Every location the theme registers should have a menu assigned. A blank one is a menu that is not rendering anywhere.
- Count the menus in the dropdown. If there are more menus than locations, work out which are live and rename the rest with a clear prefix so the next person does not guess.
- Load the homepage and one interior page side by side. If the navigation differs, that is the different template problem, not a caching problem.
If three sites come back clean, you are probably fine. If two of three have something, it is worth doing the whole portfolio, because the causes are not site specific.
What we changed
We could have written a checklist and stuck it in the team handbook. We tried that first. It did not survive a busy week, because the problem was never that people did not know the steps. It was that the steps were tedious enough to postpone.
So we built menu editing into the dashboard we already had open. Menu management in WPCentrify edits the navigation on any connected site without opening wp-admin at all. The six site job is now six edits in one tab, and the specific failures above are handled rather than left to be noticed:
- If the menu changed after you opened it, the save is refused and you are told, instead of quietly overwriting somebody
- A row whose target has been drafted, binned or deleted says so, before a visitor finds the 404
- Theme locations are set from the same screen, so a cleared assignment is visible rather than mysterious
- Nothing is written to the site until you press Save, and Discard puts it back exactly as it was
The honest summary of the gain is not that editing a menu got clever. It is that it stopped being a job you have to psych yourself up for.
What this does not fix
Worth saying plainly, because two of these caught us out afterwards.
The overwrite protection tells you that the menu changed. It does not merge the two versions and it is not version history. You reload and reapply your change, which is a far better outcome than losing it, but it is not magic.
Caching is still caching. If a CDN is holding an old page, no menu editor anywhere can help with that, and the fix is the same three step purge as always.
And none of this decides what should be in the navigation. A menu with fourteen top level items is a content problem, and moving it into a nicer editor just gives you a tidier list of fourteen things nobody can scan.
Frequently asked questions
Most often the menu did save and something is serving an older copy of the page. Clear the browser cache, purge any caching plugin, then the CDN, in that order, and check again. If the menu is correct everywhere except one template, that template is probably using a different header with a different menu assigned to it, which is common on the homepage.
Usually the menu still exists but its theme location was cleared, so the theme has nothing to render. Open Appearance then Menus then Manage Locations and reassign it. A plugin or theme conflict can also hide a menu with CSS, and on block themes an update can replace the Navigation block in the header template.
In stock WordPress you log into each site and repeat the edit, which is where the time goes and where mistakes creep in. A management platform that edits menus centrally does it from one place. WPCentrify does this from the dashboard you already use for updates and backups.
WordPress saves a menu as a whole, so the last save wins and the earlier person's work is discarded silently. Nothing warns either of you. This is the failure that is hardest to spot, because the menu looks fine, it is just missing something somebody added an hour ago.
Check every menu entry against the current status of the page it points at. An entry pointing at a page that was moved back to draft, trashed or deleted still looks normal in the menu editor and returns a 404 for visitors. Doing this by hand across a portfolio is the part nobody keeps up with.
Stop opening wp-admin to move a link
Edit the navigation on every WordPress site you manage from one dashboard, with the checks that catch a broken entry or a clashing edit before your client does.
Free during early access. No credit card required.