JavaScript SEO for React, Vue and Angular Sites: Is Google Actually Seeing Your Content?

How Google handles JavaScript pages

Google's documentation describes three main phases for JavaScript sites: crawling, rendering and indexing. Googlebot fetches the HTML and reads the links it finds. Pages that return a 200 status are queued for rendering, where a browser-like environment runs the JavaScript, and Google indexes the rendered result. A page can wait in the render queue for a few seconds, and Google says it can take longer.

Three consequences follow, and they explain most of the problems I see:

• What is in the first HTML response is seen first. A client-side app often sends an almost empty shell. Everything of value depends on the render step succeeding.
• The render is not your browser session. Google says its renderer does not keep state across page loads: local storage, session storage and cookies are cleared between them, and it does not make sense to require users to grant permissions. Content that depends on any of these may not appear.
• Googlebot does not interact. It does not click tabs or scroll to trigger loading. Content that appears only after an action is not reliably seen.

That is why the same question appears in my four-question technical SEO framework as question two: can Google understand the page it fetched? For script-heavy sites that is the question that fails most often.

React, Vue and Angular: what actually differs

People ask me which framework is best for SEO. The honest answer is that none of the three decides the outcome. What decides it is how the page is rendered and delivered, and that is a choice you make around the framework.

The "route to crawlable output" column is the real choice. I have deliberately not named specific add-on frameworks here, because they change quickly and any of the main options can work when configured properly. Ask your developers what they plan to use, then verify what the output looks like with the tests below.

Choosing a rendering strategy

Google recommends server-side rendering, static rendering or hydration over dynamic rendering, and notes that not all bots can run JavaScript at all. That second point matters beyond Google. Some other crawlers, including ones used by AI products, may not execute scripts, so a page that only exists after rendering may be invisible to them. The AI Crawler Tester shows what a page returns to a range of crawlers.

My own rule is simple. Anything that should earn search traffic should be readable from the server's HTML response, with scripts adding interactivity on top. Pages that live behind a login can stay client-rendered, and should not be indexed anyway.

The faults I check first

These are the problems I look for on any script-heavy site, whichever framework it uses.

• Links that are not links. Google can reliably find links that are <a> elements with an href. A menu item that is a div or button with a click handler gives a crawler nothing to follow.
• Hash-based routing. URLs like /#/pricing do not identify separate pages for Google. Google's guidance is to use the History API so every view has a real URL, and says the old AJAX-crawling scheme is deprecated.
• Pages that always return 200. A single-page app that shows "not found" but sends a 200 creates soft 404s. Google's suggested fixes are to redirect to a URL that returns a real 404, or to add a noindex tag to the error view. The redirect guide covers which status codes and redirects to use in each case.
• Metadata that does not change per route. Every indexable route needs its own title, description and canonical in the rendered HTML. Check that they update when you move between routes, not only on first load.
• noindex and canonical set by script. Google says it may skip rendering when it sees noindex, so a script cannot reliably remove a noindex that is in the original HTML. It also says a canonical changed by JavaScript is allowed but not recommended, and should never differ from the one in the original HTML. Keep both in the server response.
• Content that needs an interaction. Text hidden behind tabs that only fetch on click, or "load more" buttons with no URL, may never be indexed. For lazy loading, Google says to load content when it enters the viewport, without relying on scrolling or clicking, and not to lazy-load primary content on interaction.
• Infinite scroll without URLs. Each chunk needs its own persistent, linkable URL, such as ?page=2, with the address updated using the History API.
• Blocked resources and endpoints. Google can only fetch what robots.txt allows. If the API that supplies your content, or a script a page needs, is disallowed, the rendered page can come out empty. The URL Inspection tool lists resources that could not be loaded, and the robots.txt guide covers what robots rules can and cannot do.
• Features the renderer lacks. Google says Googlebot does not support WebGL, WebSockets or WebRTC, so give a fallback for anything essential to the content.
• Stale cached scripts. Google says it caches aggressively and may ignore caching headers, so put a version fingerprint in script and style file names.

How I test what Google really sees

1. View the raw response. Fetch the URL without running scripts, using view-source or a command-line request. This is what Googlebot reads first. Note which of your key content, links, title and canonical are already there.
2. Run the live test in URL Inspection. Search Console renders the URL as Google would. Open the rendered HTML and check that the main content, internal links, title, meta description and canonical are present. The Rich Results Test shows the same rendered HTML for any public URL.
3. Check the screenshot and console messages. A blank or half-built screenshot, a list of resources that could not be loaded, or JavaScript errors point straight at the cause.
4. Compare raw and rendered. Anything that appears only in the rendered version depends on the render step. For content that matters, move it into the server response.
5. Test every template. Check one product, one category, one article and one error page. A fault in a template repeats on every page that uses it, which is also how a single release can wipe out traffic.
6. Confirm status codes. Request a URL that does not exist and make sure the response is a 404. The HTTP Status Code Checker will do it in bulk.
7. Confirm in the index. After launch, the Page indexing report and the URL Inspection tool's indexed version show whether Google kept what you intended.

I use the Website Technology Checker early in an audit to see which frameworks and libraries a site runs, and the Meta Tag Checker, Heading Checker and Canonical URL Checker to review the tags on a rendered page.

Performance: bundles, hydration and Core Web Vitals

JavaScript costs users time as well as crawlers. Large bundles delay the moment a page becomes usable, and hydration can add work after the content has already appeared. Google uses Core Web Vitals in its ranking systems, and the good targets, measured at the 75th percentile of real page loads, are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less. Heavy client-side work tends to hurt INP, and late-loading content or images without reserved space tend to hurt CLS.

• Split code by route so a page does not load scripts it does not use.
• Defer scripts that are not needed for the first view.
• Reserve space for images, embeds and late-loading blocks so content does not jump.
• Do not lazy-load the main image or content that is visible when the page opens.

Good scores do not guarantee rankings, and Google is explicit about that, but poor scores make a script-heavy page harder to use. Measure with the Core Web Vitals Checker, which shows real-user data where it is available.

How I approach JavaScript sites

When I audit a site built on one of these frameworks I do not start by asking about the framework. I start by asking what the server sends for each template, and what Google ends up with after rendering. The gap between those two answers is the work. If it is small, I leave the architecture alone and fix the details above. If it is large and the pages need to rank, I recommend moving those templates to server or static rendering and give developers the specific tests that prove it worked.

That fits into a wider technical review. The indexing guide shows what a failed render looks like in Search Console, and the platform guide covers traps on hosted systems. When a redesign changes the rendering approach, treat it as a migration and follow the migration checklist. If you want help, see my technical SEO service.

Frequently asked questions

Can Google index client-side rendered pages?

Yes, Google can render JavaScript and index the result. But it is a separate, queued step that can fail or lag, so important pages are safer when the content is in the server's HTML response.

Do I need server-side rendering?

Not for everything. Pages that must rank, and that change often, benefit most. Static rendering suits pages that rarely change. App screens behind a login do not need either, because they should not be indexed.

Is dynamic rendering still recommended?

No. Google describes it as a workaround and not a recommended solution, and points to server-side rendering, static rendering or hydration instead.

Are hash URLs bad for SEO?

For separate pages, yes. Google's guidance is to use the History API so every view has a real URL, rather than fragment URLs.

How do I see what Google sees?

Use the URL Inspection tool's live test in Search Console and look at the rendered HTML, screenshot and console messages. The Rich Results Test shows the rendered HTML for any public URL.

Does lazy loading hurt SEO?

Not if it is done properly. Content should load when it enters the viewport without needing a click or scroll gesture, and primary content visible on arrival should not be lazy-loaded. Check the rendered HTML to confirm.

Which framework is best for SEO?

None of them, on its own. React, Vue and Angular can all produce pages Google can index when they are rendered on the server or at build time and their links, status codes and metadata are right.

Sources and further reading

Statements about Google in this guide are based on the pages below, checked on 24 October 2026. Frameworks release often, so check your version's documentation for current rendering options.

1. JavaScript SEO basics: crawling, rendering and indexing; links; History API; soft 404s; noindex and canonical with JavaScript
2. Fix Search-related JavaScript problems: rendering limits and debugging with URL Inspection
3. Dynamic rendering as a workaround: a workaround, not a recommended long-term solution
4. Fix lazy-loaded content: lazy loading without user actions; infinite scroll URLs
5. Make your links crawlable: a elements with an href
6. Mobile-first indexing best practices: do not lazy-load primary content on interaction
7. Block Search indexing with noindex: noindex, rendering and robots.txt
8. In-depth guide to how Google Search works: rendering during crawling
9. Introduction to robots.txt: robots.txt controls what crawlers may fetch
10. URL Inspection tool: live test, rendered HTML, screenshot and console messages
11. Rich Results Test: renders a URL and shows the HTML Google received
12. Web Vitals: LCP, INP and CLS thresholds
13. React: server rendering APIs: rendering React components to HTML on the server
14. Vue: Server-Side Rendering guide: SSR and static-site generation for Vue apps
15. Angular: Server and hybrid rendering: built-in server-side rendering and prerendering