Inspect one exact public URL across response and rendered evidence, isolate the first missing dependency or content element, and repair that failure before considering an architecture change.
Compare the HTML response with the page a crawler renders before deciding JavaScript is your SEO problem. Inspect one exact URL, its essential content and its dependencies. A working page in your logged-in browser is useful evidence, but it is not the same observation as a crawler’s public render.
This guide addresses the rendering investigation. For sitemap retrieval, canonical signals and the wider reasons a page may be excluded, use the page-indexing diagnosis. Do not rebuild an application to solve a problem you have not yet located.
Write down what must be visible
Choose a representative content page, not only the homepage. For a fictional resource library, the chosen guide needs its title, explanatory paragraphs, category and links to the next useful resources. A loading spinner, empty article container or navigation shell is not an equivalent result.
Create a short expected-content sheet using distinctive text from those elements. Include the exact public URL and the time of the test. Keep the production URL separate from a local route, authenticated preview or staging address; each can return different output.
Also decide what may remain interactive. A calculator can require input without every possible result becoming an indexable page. The editorial explanation and useful navigation surrounding it should not disappear merely because the visitor has not operated the calculator.
Understand the three stages without inventing a deadline
Google describes crawling, rendering and indexing as distinct processing stages and confirms that Search runs JavaScript. A response containing only an application shell can require execution before the main content appears. Blocked pages or required files cannot be rendered through that blocked route.
This does not mean every JavaScript site is invisible or that a server-rendered page is guaranteed to be indexed. Nor is there one reliable waiting period after which every new script-dependent page has been processed. First establish whether the relevant content can be produced at all.
Keep the stages separate in your report: the address was retrieved; essential content appeared in rendered output; Google’s recorded state shows a particular indexing result. Combining those into a single “SEO passed” checkbox conceals the question that remains unanswered.
Inspect the initial response as its own artifact
Open the exact public address without an account session and examine the main document’s response, redirect destination and source. Search the response for the expected text. This identifies what the server supplied before the browser’s application code changed the document.
If the title and article are present in the response, do not assume a blank view with scripts disabled proves they were absent. CSS, client initialization or an overlay may affect visibility. Conversely, text visible in your final browser view may have arrived through a later request rather than the initial document.
For the fictional library, record “article absent from initial response, present after application data request” if that is what you observe. This is a dependency description, not yet a failure verdict. The next question is whether the relevant rendering environment can complete that dependency.
Use Google’s rendered output to test the hypothesis
Google’s troubleshooting guide identifies URL Inspection and the Rich Results Test as routes to examine rendered DOM, loaded resources and JavaScript errors. Use the supported tool appropriate to a public URL and your authorized property access.
Compare the rendered HTML with your expected-content sheet. Do not stop at a screenshot thumbnail: a similar-looking page can omit the article’s lower sections or useful links. Record the content actually present, alongside any essential resource that failed.
Keep a current live test separate from Google’s last recorded crawl and indexed data. If the recorded observation predates a deployment, it cannot demonstrate that the repair has already been processed. A successful current render supports a narrower conclusion: this test produced the expected content at this time.
Trace a missing section to its first failed dependency
| Observation | Next evidence to inspect |
|---|---|
| Application shell only | Main script availability, execution errors and the data request that supplies the article. |
| Title present, body missing | The component’s loading condition, content response and any required interaction. |
| Logged-in browser works, public render fails | Session-dependent data, access checks and public deployment behavior. |
| Current browser works, test uses old output | Deployed asset versions, response caching and whether the evidence refers to the same release. |
| Content present, destination links absent | The actual rendered anchor markup and route addresses. |
One console warning does not necessarily explain an absent article. Start with the earliest relevant error or failed dependency and connect it to the missing element. A blocked analytics request is a different concern from an unavailable content API.
Do not expose private data endpoints or disable a whole firewall to clear a diagnostic. Public editorial content should have an intentional public delivery path. If a cross-origin request fails in the browser, use the separate CORS investigation to inspect its actual permission and response.
Remove interaction gates from essential discoverable content
Google’s lazy-loading guidance says not to rely on user actions such as clicking or scrolling to expose content to Search. Verify the crawler-rendered result instead of assuming an interaction that worked for you will occur there.
In the fictional library, “Show the explanation” should not be the only way to retrieve the explanation when it is the page’s core answer. Serve that answer in an accessible initial or rendered state. Keep optional interactive controls for the work they add, rather than making them a gate in front of the article.
For a long collection, inspect representative later items too. Distinguish content already in the rendered document from content fetched only after an interaction. If separate resource pages are valuable, give them real addresses and useful links rather than depending on one endless panel.
Inspect links and direct routes together
Google’s link guidance favors anchor elements with href addresses and descriptive text. JavaScript can add such anchors; a clickable-looking element is not equivalent merely because a person can activate it.
This simple example expresses a destination directly. The address is fictional and should be replaced with the intended public route.
<a href="/guides/image-delivery/">Choose image sizes for your page</a>Then open that destination directly in a fresh tab and refresh it. A route that works only after navigating from the homepage may depend on client state or an incomplete server fallback. Check a valid page and a genuinely missing page; an identical successful shell for both needs deliberate error handling.
Choose a proportionate repair and preserve the comparison
Google treats bot-specific dynamic rendering as a workaround, rather than a preferred long-term architecture. Consider the site’s actual content and maintenance needs before choosing server rendering, static generation or another supported approach. A framework migration is a substantial change, not a shortcut to a ranking promise.
Retest the same expected-content sheet after the correction. Check the public response, rendered text, real links and direct-route behavior, then compare with the saved failing evidence. If those pass, monitor later crawl and indexing separately.
The useful delivery is an explained rendering path and a scoped repair. “Google cannot see JavaScript” is too broad to guide a fix; “the public guide’s data request fails, leaving its article empty in rendered output” identifies a problem someone can actually resolve.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- Google Search Central: JavaScript SEO basicsChecked Crawling, rendering and indexing stages; JavaScript processing; blocked resources; meaningful HTTP responses; server or pre-rendering considerations.
Limits: The guidance does not promise a fixed rendering delay, indexing, ranking or identical processing by every crawler. - Google Search Central: Fix Search-related JavaScript problemsChecked Inspection of rendered DOM, resources, console output and exceptions with Google's supported testing tools.
Limits: A current test is not a substitute for the last indexed snapshot and cannot establish every indexing condition. - Google Search Central: Fix lazy-loaded contentChecked Making essential lazy-loaded content visible to rendering without requiring user interactions such as scrolling or clicking.
Limits: The developer must still verify the exact component and relevant rendered output; lazy loading itself is not categorically prohibited. - Google Search Central: Link best practicesChecked Crawlable anchor elements with href and descriptive text, including links inserted by JavaScript.
Limits: Link discoverability does not guarantee the destination will be crawled or indexed. - Google Search Central: Dynamic rendering as a workaroundChecked Bot-specific dynamic rendering is a workaround rather than a recommended long-term solution; server/static rendering and hydration are alternatives.
Limits: An architectural label alone does not demonstrate correct content, deployment behavior, indexing or improved rankings.