Free SEO audit with 10 action points - $2K worth of value

Home

SEO Consulting SEO Copywriting Website Migration SEO for M&A AI Search & LLM Visibility Headless & JavaScript SEO Reputation & SERP Management SEO Training Guest Post Backlinks Prices & Packages

Website Design Claude Websites Google Ads Management Landing Pages

5.0 on Google · 10+ years in SEO

Headless SEO and JavaScript SEO for Modern Websites

Q: Do you work directly with our developers?

Yes. Fixes are written as developer tickets, with sprint calls where useful and testing on staging.

Make your headless or JavaScript site as readable to Google and AI crawlers as it is fast for users.

Next.js, React, Hydrogen and headless CMS
Rendering and indexation fixes
Developer-ready tickets, tested on staging

Talk about your site What I fix

10+ Yearsof SEO Experience

Stacks

Next.js, React, Hydrogen

Background

Developer-turned SEO

Output

Developer-ready tickets

Best engaged

Before you build

Home / Headless & JavaScript SEO

I came into SEO from web development, so I read the code, not just the crawl report. I audit Next.js, Nuxt, React, Vue, Shopify Hydrogen and headless CMS sites, then work with your developers to fix rendering, indexation and performance at the source.

Why Headless and JavaScript Sites Need Specialist SEO

On a traditional site, the server sends finished HTML. On a JavaScript site, the server often sends a script, and the browser builds the page. Googlebot can render JavaScript, but it does it in a second pass, with limits on time and resources. Anything that breaks in that pass is invisible to search.

AI crawlers are stricter again. Most of the bots that feed ChatGPT, Claude, Perplexity and other LLMs do not execute JavaScript at all. If your product copy, prices or FAQs only appear after client-side rendering, those crawlers see nothing. That is a growing visibility problem, not a Google-only one.

Headless adds a second layer of risk. The CMS no longer controls the front end, so the things a WordPress or Shopify theme handled for free are now custom code: titles, canonicals, redirects, sitemaps, hreflang, structured data and robots rules. If nobody specified them, they are usually missing or wrong.

What I Fix on Headless and JavaScript Sites

Rendering strategy

The biggest decision on a JavaScript site is where the HTML gets built. I review your mix of client-side rendering, server-side rendering, static generation and incremental regeneration, page type by page type.

Money pages, collection pages, product pages and articles should ship complete HTML in the first response. Logged-in dashboards and carts do not need to. Getting this split right fixes most JavaScript SEO problems in one move.

Raw HTML vs rendered HTML parity

I compare what the server sends against what the browser ends up showing. Common gaps include body copy, internal links, canonical tags and structured data that only exist after JavaScript runs.

Then I check the same URLs in Search Console's URL Inspection tool, so we know what Google actually indexed, not what we assume it saw.

Hydration errors and content mismatches

When server HTML and client output disagree, the framework throws hydration errors and sometimes replaces the server content. The user may never notice. Google may index the wrong version, or a blank one. I find these in the console and in rendered crawls, then hand developers the exact component and URL.

Crawlable links and routing

Links built as buttons with click handlers, or routes with hash fragments, are not links to a crawler. I check that every navigation path uses real anchor tags with real hrefs, that faceted filters do not create endless URL combinations, and that soft 404s return a proper 404 status code.

Metadata, canonicals and status codes

In a headless setup, every SEO tag is generated by code. I audit titles, meta descriptions, canonicals, robots meta, Open Graph tags and hreflang across templates. I also check that redirects and errors return real 301 and 404 codes from the server, not a JavaScript redirect after the page loads.

Structured data

Product, Organization, Article, BreadcrumbList and FAQ schema should be in the server response, not injected late by a tag manager. I map the right schema to each template and validate it in the rendered and raw output.

Core Web Vitals

Headless is meant to be fast, but heavy JavaScript bundles often make it slow on mobile. I look at field data for LCP, INP and CLS, then trace problems to large bundles, third-party scripts, unoptimised images and layout shifts from late-loading components.

XML sitemaps and robots rules

Sitemaps on headless sites are often generated once and forgotten, or built from the CMS rather than the live routes. I check they list only indexable, canonical, 200-status URLs, and that robots.txt does not block the JavaScript and API files Google needs to render the page.

Actionable tip: open any key page, view the page source (not Inspect), and search for a sentence from your main copy. If it is not there, crawlers that do not render JavaScript cannot see it either.

Headless Commerce SEO

Most of my work is ecommerce, and headless stores have problems of their own.

Shopify Hydrogen and headless Shopify

Going headless on Shopify removes the theme, and with it Shopify's built-in sitemaps, canonicals and redirect handling. I make sure product and collection URLs, variant handling, redirects from the old store and the URL redirect table are rebuilt properly in the new front end.

BigCommerce, Adobe Commerce and custom storefronts

The same rules apply on any decoupled store. Product data has to be in the server HTML, filters have to be controlled, and pagination has to be crawlable. Price and stock in schema have to match what is on the page.

Headless CMS sites

Sanity, Contentful, Strapi, Storyblok and headless WordPress all give editors a content model, not an SEO plugin. I spec the SEO fields your editors need, such as title, description, canonical override, noindex and social image, so content teams can manage SEO without a developer.

Moving to Headless Without Losing Rankings

A move to headless is a migration, even if the domain stays the same. URLs, templates, rendering and internal linking all change at once. That is why so many headless launches drop 30% to 60% of organic traffic in the first month.

I get involved before build where possible. That means an SEO spec for developers, URL mapping and redirects, a staging crawl in rendered and raw mode, and a launch-day checklist. After go-live, I monitor indexation and rankings until traffic is back above baseline. My website migration service covers the full process.

Actionable tip: crawl your staging site with JavaScript rendering turned off before launch. Every page that comes back empty is a page that will struggle to rank.

AI-Built Sites: Lovable, Bolt and v0

AI website builders mostly ship single-page React apps rendered in the browser. They look finished, but many return almost nothing to a crawler. I covered the common issues in technical SEO fixes for AI websites and SEO for Lovable websites. The fixes are predictable: prerendering or SSR, real routes, per-page metadata, sitemaps and schema.

How an Engagement Works

Discovery

I review your stack, rendering setup, Search Console and analytics, and find out what your developers are already planning.

Audit

A rendered and raw crawl, URL Inspection on key templates, log file analysis where available, and a Core Web Vitals review.

Developer-ready fixes

Findings are written as tickets your developers can pick up, with the URL, the problem, the expected output and how to test it.

Testing

I check fixes on staging before release, so problems are caught before Google sees them.

Monitoring

Indexation, rendering and performance are tracked after release, either as a one-off project or through SEO consulting.

Who This Service Is For

Ecommerce brands on headless Shopify, BigCommerce or a custom storefront
Businesses running Next.js, Nuxt, Gatsby, Astro, React or Vue front ends
Teams on a headless CMS who have lost the safety net of an SEO plugin
Companies planning a move to headless who want SEO in the spec, not bolted on after launch
Founders with AI-built sites that are not getting indexed

Frequently asked questions

Is headless bad for SEO?

No. A well-built headless site can be faster and cleaner than most themes. The risk comes from launching without SEO requirements, so basics like rendering, redirects and metadata are missed.

Can Google index JavaScript?

Yes, but rendering happens in a second stage with limits, and failures are common on large or complex sites. Many AI crawlers do not render JavaScript at all, so important content should be in the server HTML.

Should we use server-side rendering or static generation?

It depends on how often content changes. Static generation suits pages that rarely change. Server-side rendering or incremental regeneration suits stock, prices and large catalogues. Most sites need a mix by page type.

Do you work directly with our developers?

Yes. I write fixes as developer tickets, join sprint calls where useful, and test on staging. My development background means we speak the same language.

Which frameworks do you work with?

Next.js, Nuxt, React, Vue, Astro, Gatsby, Shopify Hydrogen and headless CMS platforms including Sanity, Contentful, Strapi, Storyblok and headless WordPress.

Is headless SEO only for big sites?

No. Small sites built with JavaScript frameworks or AI builders often have the most basic problems, such as pages that return no content to crawlers. Those are usually quick to fix.

The bottom line

Headless and JavaScript frameworks give you speed and flexibility, but they take away the SEO defaults a traditional CMS gave you for free. Headless SEO puts them back, in code, so Google and AI crawlers see the same page your customers do.

Talk about your site See packages