How to test JavaScript pages for search before launch
A practical way to check whether important content, links and search signals survive the journey from server response to rendered page.
Written by Rob KnottA page can look complete in a browser while its initial response contains little more than an application shell. That does not automatically make it invisible to Google: Google can render JavaScript. It does mean a visual sign-off is too narrow for a search-critical release.
The useful question is what a crawler can fetch, render and discover without a logged-in session or a human click. Test that journey on representative pages before launch, then repeat the checks on the public site.
Choose pages that expose the real risk
Test a small set of URLs across the templates that matter: a category, a detail page, an article, a paginated or filtered view where relevant, and a URL that should not exist. Include a page whose content comes from an API and one reached through internal navigation. The goal is to find template-level failures, not to collect a reassuring screenshot of the homepage.
For each URL, record the expected title, primary content, canonical URL, indexability and links to the next useful pages. This gives the test a clear pass condition before anyone inspects the result.
Compare the server response with the rendered page
Fetch the URL as an HTTP response and inspect its status, HTML and robots directives. Then inspect the rendered HTML with Search Console URL Inspection or Google’s Rich Results Test. Google describes crawling, rendering and indexing as separate stages; content absent from the first response may still appear after rendering, but a failed script or unavailable resource can leave the rendered result incomplete.
Look for the actual page heading and useful body text, not just a loading message. Check whether essential data requests complete without cookies, local storage or user permission. If the rendered result differs, inspect blocked resources, console errors and the network requests needed to build the page. Prefer making essential content available in server-rendered or pre-rendered HTML when that fits the product, while testing the public output either way.
Follow the links a crawler can follow
A navigation item that responds only to a click is not necessarily a discoverable link. Google advises using an HTML anchor with an href for links it should crawl, including links inserted by JavaScript. Test the rendered DOM and follow those href values to confirm that they resolve to real, useful URLs.
For client-side routes, use distinct paths rather than URL fragments to represent different pages. Check a direct request to a deep URL as well as a journey from the homepage; both should reach the same intended content. A sitemap can support discovery, but it does not repair broken internal navigation.
Check metadata and error states as part of the template
Inspect the title, meta description, canonical link and robots directive in both the response and rendered HTML. Google recommends keeping a canonical set in JavaScript consistent with the one in the original HTML; conflicting canonicals can create an ambiguous signal. An initial noindex is particularly risky because Google may skip rendering before JavaScript removes it.
Now request a non-existent detail URL. A single-page app may return HTTP 200 for an error screen, creating a soft-404 problem. Give missing pages a meaningful server status where possible, or implement one of Google’s documented error-page approaches. Do not assume the visual “not found” message is enough.
Turn the test into release criteria
Write down what passed, what failed and who owns each fix. A useful acceptance check names the URL and template, the expected response, the required rendered content and links, and the tool used to observe them. Retest the corrected URL rather than closing an issue because a code change was merged.
Run the same sample against the live deployment. Search Console’s live inspection helps diagnose how Google sees a URL, but a successful test is not a promise of indexing or ranking. The release decision should be based on whether important content and paths are accessible and consistent, with any remaining limitations made explicit.
Key takeaways
- Test representative templates and a missing URL, not only the homepage.
- Compare the HTTP response with the rendered HTML and investigate missing content.
- Use real anchor links and check direct access to deep URLs.
- Validate canonicals, robots directives and meaningful error states.
- Retest the public deployment against written acceptance criteria.
Sources and further reading
About Rob Knott
Rob is an independent SEO and AI-search consultant with experience spanning LinkedIn, technical SEO and search leadership at MoreNiche. He helps teams turn difficult questions into clear decisions, practical plans and measurable next steps.
Available remotely for AI-search and GEO strategy, visibility baselines, website migrations, technical investigations, content planning and automation. Bring Rob in for a focused project, fractional support or ongoing strategic advice.
