What is JavaScript SEO?
JavaScript SEO is the work of making sure search engines can see what your JavaScript produces. If your content, links, titles, or structured data are inserted by scripts in the browser rather than present in the HTML the server sends, a crawler has to run that JavaScript to see them. Google can, with delays and limits. Many other crawlers do not run JavaScript at all.
The safest pattern is simple: put anything that matters for search in the initial HTML response, and use JavaScript to add interactivity on top.
How Google processes JavaScript
Google describes three phases:
- Crawling. Googlebot fetches the URL and reads the raw HTML, including any links in it.
- Rendering. The page is queued for the Web Rendering Service, which runs an up-to-date version of Chromium, executes the JavaScript, and builds the final page.
- Indexing. Google indexes the rendered result.
Rendering can happen soon after crawling or later, depending on resources. If a page's content only exists after rendering, it is indexed only after that step. Google also does not click buttons, scroll, or accept cookie prompts, so content that appears only after an interaction may never be seen.
What commonly breaks
- Links that are not links. Google follows
<a href="/path">elements. It does not followonclickhandlers or<span>elements styled to look like links. - Content behind interaction. Tabs are fine if the text is in the DOM on load. Content fetched only when a tab is clicked is not.
- Blocked resources. If robots.txt blocks the scripts or API endpoints a page needs, rendering fails.
- Metadata set late. Titles, canonicals, and
noindextags changed by JavaScript are applied at render time. Anoindexin the raw HTML can stop Google from rendering at all, so a script that removes it later has no effect. - Soft errors. Single-page apps often return
200for missing pages and show a "not found" message in the browser, which creates soft 404s. - Fragment URLs. Routes such as
/#/productsare not treated as separate pages.
How to test
Use Search Console's URL Inspection tool and choose View tested page to see the rendered HTML and a screenshot as Google saw it. Compare that with the raw source (view-source: in your browser). Anything present in the rendered view but missing from the source depends on JavaScript. The JSON-LD validator is useful for checking structured data that scripts inject.
In WordPress
Classic WordPress themes render pages on the server in PHP, so most content is in the HTML from the start. JavaScript SEO issues show up with headless WordPress front ends, page builders that load content by script, and plugins that fetch lists or reviews with AJAX. Hydrogen SEO prints titles, canonicals, robots meta, and JSON-LD in the server-rendered <head>, so those signals do not depend on rendering. See server-side rendering for the broader picture.
Common questions
Can Google index JavaScript content?
Yes. Google renders pages with a current version of Chromium. The catch is that rendering can be delayed, and content that needs clicks, scrolling, or blocked resources may be missed.
Do other search engines and AI crawlers run JavaScript?
Support varies and is often limited. Content in the initial HTML is readable by every crawler, which is why server rendering is the safer default.
Is dynamic rendering still recommended?
No. Google now describes dynamic rendering, serving bots a prerendered version, as a workaround rather than a long-term solution, and points to server-side rendering or static rendering instead.