The short answer
Test a website page by opening its exact URL in a new tab and refreshing it. A page that works only after navigating from the homepage can fail for shared links, search visitors and crawlers. The server response, page identity and rendered content need to agree on what exists at that address.
The website starts before JavaScript
You approve a new website after clicking through the navigation. Every screen looks correct. Later, you send a product link to a customer. They open it directly and see an error, an empty shell or the homepage.
The demonstration tested one way of arriving. Real visitors have several: search, bookmarks, messages and a browser refresh. A working navigation animation does not prove those entrances work.
The browser journey can hide a broken entrance
A JavaScript application can switch screens after the homepage has loaded. Directly requesting an inner URL asks the hosting system a different question: what should be returned for this address? If that route is not handled correctly, the app can appear complete during a guided tour and fail outside it.
Try the pages customers are likely to share. Open each in a new tab, reload it and check that the expected title, content and navigation appear. Do this on the deployed website, where hosting rules apply, as well as in development.
A worked example
Suppose a supplier's product page opens correctly when selected from the homepage, but its direct URL returns an error from the host.
Where it goes wrong
Approve the site after a click-through demonstration and assume the product can now be shared.
What to do instead
Open the exact product URL in a fresh tab, reload it and verify the public response and page content. Test a missing product address as well.
The check matches how a prospect will arrive from an email or search result. It exposes a route problem before it becomes a failed customer visit.
A page also needs to tell the truth about whether it exists
The server sends a status with its response. A successful page and a missing page should not both pretend to be the same thing. A visible error screen that reports success, or a useful page returned as an error, creates inconsistent signals for systems processing the URL.
Google describes crawling and rendering as connected stages. Rendering may be skipped for non-success responses, and blocked resources can interfere with processing. A good-looking final screen therefore cannot be the only acceptance check; the response behind it matters too.
Make the handover test a real shared link
Ask for one acceptance check that starts with the exact address, without a prior visit to the homepage. Confirm the important content, links, page title and canonical address, then test a deliberately missing route. A canonical is the page's stated preferred address and should match the intended page relationship.
The right implementation depends on the website, but the business outcome is simple: a customer should reach the promised page from a shared link. Record that result for the public release, so a successful local demo is not the final evidence.
Take this into your next conversation
Questions to ask your agency
- Does this exact URL work in a new tab and after refresh?
- Does the public server return the correct status?
- Do the initial and rendered page describe the same content?
- What happens when someone opens a missing route?
Common questions
Is JavaScript itself the problem?
No. The issue is whether the deployed implementation serves and identifies each route correctly. Test the actual behaviour instead of approving or rejecting a site based only on its framework.
Is a screenshot enough for acceptance?
It shows appearance at one moment. It does not establish direct navigation, refresh behaviour or the underlying response. Include those checks in the handover.
Source notes
Platform guidance behind this topic:
From explanation to implementation
This guide is published by NAVIFLARE, a website, CRM and AI workflow practice. Source notes identify the platform guidance; worked examples explain a method rather than claim a client result.
Explore website design and developmentYour next step
Bring one URL that fails when shared or refreshed, and explain the result you expect there. That gives us a concrete starting point for discussing the website's routing and delivery.
Discuss a broken page route
