Render every public search page with its main answer, descriptive title, canonical URL and crawlable links in the initial HTML whenever possible. Give useful states stable URLs, return truthful HTTP status codes, keep required resources accessible, and test both the response HTML and rendered result after deployment.
This is a technical SEO and web development architecture decision. A JavaScript framework is not inherently unindexable, but an application shell that depends on delayed APIs and client-only routing creates more failure points for crawlers and users.
Google explains that JavaScript pages move through crawling, rendering and indexing, and recommends server-side or pre-rendering because it is faster for users and crawlers and not every bot runs JavaScript Source: Google Search Central.
Classify routes before choosing rendering
Inventory every route and label it public indexable, public non-indexable, private, transactional or temporary. Define the search intent and canonical URL for each indexable template.
Public service, product, category, article and location pages usually need dependable crawlable output. Dashboards, account states, personalised results and internal search combinations usually do not.
Put the main content in the response
Use server-side rendering, static generation or another dependable server response for content that should be discovered and understood. Hydrate interactive behaviour after the useful document exists.
Check the actual HTML returned over HTTP, not only what a browser displays after scripts run. The response should contain the page heading, primary copy, important links and relevant metadata.
Avoid a universal “Loading” shell with a 200 status for every route.
Give every useful state a stable URL
Products, articles and categories need unique, shareable URLs. Use the History API for client-side navigation and preserve full-page navigation when JavaScript is unavailable or fails.
Google recommends avoiding URL fragments to change page content and using the History API for JavaScript state that belongs at a URL Source: Google Search Central.
Prevent session IDs, volatile filters and tracking parameters from multiplying indexable variants.
Use real crawlable links
Navigation should use anchor elements with an href that resolves to the destination. Click handlers on divs, spans or buttons do not provide the same discovery path.
Keep essential routes linked from semantic navigation, category pages, breadcrumbs and contextual content. Do not rely on a user gesture, infinite scroll or site search to reveal every page.
Return meaningful HTTP status codes
Return 200 for a real available page, 301 or 308 for a permanent move, 404 or 410 for missing content, and an appropriate 5xx response for server failure. Authentication should not disguise a private page as a public 200.
Single-page applications commonly create soft 404s by rendering “not found” inside a successful response. Handle missing entities at the server boundary where possible.
Google specifically advises meaningful status codes and documents soft-404 handling for client-rendered applications Source: Google Search Central.
Make metadata deterministic
Generate a unique title, meta description, robots directive, canonical and social metadata from the route's resolved content. Do not ship generic defaults and replace them late after an API call.
Keep the server and client values consistent after hydration. Confirm that error, preview and private routes cannot inherit an indexable template.
Keep canonical signals aligned
Choose the preferred URL for each page and use the same destination in the server response, sitemap, internal links, redirects and structured data. Avoid several canonical tags or a client script that changes the server canonical.
Canonicalisation is not a replacement for controlling duplicate route generation. Remove unnecessary variants and redirect when the alternative has no independent purpose.
Control robots at the response layer
Make required JavaScript, CSS and API content available to crawlers when it is needed to render public pages. Do not block a page in robots.txt and expect its content or noindex instruction to be processed.
Set noindex deliberately on public-but-non-indexable routes that crawlers may fetch. Keep private data behind authentication and authorisation, not merely a robots rule.
Never expose sensitive application state in server-rendered HTML for SEO.
Design lazy loading for discovery
Lazy-load media and secondary interface code, but render or link core content so it does not require scrolling, clicking or browser-only observers to exist. Provide dimensions and meaningful alt text for images.
For pagination, link sequential pages or stable result sets. Infinite scroll can enhance the interface while crawlable URLs preserve discovery.
Test slow and failed API responses. Important text should not silently disappear because a non-critical widget failed.
Generate sitemaps from canonical data
Include indexable canonical URLs that return successful content. Exclude private, redirected, duplicate and error states. Add accurate last-modified values only when the primary content changes.
Split large sitemaps by type where it helps monitoring. A sitemap supports discovery but does not repair a page that returns an empty shell or conflicting canonical.
Add structured data carefully
Generate JSON-LD from the same server-side entity used for visible content. Follow the relevant feature guidelines and test the output. Do not mark up claims or entities absent from the page.
Keep identifiers and URLs stable across releases. Treat structured data errors as deployment regressions for templates that depend on them.
Test three views of every template
Inspect:
- raw HTTP response and status
- browser-rendered DOM with network failures visible
- search-engine rendered output through URL Inspection or appropriate testing tools
Compare content, links, metadata, canonical, robots and structured data. Test representative real records plus missing, redirected and restricted cases.
Run the checks in production-like hosting because edge middleware, cache and environment configuration can change the result.
Monitor server logs and Search Console
Track crawler responses, 5xx errors, redirect chains, soft 404s, excluded URLs, canonical differences and indexed-page trends by template. Correlate shifts with deployments.
Sample important URLs instead of celebrating total indexed count. A smaller set of stable useful pages is better than thousands of parameter variants.
Create alerts for template-wide status or robots changes.
My take: progressive enhancement is an SEO control
My take is that indexable pages should remain understandable when client JavaScript is slow or absent. That constraint improves resilience, accessibility and performance as well as crawling.
Use JavaScript for interaction, not as the only place the public document comes into existence.
Build SEO checks into releases
Add automated tests for expected status, title, canonical, robots, heading and key links on representative routes. Crawl preview deployments and compare URL counts and signal changes.
Require explicit review for routing, rendering, middleware, authentication and data-fetching changes that affect public templates. Keep a rollback path.
Frequently asked questions
Does Google index client-rendered JavaScript?
Google can render JavaScript, but rendering is a separate stage with limitations. Server-render important content for faster, more dependable access and broader crawler support.
Is Next.js automatically SEO-friendly?
No framework guarantees correct output. Rendering mode, route design, metadata, status codes, links, cache and deployment behaviour still need verification.
Should every application route be indexed?
No. Index only public canonical pages that provide useful search answers. Keep private and low-value states protected or non-indexable.
Can a sitemap replace internal links?
No. A sitemap aids discovery, while crawlable internal links also express structure and support user navigation.
Make crawlability an application requirement
If your business needs a rendering and indexability audit, get in touch for technical SEO and web development.
Related guides
For further background, read our rendering and javascript and javascript seo. The javascript seo glossary explains the terminology used in those guides.