List the destinations the menu promises
Begin with the pages that should be reachable from the menu: services, products, language editions and contact pages. Record the expected URL for each label. Separate controls that expand a group from links that navigate to a page; an expand button does not need to masquerade as a destination.
Choose representative entry pages and test both desktop and mobile layouts. Menus sometimes use entirely different components at different widths. Also record whether you are logged out and whether a consent choice has been made, because these conditions can change the interface you are actually testing.
Inspect the link markup, not just the animation
Google's guidance recommends anchor elements with href values that resolve to web addresses. JavaScript-generated links can meet that requirement too. A visually convincing label that only invokes a click handler is therefore a different finding from an actual anchor pointing to the intended page.
For each destination, record whether the anchor exists in the initial HTML, in the rendered document before interaction, or only after opening the menu. Save the element and resolved address. This small evidence table helps distinguish missing markup, a wrong URL and a visibility problem instead of grouping all three under a vague JavaScript issue.
Test navigation separately from discovery
Open each menu group and follow a sample destination. Then load that destination directly in a fresh tab and refresh it. A client-side transition that works from the homepage can conceal a server route that fails on direct entry. Record the final address and visible page, not merely whether the click produced an animation.
Repeat the journey with keyboard navigation and at the mobile layout. Check that opening a group does not unexpectedly navigate away and that selecting a page closes or updates the menu sensibly. These interaction checks concern usability; passing them does not replace checking the link markup or establish that a search crawler extracted the destination.
Worked example: a services submenu
Imagine a menu with a Services button that expands a panel containing Website Design and SEO Audit. In this illustrative case, both child labels are spans with click handlers. Clicking works, but inspecting the panel reveals no destination anchors. The actionable finding is the missing link structure, rather than a recommendation to remove JavaScript from the whole site.
Keep the expansion control and implement each destination as an anchor with its real URL, allowing the application to enhance navigation if needed. Retest the panel before and after opening, copy the destination address and load it directly. If the links appear only after interaction, consider rendering the destination links with the menu structure so their availability does not depend on a visitor opening that panel first.
Retain evidence and scope the repair
Save the tested page, viewport, menu state, destination list and relevant markup alongside any console or request errors. If JavaScript is disabled for a diagnostic test, label that condition explicitly. A no-script result is useful for resilience analysis, but it is not a complete simulation of Google's rendering behavior.
After a fix, compare the same destinations and states and add unresolved items to your website-audit action list. Where available, inspect Google's rendered HTML as a separate observation. Distinguish a usable menu, discoverable links, a working destination and an indexed page in your report; none of those findings alone proves all the others.