JavaScript SEO checks whether a search engine can discover a page, retrieve its resources and understand the content produced by the application. For a Next.js site, start with representative routes and the actual production output. A framework choice, a green build or a screenshot alone cannot establish that an important landing page is discoverable and indexed.
The useful outcome is a short list of observed problems with affected URLs, evidence and a proposed fix. Keep performance, rendering and indexing questions separate: they can interact, but they require different checks.
Start with the page and the intended search journey
Choose a service page, a CMS article and a dynamic detail route that matter to the business. Record their expected title, main heading, body content and internal links. Include a missing route, because the behaviour of unavailable content is part of the search experience.
A fictional consultancy might expect its CRM service page to show a description, a contact route and links to relevant work. Use those expectations to inspect the delivered page. This example describes a test plan, not a result from a client project.
Compare the response with the rendered page
Inspect the HTTP response, the HTML sent by the server and the document after browser rendering. Note which important content appears at each stage. If the response contains an application shell while the browser later loads the main copy, investigate the data request, its availability and any access restrictions.
Google can render JavaScript, but its rendering process and resource access still matter. A JavaScript-disabled browser is a useful comparison, not a complete simulation of Googlebot. Use Google's JavaScript SEO guidance to frame the investigation, then confirm the affected URL with appropriate Search Console inspection evidence.
Check metadata on each route
Verify the title, description and canonical URL for each selected page. A canonical expresses a preferred URL for a set of similar pages; it should match an intentional content decision. Check for inherited defaults, missing CMS values and metadata that appears only after a request has failed.
Next.js provides static metadata, generated metadata and file conventions. Their use depends on the router and version. Consult the official metadata documentation and inspect the installed version before changing implementation code. Test the deployed route and its actual configuration as well as the local build.
Make important links discoverable
A user should be able to follow a relevant service or article link directly. Inspect the final anchor and its destination, including links produced from CMS content. A button that changes application state may be appropriate for an interaction, while navigation to another public page needs a dependable link.
Google's link guidance explains the role of anchors and destinations. Use descriptive text that explains the next page. Check that navigation still points to the intended URL after filters, consent choices or loading errors.
Test loading, missing and failed content states
| State | Check | Why it matters |
|---|---|---|
| Existing public page | Expected content and metadata are available | A successful response should represent the intended page |
| Content loading | The primary route can recover and expose useful content | An unresolved shell can conceal the page's purpose |
| Missing item | A meaningful not-found response and navigation | Unavailable content should not masquerade as a valid detail page |
| CMS failure | Documented fallback or failure behaviour | A temporary outage should not silently change the page's identity |
Use a safe environment for failure tests. Do not make production content unavailable merely to reproduce a theoretical problem. Record what was simulated and what remains untested.
Separate rendering from indexability
A page can render correctly and still carry a noindex instruction, use an unexpected canonical or be inaccessible to a crawler. Review status codes, robots controls and the inspected URL's indexability together. A live test demonstrates what was retrieved at that time; it does not guarantee future indexing or ranking.
Search Console's indexed state may describe an earlier crawl. Keep the inspection date with the evidence, and distinguish the live result from the indexed result before drawing a conclusion.
Turn findings into a bounded change
For each issue, keep the URL, reproduction steps, expected output, observed output and proposed acceptance test. For example, a missing article title might require a CMS fallback and a route test. It does not automatically justify changing the application's entire rendering strategy.
After a fix, repeat the same route checks, including a missing item and the relevant navigation. Use the existing Core Web Vitals guide for the separate performance investigation. Search progress should then be reviewed using comparable final GSC periods and verified enquiry tracking.
Scope a technical SEO investigation
Bring representative URLs, the Next.js version, hosting setup, CMS behaviour and any Search Console findings to a technical SEO discussion. The brief should identify which user and search journeys are affected. That makes the work reviewable without promising a specific ranking increase.
