You can rebuild WordPress menus from archived website evidence when the captures show usable labels, destinations and relationships. Recreate those relationships in the new site’s navigation system, then test the published links. An archived menu is a reference for what visitors saw, not a recovery of the original WordPress menu database or theme settings.
Start with a navigation inventory rather than a screenshot imitation. A header can look correct while sending visitors to an archive address, an unpublished page or an unrelated replacement. The job is to preserve useful routes and supported hierarchy without making uncertain destinations appear complete.
Collect the navigation evidence before rebuilding it
Review the homepage and representative inner pages from the intended period. Record the main navigation, footer links and any section-specific menu. Where archived interaction works, inspect the dropdowns rather than assuming that every visible top-level label was a link.
Keep the original destination beside each label. Also note where you observed it and the capture date. A later capture might show a renamed service or a different site structure. Do not silently combine both menus into a supposedly exact historical version.
Mobile navigation needs a separate check. The old site may have collapsed the same items, shortened labels or used a different arrangement. If the archive does not demonstrate the mobile behaviour, mark it unknown and have the owner approve a usable responsive interpretation. Do not describe a newly designed mobile menu as a recovered original.
The archive-to-WordPress conversion guide explains the wider rebuild. This article focuses on the navigation record and its acceptance checks, not the complete page-conversion process.
Separate menu hierarchy from page hierarchy
A submenu describes how a visitor finds a destination. It does not necessarily establish a WordPress page’s parent, its URL path or its content type. A category, external link or standalone page can all appear beneath the same menu heading.
For example, an item labelled “Services” may expand to several links without opening a Services page itself. Treat that as an observed navigation relationship. Do not create an empty page or change the children’s existing paths simply to reproduce the indentation in a menu editor.
Use this original blank record for each item:
- Position and label: header, footer or section menu, displayed text and order.
- Observed relationship: top level, child item or non-link grouping label.
- Original destination: the evidenced URL, including any path or fragment.
- Source: capture reference and date, with any uncertainty.
- Approved live destination: the published replacement or retained URL, not an archive replay address.
- Decision and test: preserve, revise or hold, with the owner’s decision and verification result.
This is a planning format, not a completed restoration case. It keeps three questions separate: what the old site showed, what the new site should provide, and what has actually been verified.
Resolve missing destinations before adding visible links
A captured link can establish that a page was referenced without preserving that page’s contents. Check the destination independently. A navigation label alone is not enough evidence to invent a recovered page.
For a missing destination, agree one of three outcomes: reconstruct it from sufficient authorized sources, use an appropriate owner-approved alternative, or leave it out of the published menu until it is ready. Keep the historical reference in the project record even when it is not a live link.
Do not route every lost link to the homepage. That hides the distinction between a restored destination and an unresolved gap. Changes to an established URL or redirect need their own review; a menu rebuild is not a reason to rename existing published pages.
Check external destinations too. Confirm that the intended organization and resource still match the link. A familiar old domain can now point somewhere different. Preserve a useful external reference only after the owner confirms that it remains appropriate.
Use the navigation system the rebuilt site actually has
WordPress does not expose the same menu interface on every theme. Its Appearance Menus documentation distinguishes classic or hybrid theme menus from navigation managed by block themes. Check the installed theme and supported interface before following instructions from an older screenshot.
Where Appearance > Menus is available, rebuild the approved items, order and nesting, then assign the menu to the supported theme location. A saved menu without the correct location can exist in the dashboard without appearing in the intended header or footer.
For block-based navigation, use the Navigation block guidance appropriate to the installed WordPress version. Check which menu the header or footer displays. An automatic page list is not the same as a deliberately selected historical menu; verify whether newly published pages would be added automatically.
A builder or custom theme may have additional display rules. Identify the actual header, footer and mobile component rather than editing an unused menu. Do this in a review environment first, and avoid theme-file changes merely to make an old tutorial’s screen appear.
Test the menu as a visitor, not only in the editor
Open the rendered site without an administrator session. Test each navigation area on desktop and a narrow viewport. Check the labels, order, submenu relationships and destinations against the approved record.
Include keyboard and touch checks. The W3C fly-out menu guidance explains why dropdowns need interaction beyond pointer hovering. Confirm visible keyboard focus, usable opening controls and access to every child link. If a parent is both a destination and a submenu controller, check that the two actions are understandable and reachable.
Follow each link and record the requested and final address. Confirm the intended content appears, not just a successful response. Where a fragment points to a section, check that the section exists. Where a page is preserved at its original URL, ensure the menu does not use a temporary staging address.
Finally, verify that the active item corresponds to the current destination and that a mobile overlay can be closed without trapping the visitor. A menu that works with a mouse but hides its links from keyboard or touch users is not ready for handover.
Define what the owner will be able to change
Demonstrate one agreed task, such as editing a navigation label or moving a submenu item, in the delivered site. Record which interface controls it. Menu editing and full-page layout editing are separate capabilities.
Our Simple WordPress restoration scope is intended for straightforward archive HTML conversion with limited customization; technical editing may be needed for HTML-based layouts. Do not assume that rebuilding a menu makes every page a visual-builder layout. Match the delivery method to the owner’s actual editing needs before work begins.
Two common menu-recovery questions
Can a menu label tell me the old page’s exact URL?
Not by itself. Inspect the evidenced link destination and verify it against other authorized sources. Similar labels can point to different addresses, and a grouping label may not have been a link at all.
Does deleting a menu item delete the underlying page?
Removing a navigation item is different from deleting its destination. WordPress’s navigation documentation treats menu-item management separately from content. Still check the actual action and interface before saving, particularly when a builder combines navigation and page controls.
