Debug the Mobile Menu as Four Separate Behaviors
A desktop navigation check cannot tell you whether someone on a phone can reach a service page. Even a visible menu icon answers only the first of several questions. For an existing service-business website, a useful test follows the path: Can the visitor see the menu control, open it, find the relevant service link, and reach the intended page?
Those are separate behaviors, with different places to investigate when one fails. The reports below illustrate why that distinction matters. They are individual reports from Squarespace and WordPress sites, not evidence of how often these problems occur on service-business websites.
Start with the symptom, not the platform
| Check | What to do on a phone | If it fails, inspect |
|---|---|---|
| Visibility | Look for the navigation control at the phone’s viewport width. | Responsive CSS, hidden elements, and elements covered by other content. |
| Opening | Tap the control and observe what happens. | The control’s link destination, event handlers, and any custom code attached to the tap. |
| Options | Inspect the opened menu and expand any submenu needed to find a service. | Menu configuration, submenu state, and whether the submenu can be activated. |
| Destination | Follow the service link. | Its target URL, redirects, and the page that actually loads. |
Record the first failed check. “The mobile menu is broken” is less useful to a developer than “the control is visible, but tapping it navigates away before any options appear.”
1. If the control is absent, inspect the rendered phone view
In one Squarespace discussion, a site owner reported that the menu appeared on desktop but not on phones. A responder identified custom CSS as the cause in that case. That is a reason to inspect CSS when a control is missing, not a reason to assume CSS causes every missing menu.
First, check whether the control exists in the document at the viewport width you are testing. If it does, inspect its computed styles and those of its ancestors. Look for rules affecting display, visibility, opacity, positioning, and overflow. Check which media-query rules apply at that width. Also inspect whether another element covers the control; a control can be present in the layout yet unavailable to tap.
If the control is not in the rendered document, changing its color or stacking order will not fix it. Check how the site’s navigation is configured or rendered before editing styles. Keep the observed symptom and the proposed fix separate in your notes.
2. If a tap goes elsewhere, inspect the control’s action
A different Squarespace owner reported that tapping the mobile menu opened a Connect page instead of displaying menu options. The owner attributed that behavior to custom code. Unlike an absent control, this one had a visible tap target. The reported failure was what the tap did.
To investigate that symptom, identify the exact element receiving the tap. Is it a button intended to toggle a panel, an anchor with a destination, or an element containing both? Inspect its attributes and any attached event handlers. Then reproduce the tap while watching whether the menu changes state or the browser navigates. If custom code is present, examine it as a possible contributor rather than treating the report above as a diagnosis of your own site.
Be precise about the expected behavior. If the design uses a menu button, specify what panel it should open. If the design uses a navigation link, specify where it should lead. A test that checks only whether the element responds to a tap can pass while the visitor still never sees the service options.
3. If the menu opens, test the route through its options
The next failure may be one level deeper. In a WordPress support discussion, a site owner reported that submenu items did not expand on a phone even though they worked on desktop. A responder said the items worked in their own test. The disagreement is important: the report identifies a behavior to check, but it does not establish that the behavior was reproducible for every tester or what caused it.
For your site, list the steps required to reach a specific service page. Does the menu open? Is the service item visible immediately, or is it inside a submenu? If a submenu is required, can you expand it with a tap, and can you select the link afterward? Test the same route with keyboard controls if the navigation is intended to support them. Record the phone, browser, viewport, and sequence of actions when reporting an issue so someone else can try to reproduce the same path.
Do not stop when the submenu looks open. Follow its service link and check the loaded page. Menu state and link destination are different parts of the route.
Turn the checks into a reproducible test
A small test record is more actionable than a screenshot of an icon. For each service route you choose to audit, capture:
Starting point: the page and viewport used for the test.
Expected path: the control, menu option, and service page you intend to reach.
Observed behavior: the first step that differs from that path.
Reproduction details: device or browser, taps or key presses, and whether the behavior repeats.
Relevant implementation: the control element, applicable CSS, menu configuration, or custom code you inspected.
For example, consider this hypothetical test note: “At the tested phone width, the menu button is visible. Tapping it opens the menu. The ‘Services’ item appears, but its submenu does not open when tapped, so this test does not reach the selected service page.” That note narrows the investigation to option expansion without claiming that the menu is invisible or that its destination is wrong.
If you automate the route, make each checkpoint an explicit assertion rather than testing only the final page. Assert that the control is available, that activating it exposes the expected options, that the chosen service link is available, and that following it loads the intended destination. A failed assertion should tell you which step failed. Match selectors and expected destinations to your actual site; the hypothetical labels above are not a universal menu structure.
The practical goal is not to prove that a site has a mobile-navigation problem. It is to give an owner or developer a clean way to verify the complete path to a service page and, if necessary, identify the first step that needs work.
