Modern sites built with React, Vue, Angular or similar frameworks often deliver an almost empty HTML shell and build the page in the browser. Google can render JavaScript, but rendering happens in a second wave that can be delayed, and any script failure can leave content invisible. If a page ranks poorly despite strong content, rendering is one of the first things to check.
Chrome DevTools lets you see the page the way a rendering engine builds it. This guide covers practical checks any SEO can run without writing code.
Step 1: Compare source HTML with rendered HTML
Right-click the page and choose View Page Source. This is the raw HTML the server sent. Now open DevTools and look at the Elements panel, which shows the rendered DOM after JavaScript has run.
Compare the two for the elements that matter:
Title tag and meta description
Canonical tag
Main heading and body copy
Internal links
Structured data
If important content exists only in the Elements panel, it depends on JavaScript. That isn't automatically a problem, but it means indexing relies on Google's renderer succeeding every time.
A fast shortcut: search the page source for a distinctive sentence from your body copy. No match means client-side rendering is injecting it.
Step 2: Disable JavaScript and reload
Open the Command Menu (Ctrl+Shift+P or Cmd+Shift+P), type "Disable JavaScript" and run it. Reload the page.
What remains is your baseline. Ask:
Is the main content still visible?
Do navigation links still appear?
Are product listings, prices or reviews gone?
Pages that go blank without JavaScript carry the highest risk. Consider server-side rendering (SSR), static generation or hybrid rendering for those templates. Remember to re-enable JavaScript afterwards.
Step 3: Check that links are real links
Search engines discover URLs by following elements. Many JavaScript apps navigate using click handlers on
or elements, which crawlers can't follow.In the Elements panel, inspect your menu, pagination and category links. You want:
You don't want an element with only an onclick handler, or an href="#" that depends on script to route. Fragment-only URLs (#/page) are also a problem, because Google generally ignores the fragment.
Step 4: Hunt for blocked and failing resources
Open the Network panel, reload and sort by status. Look for:
Blocked or failed JavaScript and CSS files (4xx or 5xx). If a script that builds content fails, Google sees an incomplete page.
API calls returning errors. If your content comes from an API and it times out or rate-limits, rendering produces blanks.
Resources disallowed in robots.txt. Googlebot needs access to the scripts and styles that render your page. Blocking /js/ or /assets/ can break rendering.
You can also check the Console panel for red errors. A single uncaught exception early in the bundle can stop everything after it from running.
Step 5: Watch for content that needs interaction
Googlebot doesn't click, scroll infinitely or hover. Content that appears only after a user action may never be seen. Test these patterns:
Infinite scroll: provide paginated URLs as a fallback, each with a real href.
"Load more" buttons: make sure the loaded items also exist on crawlable paginated pages.
Tabs and accordions: content present in the DOM but visually hidden is generally fine. Content fetched only on click is not.
Lazy-loaded images: use native loading="lazy" or IntersectionObserver implementations that trigger without scrolling gestures.
Step 6: Throttle to expose timing problems
Rendering budgets are limited. In the Network panel, set throttling to "Slow 4G" and the Performance panel to CPU 4x slowdown, then reload. If content only appears after several seconds, there is risk that a renderer with a timeout will not wait. Reduce bundle sizes, split code and prioritize above-the-fold content.
Step 7: Confirm with Google's own tools
DevTools shows how your browser renders the page, not how Googlebot does. Always cross-check with the URL Inspection tool in Search Console. Use "Test Live URL" and then "View Tested Page" to compare the rendered HTML and screenshot. This catches differences from user-agent handling, blocked resources and rendering timeouts.
Overriding your user agent via Network conditions can reveal servers that deliver different content to bots. Treat this as a diagnostic aid only, since it doesn't replicate Googlebot's infrastructure.
Rendering strategy cheat sheet
Content-heavy, SEO-critical pages (blogs, categories, products): SSR or static generation
Logged-in dashboards: client-side rendering is fine, since they aren't meant to rank
Mixed pages: render core content on the server and hydrate interactive widgets on the client
Conclusion
JavaScript isn't an SEO enemy, but it adds failure points. By comparing source and rendered HTML, disabling scripts, validating links, checking network failures and confirming in Search Console, you can find indexing gaps long before they cost you traffic. Build this checklist into every site launch and migration.
FAQ
Can Google index JavaScript content?
Yes, Google renders JavaScript. But rendering can be delayed, and errors or blocked resources can leave content unindexed.
Is server-side rendering required for SEO?
Not strictly, but it's the most reliable option for important pages and helps performance too.
Why is my content in DevTools but missing in Google?
Common reasons are blocked resources, rendering timeouts, content requiring interaction or failed API calls.
Does DevTools show exactly what Googlebot sees?
No. Use it to diagnose, then verify with the URL Inspection tool.
Are hash URLs bad for SEO?
Generally yes. Google typically ignores the fragment, so use the History API for clean paths.
Top comments (0)