# JavaScript SEO before launch: test direct URLs, not just navigation Source: https://insights.ramfaseo.se/javascript-seo-launch-checks/ Author: Ramin Amirhaeri Published: 2026-10-23T13:06:45+00:00 Updated: 2026-10-23T13:20:15+00:00 Publisher: RamfaSeo Insights. Public article text; menus, forms and visual presentation are omitted. Refer to the original page for full context. You open a new website, click through the menu and everything looks fine. Then you paste a service-page URL into a fresh browser tab and get an empty screen, the wrong language or an error. The navigation test passed. The page did not. This is where I would start a JavaScript SEO launch review: can each important URL stand on its own, without the browsing history that made the demo work? The checklist below is useful for a React or Next.js website, a headless storefront, or any site where JavaScript changes page content and navigation. It is a release review, not a promise that Google will index a page. ## Check three different versions of the same page Google describes [JavaScript processing as crawling, rendering and indexing](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics). That makes the difference between the initial response and the rendered page important. Do not assume that what appears after a successful browser session is what every crawler receives. - The direct HTTP response. Request the exact URL. Record its status, any redirect destination, and the HTML returned before client-side rendering. - The page after JavaScript runs. Check its main content, links, title, canonical and indexing directives in the rendered DOM. - The page reached through internal navigation. Click to the same destination, then compare it with a fresh direct load. Refresh it once and repeat the check. The output need not be byte-for-byte identical. A menu state or a personalised greeting can change. The service being described, the page identity and the destination URL should not depend on how the visitor arrived. ## Use a small set of pages that exposes different failures Checking ten similar landing pages is less useful than checking a few genuinely different routes. For a multilingual service site, I would include: - The homepage and one detailed service page in every published language. - A page with content loaded from a CMS or external service. - The contact page, including its success and error states. - An old URL that should redirect to a specific replacement. - A deliberately nonexistent URL that should return 404. Write the expected outcome beside each URL before testing. “Looks correct” is hard to hand over. “Returns 200, describes the English migration service, has this canonical, and links to these language equivalents” is something another person can check. ## Five release failures worth catching early ### 1. The server returns a shell with no useful content An application shell is not automatically an indexing failure: Google can render JavaScript. But server-rendered or pre-rendered content reduces dependence on that extra step and helps consumers that do not execute it. Google's JavaScript guidance makes this distinction. Check whether the initial HTML contains the page's main explanation and important links. If those appear only after a third-party request, ask what happens when that request is slow or fails. A skeleton loader is not a replacement for the service information a visitor came to read. ### 2. A staging noindex survives the production release Do not rely on JavaScript to remove a noindex directive delivered in the original HTML. Google may skip rendering after seeing it. Inspect both the response headers and the initial markup on the public domain. Keep preview protection separate from production settings so fixing one environment does not expose the other. ### 3. The title changes, but the page identity does not On client-side navigation, a heading can update while an old canonical or description remains. Compare the initial and rendered metadata for the destination, then compare a fresh load. Also look for duplicate canonical elements added by two different parts of the application. The question for the developer is precise: which component owns the metadata, and does it receive the destination's data before the page becomes available? ### 4. Every URL returns a successful response A friendly “page not found” message with a 200 response is not a genuine HTTP 404. Test a made-up URL directly. For an old URL, verify both the redirect response and the final destination; a route that works only after the application has loaded can conceal a server-routing problem. ### 5. Language switching works only after a refresh Switch from English to Persian, then to Swedish, using the site's own controls. Check the destination content, document language, direction, navigation labels and fonts. Repeat by opening each destination directly. A font problem is a user-experience defect; it is not by itself proof of an indexing issue. Still, this comparison can reveal shared state that was not updated when the language changed. Check the page identity separately instead of assuming that fixing the font fixed everything. ## A concrete example from the Ramfa website The [Ramfa SEO website implementation record](https://ramfaseo.se/en/case-studies/ramfa-seo/) documents the first release checks on 22 October 2026: 33 language URLs, HTTP and hreflang checks, a real 404 for unknown routes, and a separate contact-delivery check. It is my own website project, not a client traffic-growth case study. The useful part is the record of what was checked. Those 33 URLs describe that release, not the current size of the website. A later service page or language variant needs to join the check list when it is added. For another project, I would keep one route register with the intended language, canonical destination and equivalent pages. Navigation and sitemap generation can then use the same source instead of maintaining several slightly different lists. ## Confirm Google's view after publication Browser checks describe browser behaviour. For an important public page, use Search Console's URL Inspection tools to inspect the rendered result and compare missing content with your own test. Google's [JavaScript troubleshooting guide](https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript) explains this workflow. A successful live test is not a guarantee of indexing or ranking. Keep the release evidence and the later search observations separate. If the page is absent from search, that distinction prevents a team from repeatedly rewriting a component that already returns the correct content. ## What to include in the release handover Record the URL, the expected outcome, the observed response, the time of the check and the release identifier. Attach a useful screenshot where appearance matters, but preserve the actual response and metadata findings too. Give each failed item an owner and a clear condition for closing it. For help connecting these checks to implementation, see my [technical SEO service](https://ramfaseo.se/en/services/technical-seo/). Speed and layout stability belong in the same release conversation; they are covered under [website performance](https://ramfaseo.se/en/services/website-performance/). If URLs are changing as well, use the separate [migration and redirect checklist](https://insights.ramfaseo.se/wordpress-migration-checklist-a-tested-redirect-map-and-rollback-exercise/) before publishing.