Study first
Review the ideas behind the questions
Review JavaScript pages the way a crawler and a user would experience them. Check whether important content, links, status handling, canonical signals, and fallback behavior still work after scripts run.
Test What Search Can Render
Google Search can run JavaScript, but JavaScript pages still need checks. The rendered page should expose the important content and should not depend on unsupported state or user permissions.
- JavaScript issues can block a page or specific content from appearing in Google Search.
- The Rich Results Test and URL Inspection can show rendered DOM, loaded resources, console output, and JavaScript exceptions.
- Features that require user permission should have a way to access content without forcing the permission prompt.
In Practice
Inspect the rendered page
Do not stop at the source HTML when content is loaded by scripts. Check the rendered output and errors for the exact URL.
Plan permission-free access
If the useful content appears only after camera, location, or similar permission, crawlers and some users may not reach it.
Common mistakes
Assuming that source HTML is enough when JavaScript fills the page later.
Use rendering diagnostics to confirm the important content appears in the rendered DOM.
Q&A
Which view should an SEO check for JavaScript-loaded content?
Check the rendered DOM and rendering errors, not just the original source HTML.
Can a page require a camera permission before showing its main content to Googlebot?
No. The page needs a way to access the content without forcing that permission.
Keep URLs And Errors Crawlable
Single-page apps can hide SEO problems when URLs, links, and error states are handled only in the browser. Search needs stable URLs and error behavior that matches what users see.
- Single-page apps should not use URL fragments to load different content; use the History API for different URL views.
- A single-page app that returns a 200 status for missing content can let error pages be indexed.
- Web Rendering Service clears local storage, session storage, and cookies across page loads.
In Practice
Use real URL states
If a route matters for search, it should have a stable URL path that can load the right content directly.
Do not hide missing pages behind 200 responses
A missing product or article should not look like a normal successful page to crawlers.
Common mistakes
Using `#/products` as the only URL pattern for indexable product views.
Use normal URL paths with History API behavior for views that should be discoverable.
Q&A
Why is a 200 status risky on a missing JavaScript route?
Search may treat the error view as a normal page and index it.
Avoid Conflicting Page Signals
JavaScript can add canonical and robots tags, but the final page should still send one clear signal. Conflicts created after rendering can be harder to spot than normal template mistakes.
- If JavaScript injects rel="canonical", it should be the only canonical link tag on the page.
- JavaScript can add or change a robots meta tag, including noindex when an API call shows no content.
- Dynamic rendering is a workaround, not Google's recommended long-term solution.
In Practice
Check the final head output
A page can look fine to users while scripts create duplicate canonical tags. Inspect the rendered head before launch.
Prefer durable rendering fixes
If crawler access is unreliable, plan server-side rendering, static rendering, or hydration before treating dynamic rendering as the main architecture.
Common mistakes
Adding dynamic rendering as the default fix for every JavaScript page.
Treat dynamic rendering as a workaround and review server-side rendering, static rendering, or hydration for a long-term fix.
Q&A
What is the risk of two rendered canonical tags?
Conflicting or multiple canonical tags can lead to unexpected results.