A site built in Angular, React or Next.js can rank perfectly well.
The problems usually start when the site looks fine in a browser but Google is seeing something different.
That might mean links it can’t follow, content that only appears after scripts run, every route sharing the same title, bad status codes, or canonicals changing between the raw and rendered page.
Most of it is straightforward to check once you know where to look.
This is the checklist I use when I’m reviewing a JavaScript site with a development team.
I’m not a front-end developer. My job is to work out what needs to be true for search, explain what’s wrong, and check the fix once your team has built it.
What Google actually does with a JavaScript page
Google doesn’t just load the page the way you do in Chrome and call it done.
It first crawls the HTML it receives, then renders the page, then uses the rendered result for indexing.
That distinction matters.
If your important content, links or metadata only appear after JavaScript runs, you’re relying on that rendering step working properly.
Google explains the process in its JavaScript SEO basics.
For me, the practical point is simpler: don’t just ask whether the page works in a browser. Check what Google actually receives and renders.
Do you need server-side rendering?
Not always.
Google can index client-side rendered sites, and plenty rank well.
But if your framework gives you the option to render important pages on the server or generate them statically, I’d usually prefer that over making everything depend on client-side JavaScript.
It removes one more thing that can go wrong.
It can also make life easier for other crawlers, not just Google. Different crawlers handle JavaScript differently, so if a page matters commercially, having the useful content available without relying entirely on scripts is generally the safer setup.
That doesn’t mean “SSR everything”.
It means don’t make the important parts of the site harder to read than they need to be.
The checks I’d make first
Most JavaScript SEO issues I see fall into a fairly small number of buckets.
| Check | What I’m looking for | How I’d test it |
|---|---|---|
| Links | Navigation or internal links built with click handlers instead of proper links | Inspect the rendered HTML and crawl with JavaScript rendering enabled |
| Main content | Important text missing until scripts run or an interaction happens | Compare raw HTML with the rendered page |
| Titles and descriptions | Duplicate, missing or script-dependent metadata | Check a sample of rendered pages |
| Status codes | Missing pages returning 200 instead of 404 | Request a made-up URL and check the response |
| Canonicals | Raw and rendered canonicals disagreeing | Compare both versions |
| URLs | Hash routes or routes that don’t behave like normal URLs | Check the routing setup and crawlability |
| Robots and noindex | Indexing rules changing after scripts run | Check what Google receives before and after rendering |
| Sitemap | Missing, broken or listing non-indexable URLs | Check the sitemap directly and compare it with live pages |
None of those is especially exotic.
The reason they cause trouble is that the site can still look completely normal to a visitor.
Soft 404s are a common one
This comes up a lot on single-page applications.
You request a URL that doesn’t exist, but instead of returning a real 404, the app loads the normal shell with a 200 status.
To a user, that might just look like an error page.
To Google, it can look like a valid URL with no useful content.
That creates soft 404s and wastes crawl time.
The fix depends on the setup, but the important thing is that a missing page should behave like a missing page.
How I check what Google sees
I normally start by comparing three versions of the same page:
- what the server sends
- what the browser renders
- what Google sees in Search Console
Pick an important page and open the source.
Then inspect the rendered version.
Then use URL Inspection in Search Console and compare again.
I’m looking for differences in:
- main content
- internal links
- title and description
- canonical
- robots directives
If something important is only present in one version, I want to know why.
I’ll also request a nonsense URL to check the status code, then look through Search Console for soft 404s, crawled-but-not-indexed pages and anything else that suggests the rendering or routing setup isn’t behaving as expected.
A real example from a headless migration
I saw a good example of this during a headless Shopify migration for Kwiat.
The new site used Shopify Hydrogen with Sanity for content.
Nothing looked obviously broken to a visitor, but the technical checks after launch found several things that needed attention.
The sitemap returned a 404.
Some education pages had very little useful content in the initial HTML.
Old category URLs were still resolving.
Some canonicals were wrong.
And collection titles were being generated automatically rather than set properly.
Because content lived in more than one system, the sitemap also needed to pull from both.
I wrote the specification for the development team: a sitemap index with separate sitemaps for products, collections and editorial content, listing only live, indexable URLs.
They built it, and I checked it once it was live.
That’s the part I think gets missed with headless builds.
The site can be finished from a design and development point of view while still being unfinished for search.
The full example is in the Kwiat migration case study.
Headless doesn’t mean bad for SEO
I don’t think headless or JavaScript-heavy sites are inherently bad for search.
They just make some basics less automatic.
A conventional theme may handle things like titles, canonicals, sitemaps and 404 behaviour without anyone thinking too much about them.
With a custom build, those things often need to be specified deliberately.
That means someone needs to check:
- what is in the HTML
- what appears after rendering
- how routes behave
- how metadata is generated
- whether the sitemap is complete
- whether old URLs still resolve
- whether Google can actually see the content you expect it to see
That’s why I prefer being involved before launch rather than being brought in afterwards.
It’s much easier to fix a broken sitemap or routing issue in staging than after Google has already started crawling the new site.
The short version
If you’re building with Angular, React, Next.js or another JavaScript framework, I’d make sure of six things before launch:
- Google can follow the internal links
- the important content appears in the rendered HTML
- every page has the right title, description and canonical
- missing pages return the right status
- the sitemap lists the right URLs
- Search Console shows Google seeing roughly what you expect it to see
If those are right, the framework itself usually isn’t the problem.
If you’re planning a new build or migration, I can review the staging site before launch and give your developers a prioritised list of anything that needs fixing.
My technical SEO audit and site migration work cover that, and the SEO for software development companies page explains how I work with development teams. If you’re choosing someone to help, how to choose an SEO specialist for a software company sets out what to ask. You can also request a free assessment or get in touch.
FAQ
Is JavaScript bad for SEO?
No. Google can crawl, render and index JavaScript pages, and plenty of them rank well. The risk is relying on content or links that only appear after scripts run, because indexing then depends on rendering working. Rendering important pages on the server, or generating them statically, removes some of that risk.
Do React, Angular and Next.js need server-side rendering?
Not strictly. Client-side rendered sites can be indexed, but server-side rendering or static generation removes a dependency, and it helps crawlers that handle JavaScript differently from Google. I’d use it for the pages that matter commercially rather than rebuilding everything around it.
How do I check whether Google can see my JavaScript content?
Compare the raw HTML, the rendered page and what the URL Inspection tool in Search Console shows. If something important is missing from the rendered version, Google may not be able to index it. Then check what a made-up URL returns, and look for soft 404s in Search Console.
Why does my single-page app have soft 404s?
Usually because a URL that doesn’t exist loads the normal page with a 200 status. Make missing pages return a real 404, redirect them to a URL that does, or add a noindex tag to error pages. Which suits depends on your setup, so test what a made-up address returns first.
When should SEO be involved in a JavaScript build?
Before launch. A review of the staging site can catch a missing sitemap, duplicate titles, wrong canonicals and content that only renders in the browser while they’re still cheap to fix. After launch the same checks still work, but you’re fixing a live site.
Sources
- JavaScript SEO basics, Google Search Central, last updated 4 March 2026, accessed 21 October 2026. Supports: the crawl, render and index phases, links, titles and descriptions, canonicals, status codes and soft 404s, and testing with the URL Inspection tool.
- Paul Myers, Kwiat headless Shopify migration, 2026 (published client case study). Supports: the sitemap, rendering, redirect, canonical and metadata findings.
