A JavaScript page can look complete in a developer’s browser while important content or links fail under other conditions. Before signing off a release, check what the server returns, what appears after rendering and how the page behaves when opened directly. A visual check alone leaves those differences unexplained.
Choose URLs That Exercise the New Behaviour
Select representative pages from each changed template. Include an important commercial page, a deeper page and an address that should return an error. If routing or data loading changed, include pages that use those features.
Open each address directly in a fresh session. Don’t rely only on reaching it through the application’s menu. Compare the result with a journey that begins elsewhere on the site and uses the normal navigation.
Record the expected content before testing. For a service page, that might include the heading, service description, coverage information and enquiry link. Without an agreed expectation, a screenshot can look plausible while an important section is absent.
Compare the Response With the Rendered Page
Inspect the initial HTML and the rendered HTML. Identify which important content depends on JavaScript and confirm that it appears successfully under the tested conditions. Check links and page metadata alongside the visible text.
Google’s JavaScript SEO documentation explains its crawling, rendering and indexing stages. Google runs JavaScript, but rendering has limitations and may be delayed. It won’t render blocked pages or execute JavaScript from blocked files, so browser success doesn’t establish that Google can process the same material.
Ask the developer to investigate missing content before prescribing a framework change. The cause might be a failed request, an interaction dependency or a blocked resource. The appropriate fix depends on the evidence.
Check Indexing Signals Through the Same Journey
Compare the title, canonical URL and robots instructions before and after rendering. Look for conflicting values or a template that retains staging instructions. Google warns that an initial noindex instruction may cause it to skip rendering, so relying on JavaScript to remove that instruction is unsafe.
For a page intended to be indexed, agree the expected signals and verify them on the released version. Keep the result with the tested URL and release identifier so a later investigation can establish what changed.
Test Links and Error Responses Separately
Inspect navigation links rather than judging them only by whether a click works. Google’s crawlable link guidance recommends anchor elements with an href attribute. A script-driven interaction may need changes to expose a usable link.
Request a non-existent address and inspect the server response as well as the displayed page. An error message inside an otherwise successful application response needs review. Agree how genuine missing pages should be handled within the site’s architecture.
Josh Willett’s JavaScript and technical SEO consulting includes comparisons of raw and rendered HTML and implementation review. Bring affected URLs and reproducible differences to that review so it can address the release’s actual risks.
Verify Again on the Live Site
Protected staging environments limit what external search tools can inspect. Record those limits and plan the remaining checks after launch, without weakening staging protection merely to obtain a test result.
Repeat the representative journeys on production. If core content, links or indexing instructions differ from the approved result, give the release owner the evidence and apply the team’s agreed correction or rollback process.
