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

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:

1. Starting point: the page and viewport used for the test.

2. Expected path: the control, menu option, and service page you intend to reach.

3. Observed behavior: the first step that differs from that path.

4. Reproduction details: device or browser, taps or key presses, and whether the behavior repeats.

5. 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.

You can verify what appeared on the page during that submission. You cannot use the message alone to verify that the inquiry appeared where your business expects to receive it, or that a later reply reached the visitor. In one Shopify community report, a poster described submissions that appeared to succeed but did not arrive by email. That is an individual report, not a measure of how often this happens or an explanation of its cause.

For an existing website, I’d test the inquiry path as three separate checkpoints: on-screen confirmation, business receipt, and reply. The third checkpoint applies only if a reply is part of the workflow you want to test. This approach makes the test more useful than relying on the confirmation message alone, while keeping its conclusions narrow.

Specify what each checkpoint means on your site

Before sending anything, write down the destination you intend to check. “The business received it” is too vague for a test if nobody has agreed on where to look.

Your intended destination might be an email address or a dashboard, depending on how your own site is set up. Name the specific location you expect to use, then have someone with access check that location. Finding a message somewhere else would be a different observation, not a substitute for the check you planned.

Treat “not checked” as its own state. If nobody has looked at the intended destination, you do not yet have a receipt result. Likewise, a reply cannot be marked “not received” until you know whether one was sent and have checked the test visitor address.

Run one traceable test

Use a test inquiry that you can distinguish from other messages. For example, put a marker such as FORM-TEST-APR15-A in the message. The marker is a hypothetical example; its exact text does not matter. Use a visitor-side address you can access, and identify the inquiry as a test.

Follow the path in order:

1. Submit through the live form. Record the marker, submission time, and exact on-screen result. If the result is unclear, write “unclear” rather than assuming the submission succeeded.

2. Check the intended business destination. Look for the same marker and record the location checked. Distinguish “matching inquiry found,” “matching inquiry not found where checked,” and “destination not yet checked.”

3. Test a reply only if the workflow calls for one. If someone sends a reply through the usual process, record that action. Then check the visitor-side address and record whether the reply was received.

A compact record keeps observations from turning into guesses:

Test marker: [unique marker]
Visitor-side address: [address used for this test]
Submitted at: [time]
On-screen result: [success / other result / unclear]
Intended business destination: [specific location]
Destination checked by: [person / not yet checked]
Matching inquiry at destination: [found / not found / not yet checked]
Reply expected for this test: [yes / no]
Reply sent: [yes / no / not applicable / not yet checked]
Reply received at visitor address: [yes / no / not applicable / not yet checked]

This is an observation log, not a claim about the system’s internals. Its value is that someone reviewing the test can tell which steps were actually checked. It also gives people who handle different parts of the inquiry a common marker to look for.

Interpret the observations without skipping a step

Consider a hypothetical test in which the page shows success, but the person checking the intended business destination cannot find the marked inquiry. Record exactly that: success shown; matching inquiry not found at the location checked. The next step is to investigate that mismatch using whatever settings or records are available for your site. The observation alone does not identify a cause, and it should not be rewritten as a claim that the message disappeared everywhere.

Now consider a different result: the marked inquiry is found, but no one has tried to reply. The receipt checkpoint has been checked; the reply checkpoint has not. Calling the whole path “verified” would erase that distinction. If a reply is sent but is not found at the visitor-side address, record those two observations separately as well.

Finally, suppose the confirmation appeared, the matching inquiry was found, and an expected reply was received. You have observed a complete path for that test inquiry. Keep the result tied to its marker and time rather than treating it as a guarantee about every future submission.

This is why the order matters. Starting with a general question such as “Does our form work?” invites one yes-or-no answer to cover several different checks. Starting with a marked submission gives you a smaller, answerable set of questions: What did the visitor see? Where did the inquiry appear? If a reply was expected, did it reach the test visitor?

Make the next check depend on the missing observation

If the business destination has not been checked, ask someone with access to check it before drawing a conclusion about receipt. If the inquiry is found there, decide whether a reply test is relevant to the workflow. If it is not found where checked, retain the marker, time, and named destination for further investigation. These are different next actions because the recorded states are different.

The practical mistake to avoid is promoting the first checkpoint into proof of the others. Let the success message stand for what you saw on the page. Then use a marked inquiry to check receipt, and, when appropriate, an actual reply to check the final step.

A few seconds later, you have a homepage. Nice headline. Services section. CTA. Decent copy. At that point, it is very tempting to think: “Okay. The hard part is done.” It wasn’t. The hard part started when I stopped asking AI to generate a page and started asking it to generate an entire website that a real business could actually use. That changed everything. A homepage is easy LLMs are very good at producing something that looks convincing once. Give them a prompt and they can generate:

• a hero section

• service descriptions

• an About section

• testimonials

• FAQs

• calls to action For a demo, this is enough. For a real website, it is nowhere near enough. A website needs consistency across multiple pages. The navigation has to make sense. The copy cannot contradict itself. The layout needs to survive mobile screens. Buttons need to point somewhere real. Sections cannot randomly disappear. The business name cannot change halfway through the site. And the AI should probably not invent a phone number. That last one happened more often than I expected. Problem #1: The AI had no idea what the website actually was My first approach was basically: Here is the business.

Generate the website.

The output looked fine. Until I generated another page. Then another. Suddenly the website had three different personalities. The homepage sounded premium. The services page sounded like a discount contractor. The About page sounded like a Fortune 500 company. The model was generating pages independently. That was the mistake. A website is not a collection of unrelated prompts. It needs a shared source of truth. So instead of generating pages immediately, I started generating a structured representation of the business first. Something closer to: { "business": "Austin Roofing Co", "industry": "Roofing", "location": "Austin, Texas", "audience": "Homeowners", "tone": "Professional and local", "services": [ "Roof repair", "Roof replacement", "Storm damage repair" ], "primaryGoal": "Request a quote" }

Every page then uses the same context. This sounds obvious now. It was not obvious in version one. Problem #2: AI loves inventing things Ask an AI to create a business website and it wants to be helpful. Sometimes a little too helpful. It may invent:

• customer testimonials

• awards

• years of experience

• certifications

• addresses

• statistics

• phone numbers A sentence like: “Trusted by 2,000 homeowners since 1998”

looks fantastic on a landing page. There is only one problem. Nobody told the AI that. For a fictional demo, this is harmless. For a real business, it is a serious problem. So I had to start treating certain information differently. There are facts the model can rewrite. There are facts it can infer carefully. And there are facts it should never create. That distinction became one of the most important parts of the system. Problem #3: Good-looking HTML can still be broken This one surprised me. A generated page could look great at 1440px. Then I opened it on mobile. Chaos. Headings wrapping into five lines. Buttons leaving their containers. Images becoming enormous. Two-column layouts refusing to become one column. Text becoming unreadable over backgrounds. The AI had created something that was technically valid and visually broken.

This is where I realized something important: Generating the site and verifying the site are two completely different problems. So I added a separate visual QA step. Instead of trusting the generated result, the system has to inspect what actually rendered. Things like: Does content overflow? Are sections missing? Is text readable? Does the navigation work? Are elements overlapping? Does the page still make sense on mobile?

The AI can say the website is correct. The browser is the final judge. Problem #4: “Regenerate” is not a solution A lot of AI products solve bad output with one button: Generate again. That works surprisingly well in demos. It is also expensive. If generation fails 10% of the time, simply running the whole thing again means:

• more model calls

• more latency

• more compute

• more money

• another chance for something else to break So instead of regenerating everything, I started trying to identify the exact thing that failed. Bad section? Fix the section. Broken page? Rebuild the page. Bad content? Regenerate the content. The goal became: detect -> isolate -> repair

instead of: fail -> regenerate everything -> hope

That one change made the system feel much less like a slot machine. Problem #5: The AI kept being creative when I needed it to be boring This was probably the funniest problem. Creativity sounds great when building with AI. Until you are generating production UI. Sometimes you do not want creativity. You want: Header Hero Services About CTA Footer

That is it. No floating glassmorphism card. No randomly rotated image. No giant quote taking up the whole viewport. No mysterious “Our Philosophy” section for a plumbing company. The model kept trying to impress me. I kept trying to make it behave. Eventually I realized the system needs both freedom and constraints. Too many constraints and every site looks identical. Too much freedom and every generation becomes unpredictable. Finding that middle ground was much harder than writing the prompt. The architecture slowly changed The original idea was basically:

Business description ↓ AI ↓ Website

The real system started looking more like:

Business description ↓ Business understanding ↓ Website structure ↓ Page planning ↓ Content generation ↓ Design generation ↓ Rendering ↓ Visual validation ↓ Repair ↓ Final website

The interesting part is that AI is only one piece of that pipeline. Most of the work is actually about controlling it. The biggest lesson Before building this, I thought the main challenge would be: “Can AI generate a good website?”

It can. That is not the interesting question anymore. The real question is: Can AI generate a good website repeatedly, predictably, and without a human fixing it afterward?

That is a completely different engineering problem. The first impressive result took very little time. The reliable system took much longer. And I suspect this is true for a lot of AI products right now. The demo is easy. The last 20% is the product. I’m still working on this problem while building Instantsite, where the goal is to turn a short business description into a complete editable website. But the thing I find most interesting is not the website generatio

n itself. It is everything required to make unpredictable AI output behave like predictable software. That part is much harder than the demo makes it look. One question If you’re building with generative AI, what was the first thing that worked perfectly in the demo and completely fell apart in production?