Technical SEO audit for React websites.

Is React bad for SEO?

No.

React is a frontend tool. The SEO result depends on how the solution is built and served.

Google can render JavaScript, but crawling and rendering can still be affected by heavy bundles, missing resources, client-side errors, API dependencies, incorrect routing and unstable metadata.

Distinguish between the HTTP response, initial HTML, rendered DOM and the crawler’s actual result. A modern React site can be SEO-friendly with correct SSR, SSG, prerendering, metadata, routing and internal linking. Audit output and behaviour — not the framework name.

Before the audit: understand how the React site renders

The rendering strategy determines when the page content becomes HTML.

Client-side rendering — CSR

With pure client-side rendering, the server often sends a relatively small HTML shell. JavaScript is then loaded and builds the page in the browser.

This can work well, but makes SEO more dependent on scripts, API calls and routing. If the main content or metadata only appears after JavaScript, SEO-critical routes should be tested especially thoroughly.

Server-side rendering — SSR

With SSR, HTML is generated on the server for the specific request. This makes route-specific content directly available in the response and can be robust for pages that need to be discovered and understood quickly.

SSR is not automatically best and still requires correct caching, metadata, status codes and error handling.

Static Site Generation — SSG

With SSG, HTML is generated during the build. This suits marketing, service and information pages that do not need to be generated again for every request.

For SEO-critical routes, static output is often easy to inspect because the finished HTML can be validated before deployment.

Prerendering

Prerendering effectively means that route-specific HTML is produced in advance or as part of the build or deployment process, so the user and crawler do not depend on building all the main content client-side.

Hybrid rendering

Many sites combine strategies. Do not only ask “Does the site use SSR?” Ask instead: How is each important page type produced, and is the output robust?

If the wider platform decision is still open, the guide React website vs. WordPress explains the trade-offs between a custom React-based frontend and a CMS-oriented WordPress setup.

Step 1 — check what the server actually sends

This is one of the most important steps.

Open an important page and compare:

• View Source or the raw HTTP response
• the browser’s Elements panel after JavaScript has run

Check at least:

• H1
• important body text
• <title>
• meta description
• canonical
• robots meta
• structured data
• central internal links

You can also retrieve HTML and headers directly:

curl -L https://example.com/service/
curl -I https://example.com/service/

If the page’s main content only exists after JavaScript, that is not automatically an error. But you should investigate whether rendering is stable, whether API calls can fail and whether Google sees the same meaningful page.

For SEO-critical routes, you should be able to explain when the title, main content, links and canonical become available.

Step 2 — check title tags and meta descriptions

Every indexable route should be able to have relevant, route-specific metadata.

Audit:

• missing titles
• the same title on many routes
• generic fallback titles
• route changes where the title does not update
• metadata that only exists in the finished browser DOM
• templates where dynamic data produces empty metadata on failure

SPA routing can create errors if metadata only changes after client navigation. Test both a direct request and internal navigation to the same URL. The result should be consistent.

Google may choose different snippet text, so focus on unique and useful descriptions — not a specific character count.

Step 3 — check canonical URLs

Canonical helps search engines choose a preferred URL among identical or very similar pages. It is a signal, not a replacement for proper URL architecture.

Audit:

• self-referencing canonical on primary pages
• HTTP vs. HTTPS
• www vs. non-www
• trailing slash variants
• query parameters
• duplicate routes
• canonical pointing to a redirect
• canonical pointing to a noindex page
• canonical pointing to the wrong route

On client-rendered sites, canonical should be unambiguous. Avoid setups where source and JavaScript specify different canonicals, and compare the user-declared canonical with the Google-selected canonical in Search Console.

Step 4 — check robots meta and robots.txt

The two mechanisms serve different purposes.

robots.txt

robots.txt controls which URLs or resources a crawler may retrieve.

robots meta

A robots meta tag on the page itself can, for example, signal noindex.

The important nuance is that a crawler can only read the page’s meta tag if it is allowed to retrieve the page. If a URL is blocked in robots.txt, you cannot rely on a noindex on the page being seen.

Audit:

• unintended noindex
• staging rules that have reached production
• blocking JavaScript or other resources needed for rendering
• old crawl blocks
• legitimate private or utility paths

noindex is not automatically an error. Login, checkout, internal search pages and other utility routes may correctly be noindex depending on the site.

Step 5 — check the XML sitemap

A sitemap should primarily list the canonical URLs that the business actually wants in search results.

Audit for:

• 3xx URLs
• 404 URLs
• noindex URLs
• duplicates
• URLs that canonicalise to other pages
• old deleted routes
• incorrect domain or protocol variants
• missing dynamic routes
• new pages that never appear

On a React site with route data in code, a CMS or an API, you need to know where the sitemap generator gets its URLs from. A sitemap does not replace internal linking.

Step 6 — check status codes and routing

Status codes are a classic problem in client-side apps.

A React router can show a polished “Page not found” component while the server still responds:

HTTP/1.1 200 OK

That creates a soft 404 risk. If the URL genuinely does not exist, the server or hosting layer should be able to return a correct 404 status.

Audit:

• existing pages -> 200
• permanent moves -> typically 301 or 308
• temporary redirects -> the relevant 3xx status
• non-existent pages -> 404
• server errors -> the correct 5xx status
• redirect chains
• redirect loops

Check redirects with curl -I or a crawler. Client-side redirects should not replace correct HTTP redirects for URL migrations.

Step 7 — check internal links

Internal links support discovery, information architecture, context and user flow.

Google can crawl ordinary links most reliably, such as:

<a href="/en/services/technical-seo/">Technical SEO</a>

Audit:

• <a href=""> on elements that function as links
• click handlers on div, span or buttons that actually navigate
• orphan pages
• broken links
• links through unnecessary redirects
• navigation
• breadcrumbs
• contextual links
• descriptive anchor text

React Router, Next.js and other routers can handle navigation perfectly well, but the resulting markup should still be a real link when the element is semantically a link.

Step 8 — separate crawlability from indexability

The concepts are often mixed together.

Crawlability: Can the crawler retrieve the URL and necessary resources?

Indexability: May and can the page be included in the index as a candidate for search results?

A URL may, for example:

• be crawled but have noindex
• be discovered but have very weak internal linking
• be crawled without being indexed
• be a duplicate where another canonical is selected
• be blocked from crawling and therefore not evaluated normally

An audit should first define which URL types the business actually wants indexed. Otherwise, correct exclusions risk being treated as errors.

Step 9 — use Google Search Console correctly

Search Console supplements crawler data with Google’s own assessment.

URL Inspection

For an important route, check:

• whether the URL is indexed
• crawl status
• user-declared canonical
• Google-selected canonical
• last crawl
• live test
• rendered HTML or screenshot where relevant

Use the live test after fixes; aggregated reports can take longer to update.

Page indexing

Look especially for patterns such as:

• Crawled — currently not indexed
• Discovered — currently not indexed
• Alternate page with proper canonical
• Page with redirect
• Soft 404
• Excluded by noindex

Not every non-indexed URL is an error. Prioritise based on the question:

Is this a URL we actually want in Google?

Step 10 — structured data / schema

Structured data can describe entities and page types and make pages eligible for relevant rich results.

On a B2B site, relevant types may include:

• Organization
• BreadcrumbList
• Article
• other types that genuinely fit the page’s visible content

Audit:

• whether JSON-LD can be parsed
• whether the data matches the visible content
• whether URLs are correct
• whether the markup is route-specific
• whether schema disappears after client-side navigation
• whether deployment changes the output

Avoid fake ratings, invented reviews or markup for content the user cannot see.

Valid schema does not guarantee a rich result. Its primary purpose is correct, truthful and maintainable markup.

Step 11 — Core Web Vitals and performance

The central Core Web Vitals are:

• LCP — loading performance
• INP — responsiveness during interaction
• CLS — visual stability

Practical “good” thresholds are LCP <= 2.5 seconds, INP <= 200 ms and CLS <= 0.1 at the 75th percentile of actual visits.

React projects can be especially affected by:

• large JavaScript bundles
• hydration
• heavy dependencies
• animation libraries
• third-party scripts
• large hero images
• client-side data fetching
• fonts

React is not automatically slow. The issue is the amount of work the browser needs to perform and when it happens.

Use PageSpeed Insights for field data and lab diagnostics. Lighthouse is useful for troubleshooting, but one lab run is not the same as real user data.

Step 12 — JavaScript bundle and code splitting

Too much JavaScript can affect downloading, parsing, execution and especially responsiveness.

Audit:

• bundle size
• route-based code splitting
• lazy loading
• unnecessary dependencies
• duplicate libraries
• third-party scripts
• components that load large packages without using them in the first view

An “unused JavaScript” finding does not mean the entire file can be deleted; the code may be needed later or on other routes. Use the finding as a starting point for developer analysis.

Step 13 — audit images

Images affect performance, layout and understanding.

Check:

• appropriate dimensions
• responsive images
• modern formats where they make sense
• width and height
• lazy loading
• the LCP image
• alt text
• decorative images with empty alt text
• stable image URLs

The LCP image should normally not be lazy-loaded in a way that delays the most important content.

Alt text should describe relevant images for accessibility and context. It should not be used as a hidden keyword list.

Step 14 — heading structure and semantic HTML

SEO does not require a magical number of headings. A logical structure helps users, assistive technologies and search engines understand the content.

Audit:

• a clear main heading
• logical H2/H3 levels
• <main>
• <article> where relevant
• navigation
• header/footer
• buttons vs. links
• form labels

A button should perform an action. A link should lead to a URL. React components should not erase basic semantics.

Step 15 — dynamic routes

React sites often have routes such as:

/projects/:slug
/products/:id

For each dynamic page type, audit:

• can all important URLs be discovered?
• are they included in the sitemap?
• can the server or build generate them?
• do they have route-specific title and description?
• is the canonical correct?
• do invalid slugs return 404?
• are crawlable internal links present?
• is prerendering or build output complete?

A typical problem is that the app can display any slug while the sitemap, metadata or 404 logic does not follow along.

Step 16 — client-side data fetching

A route may return an HTML shell and then retrieve the main content from an API.

This is not automatically wrong. But audit what happens if:

• the API responds slowly
• the API fails
• data is missing
• the crawler’s rendering does not get the same result
• metadata depends on data that arrives later
• a user opens the route URL directly

For SEO-critical content, server-side fetching or build-time generation may be more robust because the main content and metadata exist earlier in the request flow.

If the underlying problem is that several systems need to exchange data, read API integrations explained for businesses before treating the issue as a frontend SEO problem.

Step 17 — JavaScript errors

A runtime error can be serious if navigation or main content depends on JavaScript.

Audit the browser’s console and network panel for:

• uncaught errors
• failed network requests
• hydration errors
• API failures
• chunk loading errors
• third-party script errors

Test both a direct landing and internal navigation; some errors only occur in one flow.

Step 18 — duplicate content and URL variants

Check whether the same content can be opened through several variants:

• www / non-www
• HTTP / HTTPS
• trailing slash / no trailing slash
• uppercase / lowercase
• query parameters
• filter URLs
• old routes

Use redirects, canonical and consistent internal links as needed. The goal is to make the preferred URL clear.

Step 19 — mobile experience

Google uses the mobile version of content for mobile-first indexing.

Therefore audit:

• the same central content on mobile and desktop
• responsive layout
• navigation
• touch targets
• overlays
• images
• loading
• performance
• metadata and structured data if the site serves different versions

On responsive React sites, conditionally loaded components can still create differences between mobile and desktop.

Step 20 — accessibility and SEO overlap

Accessibility is not an SEO hack, but several technical practices overlap.

This includes:

• semantic HTML
• crawlable and understandable links
• logical headings
• relevant alt text
• form labels
• meaningful navigation
• clear content hierarchy

Note accessibility issues when they also affect structure or functionality.

A concrete audit workflow

A practical audit can be carried out in this order:

1. Crawl the entire site

Export URL, status code, title, description, canonical, H1, indexability and internal links.

2. Select representative routes

Choose, for example, the homepage, a service page, an article, a dynamic route, a 404 and a route with API data.

3. Check HTTP and initial HTML

Use View Source, curl or server/build output. Note what exists before browser JavaScript.

4. Compare with the rendered DOM

Check whether central elements change, disappear or only appear after API calls.

5. Check Search Console

Investigate important URLs with URL Inspection and look for patterns in Page indexing.

6. Check sitemap, robots and canonical

Compare the crawler’s URL list with the sitemap and the desired information architecture.

7. Audit internal linking

Find orphan pages, click-handler navigation and unnecessary redirect links.

8. Test performance

Use PageSpeed Insights, Lighthouse and the browser’s Performance and Network tools.

9. Check structured data

Validate syntax and compare the markup with the visible content.

10. Prioritise and implement

Group findings by impact and risk. Fix critical indexing and routing errors before cosmetic notices.

11. Validate again in production

Crawl the deployed version, check status codes and HTML output, and test the most important URLs again.

Prioritise errors by impact — not quantity

An audit tool can find many notices. They are not equally important.

Critical

Examples:

• important pages are unintentionally noindex
• important routes cannot render the main content
• a central page returns the wrong status
• canonical points away from an important page
• production blocks the crawler

High

Examples:

• important routes lack route-specific metadata
• central pages are orphaned
• 404 routes consistently return 200
• serious LCP or INP problems on central templates
• dynamic money pages are missing from the sitemap or build

Medium

Examples:

• individual redirect links
• descriptions that should be improved
• schema opportunities
• minor inconsistency in headings or internal anchors

Low

Examples:

• cosmetic tool notices with no real effect
• “missing” schema that is not relevant
• intentional noindex routes
• small optimisations with no effect on important pages

The goal is not an SEO health score of 100.

The goal is a website where the pages that matter are crawlable, indexable, relevant, understandable and fast enough for the actual user experience.

Common false positives in audit tools

A tool may flag something as an issue even though it is intentional.

Examples:

• noindex on login or utility routes
• redirects that intentionally consolidate old URLs
• missing description on a page that should not be indexed
• schema that does not make sense for the page type
• links with attributes chosen for a specific purpose

The main rule is:

Understand why the tool flagged something before fixing it.

Audit website behaviour and business-critical routes — not the colour of tool icons.

The most common React SEO errors

1. The same title on every route. Metadata is handled globally instead of per route.
2. Main content only exists after JavaScript or an API call. There is no robust rendering strategy for SEO-critical pages.
3. SPA 404 returns HTTP 200. The user sees an error, but the server signals success.
4. Incorrect or missing canonical. URL variants become unclear.
5. Dynamic routes are missing from the sitemap. Pages exist in the app but not in the URL generator.
6. Click handlers are used as links. Navigation looks correct, but the markup is not crawlable.
7. JavaScript bundles are too large. Loading and responsiveness become unnecessarily heavy.
8. SEO routes are not prerendered even though doing so would simplify the output.
9. API content fails during rendering. The crawler and user can receive empty or incomplete content.
10. Internal linking is weak. Routes are only available through the sitemap or a direct URL.
11. Staging `noindex` has reached production.
12. URL moves happen only client-side. An HTTP redirect is missing.

Frameworks: React is not one architecture

“React website” can mean very different things:

• classic React SPA
• Next.js
• Remix
• Astro with React components
• Vite + React with prerendering
• custom SSR
• hybrid setup

The audit should not begin with “Next.js = good” or “SPA = bad”. Audit output, status codes, routing, links, metadata, rendering, performance and indexing behaviour. The framework is only part of the explanation.

Test the production build — not only the development environment

A site can work locally and behave differently after build or deployment.

Check the actual production version:

• generated HTML
• route metadata
• assets
• routing
• 404
• redirects
• sitemap
• robots.txt
• canonical
• schema
• API endpoints

Errors can arise in build-time data, environment variables, CDN rules, rewrites or hosting configuration.

Pre-deploy SEO validation

Some errors can be caught automatically before deployment.

Consider checks for:

• title on indexable routes
• canonical
• sitemap URLs
• broken internal links
• route status
• JSON-LD parsing
• build success
• type check

On static sites, a script can, for example, check that important routes contain a title, canonical and main content.

Automation does not replace manual SEO review. It is best for known regression errors: things that should always be true before production.

When is the problem not technical SEO?

A technically perfect site can still have low organic visibility.

The problem may be:

• very low search demand
• incorrect search intent
• thin or undifferentiated content
• strong competition
• low authority
• few relevant mentions or backlinks
• weak information architecture
• unclear brand or offer

Technical SEO creates the foundation for discovery, rendering and understanding. It does not guarantee rankings.

If crawling, indexing and performance are solid, the analysis should move on to content, intent and competition.

When does a professional technical SEO audit make sense?

It is especially relevant for larger React sites, migrations, framework changes, many dynamic routes, persistent indexing problems, weak Core Web Vitals or technical findings that lack prioritisation.

When the need has moved from self-diagnosis to a genuine code and implementation review, a technical SEO review may be the natural next step.

If the problem is more fundamentally about the architecture of a new React site, it may also be relevant to look at custom websites and how route-specific HTML, metadata and performance are built in from the start.

Practical audit checklist

Rendering

• [ ] Important content can render reliably
• [ ] The rendering strategy is understood for each important page type
• [ ] Initial HTML or build output has been checked
• [ ] No critical JavaScript errors block content

Indexing

• [ ] Important landing pages are indexable
• [ ] noindex is used intentionally
• [ ] URL Inspection has been checked on representative routes
• [ ] Page indexing patterns have been assessed against the desired indexing

Metadata

• [ ] Unique title on central routes
• [ ] Relevant meta description
• [ ] Correct canonical
• [ ] Robots meta is correct
• [ ] Metadata works for both direct requests and client navigation

Crawling

• [ ] Sitemap contains the desired canonical URLs
• [ ] robots.txt has been checked
• [ ] Internal links are crawlable
• [ ] Orphan pages have been identified
• [ ] Status codes and redirects are correct

Content and HTML

• [ ] Clear H1
• [ ] Logical heading structure
• [ ] Semantic links and buttons
• [ ] Important content is available without user interaction

Performance

• [ ] LCP has been analysed
• [ ] INP has been analysed
• [ ] CLS has been analysed
• [ ] JavaScript bundle has been reviewed
• [ ] LCP image and image strategy have been reviewed
• [ ] Third-party scripts have been assessed

Structured data

• [ ] JSON-LD can be parsed
• [ ] Schema is relevant
• [ ] Markup matches visible content
• [ ] Route-specific data is correct

Production

• [ ] Final build has been validated
• [ ] Redirects work after deployment
• [ ] 404 returns the correct status
• [ ] Dynamic routes have been tested
• [ ] Sitemap and robots.txt are correct in production

FAQ

Is React bad for SEO?

No. React can be used for SEO-strong websites. Problems arise from implementations where rendering, routing, metadata, links or status codes do not work robustly for the crawler.

Can Google index React websites?

Yes. Google can render JavaScript. It is still important to test whether the specific site can be retrieved and rendered correctly, and whether content, links and metadata actually become available.

What is the difference between CSR, SSR and SSG?

CSR primarily builds the page in the browser. SSR generates HTML on the server for a request. SSG generates HTML during the build. Many modern React sites combine strategies.

Do React pages need to be prerendered?

Not always. Prerendering is often useful for stable, SEO-critical routes, but the right strategy depends on data, update frequency and application needs.

How do I check whether Google can see my React content?

Compare initial HTML with the rendered DOM, use Search Console URL Inspection and check relevant routes with a crawler and direct HTTP requests.

Is client-side rendering bad for SEO?

Not automatically. CSR does increase dependence on JavaScript and client-side data. Important routes should be tested for robust rendering, metadata, links and error states.

How do you handle metadata in React?

Metadata should be route-specific and stable when the URL is requested directly. In SEO-critical setups, title, canonical and other central tags should not depend only on late client-side navigation.

Why can a React 404 return status 200?

Because the router can show a 404 component after the server has already responded with 200. The hosting or server layer must be configured so non-existent URLs return a correct 404 status.

Are Core Web Vitals part of technical SEO?

Yes, they are relevant to technical quality and user experience. They should, however, be analysed together with rendering, indexing, content and other technical factors — not as an isolated SEO score.

Can a React site rank as well as WordPress?

Yes. Neither platform automatically ranks better. The specific implementation, content, search intent, authority, crawlability and user experience matter more than the technology name.

Conclusion

A technical SEO audit is not about getting every audit tool to show 100. The goal is to ensure that the pages that should rank can be crawled, rendered, understood and used effectively.

On React sites, this especially means checking more than the finished browser view. Look at HTTP status, initial HTML, rendering, metadata, dynamic routes, internal links, JavaScript errors and the actual production build.

If a React site has unclear indexing, rendering or performance problems, AS Web Solutions can help with a technical review and implementation of the relevant fixes. But the audit should first determine which problems genuinely affect the important pages, so the effort is prioritised by impact rather than by the number of notices.