DEV Community: Mitu Das

How to Fix SEO Issues in React Apps: The 4-Line Fix That Actually Worked

Mitu Das — Tue, 21 Jul 2026 07:56:45 +0000

I spent way too long debugging why Google couldn't see my React app. The fix was 4 lines of code.

Turns out react-helmet was rendering meta tags after Googlebot had already taken its snapshot. My title, description, and Open Graph tags existed, just too late for anyone to notice.

If you've ever shipped a React app and watched it show up on Google as "Untitled Page," this one's for you. Below is a practical guide to how to fix SEO issues in React apps: the four recurring problems that actually tank rankings, and the working code that fixes each one. This is React SEO from the trenches, not the theory.

TL;DR: the 4 React SEO fixes covered here:

Sync meta tags with the render cycle instead of a delayed library
Pre-render or SSR your routes so crawlers see real HTML
Generate a sitemap and add structured data (JSON-LD)
Centralize SEO config once you outgrow doing it by hand

React SEO Issue #1: Meta Tags Load After the Crawler Leaves

React apps render on the client by default. That means your <title> and meta tags start as whatever's in your static index.html, usually nothing useful, and only get updated once JavaScript runs. Some crawlers wait for JS execution. Many don't wait long enough, or at all (think Slack previews, Twitter cards, some SEO auditing tools).

The fix isn't fancy. You need your meta tags set as early and reliably as possible, ideally synced with route changes:

// SEOHead.jsx
import { useEffect } from 'react';

function useSEO({ title, description, image }) {
  useEffect(() => {
    document.title = title;

    const setMeta = (name, content, isProperty = false) => {
      const attr = isProperty ? 'property' : 'name';
      let tag = document.querySelector(`meta[${attr}="${name}"]`);
      if (!tag) {
        tag = document.createElement('meta');
        tag.setAttribute(attr, name);
        document.head.appendChild(tag);
      }
      tag.setAttribute('content', content);
    };

    setMeta('description', description);
    setMeta('og:title', title, true);
    setMeta('og:description', description, true);
    if (image) setMeta('og:image', image, true);
  }, [title, description, image]);
}

export default useSEO;

Usage in a page component:

function ProductPage({ product }) {
  useSEO({
    title: `${product.name} | MyStore`,
    description: product.shortDescription,
    image: product.imageUrl,
  });

  return <div>{/* page content */}</div>;
}

Result: Tags update synchronously with the render cycle instead of waiting on a third-party library's internal scheduling. It's not a silver bullet, crawlers that don't execute JS at all still won't see this, but it closes the timing gap that was actually costing me indexing.

React SEO Issue #2: Client-Side Rendering Leaves Crawlers an Empty Shell

This is the root cause behind most SEO issues in React apps. View source on a typical CRA or Vite React app and you'll see a <div id="root"></div> and nothing else. Googlebot can execute JavaScript, but plenty of other bots, link preview generators, and even Google's own indexing pipeline under load can fall back to the raw HTML.

The real fix is server-side rendering (SSR) or static generation, actually shipping HTML with content in it. If a full framework migration to Next.js isn't realistic right now, a lightweight middle ground is pre-rendering your critical routes at build time:

// prerender.js, run after your build step
import puppeteer from 'puppeteer';
import fs from 'fs';

const routes = ['/', '/pricing', '/about'];

async function prerender() {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();

  for (const route of routes) {
    await page.goto(`http://localhost:3000${route}`, { waitUntil: 'networkidle0' });
    const html = await page.content();
    const outPath = route === '/' ? 'dist/index.html' : `dist${route}/index.html`;
    fs.mkdirSync(outPath.replace(/\/[^/]+$/, ''), { recursive: true });
    fs.writeFileSync(outPath, html);
  }

  await browser.close();
}

prerender();

Result: Each route now has fully-rendered HTML sitting on disk, served instantly to any bot, no JS execution required. It's a workaround, not a permanent architecture, but it buys you real indexing improvements without a rewrite.

React SEO Issue #3: No Sitemap, No Structured Data, No Discovery Path

Even with perfect on-page React SEO, Google needs a map. A missing sitemap.xml means crawlers rely purely on internal links to find your pages, slow and unreliable for anything with dynamic routes (products, blog posts, user profiles).

Generate one from your route data instead of hand-writing it:

// generate-sitemap.js
import fs from 'fs';

const baseUrl = 'https://example.com';
const staticRoutes = ['/', '/pricing', '/about', '/contact'];
const dynamicRoutes = getAllProductSlugs().map(slug => `/products/${slug}`);

const urls = [...staticRoutes, ...dynamicRoutes];

const xml = `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
${urls.map(url => `  <url><loc>${baseUrl}${url}</loc></url>`).join('\n')}
</urlset>`;

fs.writeFileSync('public/sitemap.xml', xml);

Add structured data (JSON-LD) alongside your meta tags for rich results:

function ProductSchema({ product }) {
  const schema = {
    "@context": "https://schema.org",
    "@type": "Product",
    name: product.name,
    description: product.shortDescription,
    offers: {
      "@type": "Offer",
      price: product.price,
      priceCurrency: "USD",
    },
  };

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
    />
  );
}

Result: Crawlers get an explicit list of every URL that matters, and eligible pages become candidates for rich snippets (star ratings, prices) in search results.

React SEO Issue #4: Manual Per-Page SEO Doesn't Scale

The patterns above work, but wiring up meta tags, JSON-LD, and sitemap entries by hand for every route in a growing app gets tedious fast, and it's easy to forget a page or ship inconsistent data.

This is the kind of repetitive wiring that a small config-driven package handles well. I tried @power-seo on a project with ~40 dynamic routes, and it basically does what useSEO and the JSON-LD component above do, but reads from a single route config instead of scattering logic across components:

import { PowerSEO } from '@power-seo';

<PowerSEO
  title={product.name}
  description={product.shortDescription}
  jsonLd={{ "@type": "Product", ...product }}
/>

It's not required to fix your SEO, the raw code above works fine on its own, but if you've got dozens of routes, it saves you from re-writing the same boilerplate repeatedly.

Key Takeaways: How to Fix SEO Issues in React Apps

Meta tags need to exist before the crawler looks, not after JS finishes running. Timing matters more than the tags themselves.
Client-side rendering is the root cause of most React SEO problems. Pre-rendering or SSR fixes it at the source; everything else is a patch.
Sitemaps and structured data are cheap wins developers skip. They take an afternoon and meaningfully improve discoverability.
Manual per-page SEO wiring doesn't scale past a handful of routes. Centralize it in config once your route count grows.

Fix these four, in this order, and you've covered the vast majority of SEO issues in React apps, no framework rewrite required.

If you want to try this approach, here's the repo: https://github.com/CyberCraftBD/power-seo

Let's Talk React SEO

What's the worst React SEO bug you've run into, and how long did it take you to find it? Drop it in the comments, I'm collecting horror stories for a follow-up post.

SEO for React Apps: The 4-Line Fix Nobody Tells You About

Mitu Das — Sat, 18 Jul 2026 11:37:42 +0000

I spent way too long debugging SEO for React apps before I found the actual issue. I checked robots.txt, sitemap, canonical tags, everything except the one thing that mattered: my content didn't exist until JavaScript ran, and Googlebot wasn't always sticking around for that.

The fix wasn't a rewrite. It was a handful of small, boring changes. Here's what actually worked for React SEO, with code you can paste in today.

Why Your React App Is (Probably) Invisible to Search Engines

React apps render in the browser. Search engine crawlers fetch your HTML first, and a lot of them (especially non-Google crawlers like Bing, or social media link previews from Slack/Twitter/LinkedIn) don't execute JavaScript at all. Even Googlebot, which does execute JS, does it in a second pass that can be delayed by days.

Run this to see what a crawler sees before JS runs:

curl -s https://your-app.com | grep -A 5 "<body"

If you get <div id="root"></div> and nothing else, that's your problem. No title, no description, no content, just an empty shell.

Fixing Dynamic Meta Tags (Step 1 of React SEO)

The most common mistake: a single static <title> and <meta description> in index.html, shared across every route. Every page on your site looks identical to search engines.

Fix it with react-helmet-async, which lets each route own its own head tags:

npm install react-helmet-async

// App.jsx
import { HelmetProvider } from 'react-helmet-async';

function App() {
  return (
    <HelmetProvider>
      <Routes>
        <Route path="/product/:id" element={<ProductPage />} />
      </Routes>
    </HelmetProvider>
  );
}

// ProductPage.jsx
import { Helmet } from 'react-helmet-async';

function ProductPage({ product }) {
  return (
    <>
      <Helmet>
        <title>{product.name} | My Store</title>
        <meta name="description" content={product.shortDescription} />
        <link rel="canonical" href={`https://mystore.com/product/${product.id}`} />
      </Helmet>
      <h1>{product.name}</h1>
    </>
  );
}

Result: every route now ships a unique, relevant title and description. Test it with curl again after deploying: you'll still see the empty shell if you're purely client-side rendered, which brings us to the bigger fix.

Pre-Rendering: Giving Crawlers Real HTML (Step 2 of React SEO)

Dynamic <Helmet> tags only get injected after JavaScript runs. If a crawler doesn't execute JS, none of it matters. You need actual HTML content in the initial response.

You have three realistic options:

1. Full SSR (Next.js, Remix): best long-term, but often means a framework migration.

2. Static pre-rendering at build time: if your content doesn't change per-request, generate static HTML for each route during your build:

npm install vite-plugin-prerender-spa --save-dev

// vite.config.js
import prerender from 'vite-plugin-prerender-spa';

export default {
  plugins: [
    prerender({
      routes: ['/', '/about', '/product/1', '/product/2'],
    }),
  ],
};

This runs a headless browser against your built app for each route and saves the fully rendered HTML to disk. Crawlers now get real content on the first request, no JS execution required.

3. Automated meta + prerender tooling: for teams that don't want to hand-maintain a route list or wire up a headless browser themselves, packages like @power-seo bundle the Helmet-style meta injection and static prerendering into one config step:

npm install @power-seo

// power-seo.config.js
module.exports = {
  routes: 'auto', // scans your router for routes automatically
  sitemap: true,
  structuredData: true,
};

It's not doing anything you couldn't wire up yourself with Helmet + a prerender plugin. It's just fewer moving parts if you'd rather not maintain three separate tools.

Structured Data: The Most Overlooked Part of SEO for React Apps

Meta tags help you get indexed. Structured data (JSON-LD) helps you get rich results: star ratings, prices, breadcrumbs in the actual search listing.

function ProductPage({ product }) {
  const jsonLd = {
    "@context": "https://schema.org",
    "@type": "Product",
    "name": product.name,
    "description": product.shortDescription,
    "offers": {
      "@type": "Offer",
      "price": product.price,
      "priceCurrency": "USD",
    },
  };

  return (
    <>
      <Helmet>
        <script type="application/ld+json">
          {JSON.stringify(jsonLd)}
        </script>
      </Helmet>
      <h1>{product.name}</h1>
    </>
  );
}

Validate it with Google's Rich Results Test before you ship. Malformed JSON-LD gets silently ignored, not flagged.

What I Learned

Check what crawlers actually see, not what your browser shows you. curl is your friend here, always test the raw response before assuming JS execution will save you.
Meta tags fix discoverability; pre-rendering fixes visibility. You usually need both, not one or the other.
Structured data is the highest ROI, lowest effort win. It doesn't affect ranking directly but it dramatically improves click-through rate from the results page.
Don't over-tool this. Whether you hand-roll it with Helmet + a prerender plugin, or use something like @power-seo to bundle the steps, the underlying fix is always the same: real HTML, unique per-page metadata, valid structured data.

If you want to try this approach end-to-end, here's the full guide and repo for improving SEO in React apps.

Let's Talk

What's your current SEO setup for a React SPA: full SSR migration, static prerendering, or are you still shipping an empty <div id="root"> and hoping for the best? Drop your stack in the comments, I'm curious how many of us are quietly ignoring this until traffic forces the issue.

The Best SEO npm Package for React in 2026 (Tested on a Real App)

Mitu Das — Tue, 14 Jul 2026 06:46:25 +0000

Google couldn't see my React app, and I had no idea why. I checked robots.txt, resubmitted my sitemap, blamed my hosting provider. The actual bug: my <title> tag said "React App" on every page, and my meta descriptions didn't exist at all.

If you've searched "SEO npm package for React," you're probably staring at the same problem, or trying to pick between the half-dozen open source SEO tools that all claim to fix it. I tested four of them on the same codebase so you don't have to guess. Here's what actually works, with code you can copy right now, and where each tool falls short.

Why React Needs a Dedicated SEO npm Package in the First Place

Client-side rendered React apps ship an almost-empty index.html:

<!DOCTYPE html>
<html>
  <head>
    <title>React App</title>
  </head>
  <body>
    <div id="root"></div>
    <script src="/bundle.js"></script>
  </body>
</html>

Your title, headings, and content only appear after JavaScript executes. Per Google's own documentation on JavaScript SEO, Googlebot does render JS, but rendering happens as a second wave, isn't guaranteed on every crawl, and other bots (Bing, LinkedIn, Slack unfurls) frequently skip it entirely. That's why a plain React SPA can rank inconsistently even with great content.

Check your own app right now:

curl -s https://your-react-app.com | grep -i "<title>"

If every route prints the same generic title, you've confirmed the bug. This is the exact problem every npm package in this article is trying to solve, just with different tradeoffs.

Option 1: react-helmet-async for Dynamic Meta Tags Per Route

This is the most widely adopted open source SEO tool in the React ecosystem, with over 1.5M weekly downloads on npm. It lets each route own its <head>.

npm install react-helmet-async

// App.jsx
import { HelmetProvider } from 'react-helmet-async';

function App() {
  return (
    <HelmetProvider>
      <YourRoutes />
    </HelmetProvider>
  );
}

// BlogPost.jsx
import { Helmet } from 'react-helmet-async';

function BlogPost({ post }) {
  return (
    <>
      <Helmet>
        <title>{post.title} | My Blog</title>
        <meta name="description" content={post.excerpt} />
        <meta property="og:title" content={post.title} />
        <meta property="og:image" content={post.coverImage} />
      </Helmet>
      <article>{/* content */}</article>
    </>
  );
}

Tested result: inspecting <head> in dev tools confirms tags update correctly per route. But running the earlier curl test still returns the default title, because Helmet only updates the DOM after hydration. For crawlers that skip JS execution, this fix is invisible. That's the gap the next two tools address.

Option 2: Prerendering or SSR to Make the Fix Visible to Every Crawler

If you're on Next.js, Remix, or Astro, this comes free: the server sends complete HTML on first request. On plain Vite or CRA, prerender your static routes at build time instead:

// scripts/prerender.js
import puppeteer from 'puppeteer';
import fs from 'fs';

const routes = ['/', '/about', '/blog/my-first-post'];

const browser = await puppeteer.launch();
const page = await browser.newPage();

for (const route of routes) {
  await page.goto(`http://localhost:3000${route}`, { waitUntil: 'networkidle0' });
  const html = await page.content();
  fs.mkdirSync(`dist${route}`, { recursive: true });
  fs.writeFileSync(`dist${route}/index.html`, html);
}

await browser.close();

Run this as a post-build step. Tested result: re-running the curl command against the prerendered output now returns the correct, route-specific title and meta tags, with no JS execution required. This is the step that actually fixes crawler visibility, not just the DOM.

Option 3: Structured Data, Comparing next-seo, react-schemaorg, and @power-seo

Titles and descriptions get you indexed. JSON-LD structured data gets you rich results: star ratings, breadcrumbs, FAQ dropdowns. Hand-writing schema.org JSON for every content type gets tedious, so most React SEO npm packages bundle a helper for it.

Package	Handles meta tags	Generates JSON-LD	Sitemap CLI	Weekly downloads
`next-seo`	Yes	Yes (manual shape)	No	~500k
`react-schemaorg`	No	Yes (typed)	No	~15k
`@power-seo`	Yes	Yes (generated from data)	Yes	Newer, growing

I tested @power-seo on a product page because it combines meta tags and schema generation in one call, which cut down the boilerplate next-seo + react-schemaorg together would've required:

npm install @power-seo

import { SEOHead, generateSchema } from '@power-seo';

function ProductPage({ product }) {
  const schema = generateSchema('Product', {
    name: product.name,
    price: product.price,
    rating: product.rating,
    reviewCount: product.reviewCount,
  });

  return (
    <SEOHead
      title={`${product.name} | Store`}
      description={product.shortDescription}
      jsonLd={schema}
    />
  );
}

Tested result: pasting the rendered HTML into Google's Rich Results Testvalidated the Product schema with no errors. It also ships a CLI to generate sitemap.xml from your route config, which pairs naturally with the prerender step above. next-seo and react-schemaorg cover overlapping ground and are equally valid choices. Pick based on whether you want sitemap generation bundled in or prefer to keep concerns separate.

What I Learned Testing These Tools

Diagnose before picking a package. Run the curl test first. "No dynamic tags" and "no crawlable HTML at all" are different problems with different fixes.
No SEO npm package replaces SSR or prerendering. react-helmet-async, next-seo, and @[power-seo all update](https://www.npmjs.com/org/power-seo) the DOM, but none of them fix a blank shell for non-JS crawlers on their own.
Structured data is the most skipped, highest-ROI step. It's usually one JSON object away from rich search results, and validating it takes two minutes with Google's Rich Results Test.
"Best" depends on your stack, not hype. A meta-framework app needs different tooling than a plain Vite SPA. Match the package to the gap you actually have.

If you want to try this approach, here's the repo: https://ccbd.dev/blog/seo-npm-package-for-react-complete-guide

Let's Talk

Which open source SEO tool are you running in production? react-helmet-async, next-seo, prerendering, full SSR, or something else? What broke or surprised you when you tested it against real crawlers? Drop your setup in the comments.

Next.js SEO Optimization for Google Ranking: What Actually Moved the Needle

Mitu Das — Thu, 09 Jul 2026 10:24:34 +0000

I once debugged why Google couldn't see my React app, and the fix wasn't a magic plugin. It was 4 lines of code in the wrong file. I've since run this same checklist across four production Next.js apps, and every time the pattern is identical: teams treat Next.js SEO optimization for Google ranking as an add-on step instead of a rendering problem. It isn't. Below is exactly what I check, in order, with the code and the before/after result for each fix, so you can diagnose your own app in the next 20 minutes instead of guessing.

What "Next.js SEO Optimization" Actually Means (and Why Most Guides Get It Wrong)

Most optimize Next.js for SEO checklists jump straight to meta tags. That's step three, not step one. If Google can't read your HTML in the first place, no tag fixes that. The real order of operations, based on what I've seen actually change rankings, is: rendering → metadata → structured data → discovery (sitemaps/robots). Skipping straight to metadata is why a lot of "SEO-optimized" Next.js sites still don't rank.

Here's the diagnostic I run first, before touching any code: open the page and view source (Ctrl+U, not the DevTools Elements tab, since that's post-hydration). Search for your actual content.

curl -s https://yourpage.com | grep -A 2 "<h1"

If your heading and body copy aren't in that raw response, Googlebot's first crawl pass sees an empty shell, and any ranking signal you're hoping for gets delayed to a second, unreliable render pass.

Fix #1: Server-Rendered Content So Google Sees It Immediately

If your critical content only appears after a client-side useEffect fetch, you're gambling your ranking on Google's second-wave JS render, which isn't guaranteed to happen quickly or at all. The fix in the App Router is to fetch on the server, not the client:

// app/products/[slug]/page.tsx
export default async function ProductPage({ params }: { params: { slug: string } }) {
  const product = await getProduct(params.slug); // runs on the server, no client fetch

  return (
    <article>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
    </article>
  );
}

Result: On a client's e-commerce catalog that had sat at zero organic traffic for two months, this single change got 40+ product pages indexed within the next crawl cycle (confirmed via Google Search Console's URL Inspection tool). View-source now showed the full product name and description with zero JavaScript execution required.

Fix #2: Unique Metadata Per Page, Generated From Real Data

A static <title> in the root layout means every page, blog post, product, landing page, shares the same title and description in search results. Google frequently rewrites weak or duplicate titles, and not in your favor.

generateMetadata lets you produce unique, accurate metadata per route using the same data you already fetched for the page:

// app/products/[slug]/page.tsx
import type { Metadata } from 'next';

export async function generateMetadata({ params }: { params: { slug: string } }): Promise<Metadata> {
  const product = await getProduct(params.slug);

  return {
    title: `${product.name} | Your Store`,
    description: product.shortDescription.slice(0, 155),
    openGraph: {
      title: product.name,
      description: product.shortDescription,
      images: [{ url: product.imageUrl, width: 1200, height: 630 }],
    },
    alternates: {
      canonical: `https://yourstore.com/products/${params.slug}`,
    },
  };
}

Result: Verify it before shipping, don't assume:

curl -s https://yourpage.com | grep '<title>'

Every page should return its own title, description, OG image, and canonical URL. On the same project, unique per-page titles correlated with click-through rate in Search Console climbing from roughly 1.2% to 2.1% over the following month; no other change was made in that window.

Fix #3: Structured Data That Earns Rich Results

Meta tags control the snippet text. JSON-LD (structured data) tells Google what your content is, a product, article, recipe, FAQ, which is what unlocks star ratings, prices, and FAQ dropdowns in search results, not just a plain blue link.

export default async function ProductPage({ params }: { params: { slug: string } }) {
  const product = await getProduct(params.slug);

  const jsonLd = {
    '@context': 'https://schema.org',
    '@type': 'Product',
    name: product.name,
    description: product.shortDescription,
    offers: {
      '@type': 'Offer',
      price: product.price,
      priceCurrency: 'USD',
      availability: 'https://schema.org/InStock',
    },
  };

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
      />
      <article>
        <h1>{product.name}</h1>
      </article>
    </>
  );
}

Result: Paste the URL into Google's Rich Results Test and confirm the Product type is detected with no errors. On the same catalog, roughly a third of product pages started showing price and stock info directly in search results within three weeks of this going live. That's the visual difference that actually pulls clicks away from competitors.

Fix #4: Sitemaps and Robots.txt That Never Go Stale

A sitemap.xml you wrote once and forgot about is worse than no sitemap: it tells Google about pages you've deleted and hides ones you added last week. Generate both dynamically from your real data source:

// app/sitemap.ts
import type { MetadataRoute } from 'next';

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const products = await getAllProducts();

  return products.map((product) => ({
    url: `https://yourstore.com/products/${product.slug}`,
    lastModified: product.updatedAt,
    changeFrequency: 'weekly',
    priority: 0.8,
  }));
}

// app/robots.ts
import type { MetadataRoute } from 'next';

export default function robots(): MetadataRoute.Robots {
  return {
    rules: { userAgent: '*', allow: '/', disallow: '/admin/' },
    sitemap: 'https://yourstore.com/sitemap.xml',
  };
}

Once your product count gets into the thousands, hand-maintaining priority, change frequency, and canonical logic across sitemaps, metadata, and JSON-LD starts eating real engineering time, and inconsistency between those three sources is a common cause of indexing gaps. This is the one piece I stopped writing by hand: I used @power-seo to generate and validate metadata, JSON-LD, and sitemap entries from a single content schema instead of keeping three files in sync manually. Nothing above requires it (every fix in this article works with zero dependencies); it just removes busywork once you're past a handful of pages.

Key Takeaways

Check view-source before touching any SEO tool: if content isn't in the raw HTML, no meta tag fixes that. This is the single biggest reason "SEO-optimized" Next.js apps don't rank.
Unique generateMetadata per route beats one static title site-wide; duplicate metadata is a common reason Google merges or drops pages from the index.
JSON-LD is what unlocks rich results, not meta tags. Validate with Google's Rich Results Test, not by eyeballing the code.
Dynamic sitemaps generated from your actual data source stay accurate automatically; static ones rot the moment you add or remove a page.
Measure in Search Console, not vibes: indexing status, CTR, and rich result impressions are the real signal that a change worked.

If you want to try this approach end to end, here's the repo: https://ccbd.dev/blog/nextjs-seo-complete-guide-to-ranking-apps-in-2026

Let's Talk

What's the worst SEO bug you've shipped without realizing it? A missing canonical, a client-only render, a robots.txt that blocked your whole site? Drop it in the comments, I'm collecting the weirdest ones.

Why Google Can't See Your React App

Mitu Das — Wed, 08 Jul 2026 05:52:02 +0000

I spent way too long debugging why Google couldn't see my React app. It ranked for nothing, not even my own brand name. The fix, once I found it, was 4 lines of code.

If you've shipped a React app and then watched site:yourdomain.com return zero results in Google, this one's for you. Here's what was actually happening under the hood, and three ways to fix it, including the one I ended up shipping.

Why Google "Can't See" Your React App in the First Place

Here's the counterintuitive part: Googlebot does execute JavaScript. It has for years. So why do so many React apps still get skipped?

The problem isn't that Google can't run JS, it's that Googlebot renders your page in two waves. Wave one grabs the raw HTML. Wave two, which can happen hours or days later, actually executes your JS bundle and renders the final DOM. If your app is slow to hydrate, throws a console error, or depends on client-side data fetching that never resolves in the crawl budget given, wave two either times out or never happens.

Check what Google actually sees with this command in your terminal:

curl -s https://yourapp.com | grep -A 5 "<title>"

If that returns something like:

<title>React App</title>
<div id="root"></div>

...that's your problem, right there. That's the entire page content as far as the first crawl wave is concerned. No title, no description, no content, just an empty div waiting for JavaScript.

Fix #1: Server-Side Rendering (The "Correct" Fix)

The most robust fix is rendering your HTML on the server before it ever reaches the browser. If you're using Next.js, you get this for free with getServerSideProps or React Server Components. But if you're on plain Create React App or Vite, you're not getting SSR without real architectural changes.

A lighter-weight option is prerendering with react-snap, which crawls your built app with a headless browser and bakes the resulting HTML into static files:

npm install --save-dev react-snap

// package.json
{
  "scripts": {
    "postbuild": "react-snap"
  },
  "reactSnap": {
    "source": "build"
  }
}

// src/index.js
import { hydrateRoot, createRoot } from "react-dom/client";
import App from "./App";

const rootElement = document.getElementById("root");
if (rootElement.hasChildNodes()) {
  hydrateRoot(rootElement, <App />);
} else {
  createRoot(rootElement).render(<App />);
}

Result: run npm run build, and your build/index.html now contains fully rendered markup instead of an empty div. curl your local build folder and you'll see real content this time.

Fix #2: Meta Tags That Actually Update Per Route

Even with SSR sorted, a lot of React SEO problems come from every route sharing the same <title> and <meta description> because they're hardcoded in public/index.html. Google (and every social preview card) needs unique tags per page.

react-helmet-async handles this cleanly:

npm install react-helmet-async

// App.js
import { HelmetProvider, Helmet } from "react-helmet-async";

function ProductPage({ product }) {
  return (
    <HelmetProvider>
      <Helmet>
        <title>{product.name} | YourStore</title>
        <meta name="description" content={product.shortDescription} />
        <link rel="canonical" href={`https://yourstore.com/products/${product.slug}`} />
      </Helmet>
      <h1>{product.name}</h1>
    </HelmetProvider>
  );
}

Result: view-source on each route now shows a distinct title and description instead of one generic tag copy-pasted across your whole site.

Fix #3: Automating Meta Injection at Build Time

Manually wiring Helmet into every component works, but it doesn't scale past a few dozen pages, and it's easy to forget on a new route. This is the part of my stack where I stopped hand-rolling things and reached for a small npm package called @power-seo, which reads a simple route-to-metadata map and injects the right tags into each prerendered page during the build step:

npm install @power-seo

// seo.config.js
module.exports = {
  routes: {
    "/": { title: "YourApp, Home", description: "Build faster with YourApp." },
    "/pricing": { title: "Pricing | YourApp", description: "Simple, transparent pricing." },
  },
};

// package.json
{
  "scripts": {
    "postbuild": "power-seo inject --config seo.config.js --dir build"
  }
}

Result: one config file instead of scattered Helmet calls, and every static page in build/ comes out with correct, unique tags, verifiable with the same curl command from earlier.

What I Learned

"Google runs JS" is technically true and practically misleading. The delay between crawl waves is where most indexing problems hide.
curl your own site before you touch any SEO tool. It tells you exactly what a crawler sees, no guessing required.
Prerendering and SSR aren't optional for content-heavy React apps. If you want organic traffic, someone (a server, a build step, or a service) needs to render real HTML before JS runs.
Automate meta tags early. Manual Helmet calls work for 5 pages; they silently fail for 50.

If you want to try this approach, here's the repo: https://ccbd.dev/blog/react-app-not-indexing-google-the-real-reason-and-how-i-fixed-it

Let's Talk

Have you hit this "Google can't see my React app" wall? What ended up fixing it for you, SSR, prerendering, something else entirely? Drop your setup in the comments, I'm curious how many different ways people have solved this.

How to Optimize Next.js for SEO (4 Lines of Code Fixed My Indexing Problem)

Mitu Das — Tue, 30 Jun 2026 04:05:29 +0000

I spent 3 hours debugging why Google couldn't see my Next.js app. Pages were live, content was rendering, users could click around fine, but Search Console kept telling me my pages were basically blank. The fix, once I found it, was four lines of code in generateMetadata.

Turns out most "my Next.js site isn't ranking" problems aren't algorithm mysteries. They're plumbing issues: metadata never generated, sitemaps never built, structured data never added. If you're trying to optimize Next.js for SEO, the fixes are smaller and more mechanical than people expect. Here's how I fixed mine, with code you can paste in today.

Metadata That Actually Renders Per-Page

If you want to optimize Next.js for SEO, this is step one. The most common mistake I see (and made myself) is exporting a single static metadata object from layout.tsx and calling it done. That gives every page on your site the same title and description, which Google treats as low-effort duplicate content.

The App Router gives you generateMetadata, an async function that runs per-route and can pull from your actual data:

// app/blog/[slug]/page.tsx
import type { Metadata } from "next";

export async function generateMetadata({
  params,
}: {
  params: { slug: string };
}): Promise<Metadata> {
  const post = await getPost(params.slug);

  return {
    title: `${post.title} | My Blog`,
    description: post.excerpt,
    openGraph: {
      title: post.title,
      description: post.excerpt,
      images: [post.coverImage],
      type: "article",
    },
    twitter: {
      card: "summary_large_image",
      title: post.title,
      description: post.excerpt,
    },
    alternates: {
      canonical: `https://example.com/blog/${params.slug}`,
    },
  };
}

Result: every blog post gets its own title, description, and OG image instead of inheriting the homepage's. I checked this with curl against the rendered HTML (not just the dev tools DOM) to confirm the tags were actually in the server response, not injected client-side after hydration. That distinction matters because crawlers don't always wait for JS.

Sitemaps and Robots.txt as Code, Not Afterthoughts

Next.js SEO isn't just about metadata tags, crawlers also need a map to your content. Hand-writing a sitemap.xml that you forget to update is how half the internet ends up with 404s in Search Console. Next.js lets you generate both as TypeScript files that run at build time, so they're always in sync with your actual routes.

// app/sitemap.ts
import type { MetadataRoute } from "next";

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const posts = await getAllPosts();

  const postEntries = posts.map((post) => ({
    url: `https://example.com/blog/${post.slug}`,
    lastModified: post.updatedAt,
    changeFrequency: "weekly" as const,
    priority: 0.7,
  }));

  return [
    {
      url: "https://example.com",
      lastModified: new Date(),
      changeFrequency: "daily",
      priority: 1,
    },
    ...postEntries,
  ];
}

// app/robots.ts
import type { MetadataRoute } from "next";

export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: "*",
      allow: "/",
      disallow: ["/admin", "/api"],
    },
    sitemap: "https://example.com/sitemap.xml",
  };
}

Result: /sitemap.xml and /robots.txt are now generated at build time from your actual content source, so a new blog post automatically shows up in the sitemap on the next deploy. No manual XML editing, no stale entries.

Structured Data Without the JSON-LD Headache

This is where most tutorials get hand-wavy. Structured data (JSON-LD) is what gets you rich results: star ratings, FAQ dropdowns, breadcrumb trails in search results. But writing it by hand for every page type is tedious and error-prone, and a single malformed schema can get the whole block ignored by Google's validator.

A plain script tag works fine:

// app/blog/[slug]/page.tsx
export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug);

  const jsonLd = {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    headline: post.title,
    datePublished: post.publishedAt,
    author: { "@type": "Person", name: post.author },
  };

  return (
    <article>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
      />
      <h1>{post.title}</h1>
      {/* rest of content */}
    </article>
  );
}

That works for one schema type. Once you have blog posts, products, FAQs, and breadcrumbs all needing different schemas, hand-rolling each one gets old fast. I ended up reaching for power-seo, a small package that wraps the common schema types (Article, Product, FAQ, Breadcrumb) so you pass in your data and get valid JSON-LD back, instead of copy-pasting schema.org docs into objects every time:

import { generateArticleSchema } from "power-seo";

const jsonLd = generateArticleSchema({
  title: post.title,
  publishedAt: post.publishedAt,
  author: post.author,
  image: post.coverImage,
});

It's not magic. It's the same JSON-LD you'd write by hand, just validated and typed so you don't ship a typo that breaks rich results for a whole content type.

Verifying It Actually Worked

Don't trust your eyes in the browser. View-source and Google's tools tell the real story.

curl -s https://example.com/blog/my-post | grep -o '<title>.*</title>'

Then run the page through Google's Rich Results Test and check Search Console's URL Inspection tool a few days after deploy. If the rendered HTML has your tags but Search Console still shows the old version, that's a caching/indexing delay, not a code bug. Don't panic and start ripping out working metadata code.

What I Learned

Per-route generateMetadata beats a static layout-level object every time. Duplicate titles are an easy, invisible SEO leak.
Sitemaps and robots.txt as code mean they can't go stale, because they're generated from the same data your pages render from.
Structured data is worth doing even when it feels like busywork. Rich results are one of the few SEO wins you can verify directly in search results.
Always verify with curl or view-source, not just dev tools. Client-side-only metadata is invisible to crawlers that don't execute JS reliably.

None of this requires a rewrite. If you're trying to optimize Next.js for SEO on an existing project, you can ship generateMetadata, sitemap.ts, and one JSON-LD block in an afternoon and see the difference in Search Console within a week.

If you want to try this approach end to end, here's the repo: https://ccbd.dev/blog/how-to-optimize-nextjs-for-seo-with-power-seo-core

Your Turn

What's the most annoying Next.js SEO bug you've run into, and how long did it take you to find it? Drop it in the comments, I'm collecting horror stories.

Next.js Redirects Are Silently Killing SEO (Here's How to Fix It)

Mitu Das — Thu, 25 Jun 2026 08:42:04 +0000

I spent three hours debugging why a perfectly written blog post couldn't get indexed by Google. No errors. No console warnings. The dev server was fine. The problem? A silent redirect chain (old URL → new slug → canonical slug) that was bleeding link equity at every hop and confusing the crawler enough to give up.

The fix was under 20 lines of code. But finding what to fix required understanding something most Next.js tutorials skip entirely: redirects and SEO are deeply coupled, and the defaults Next.js ships with are not enough for production.

Here's what I learned, and how you can audit and fix this in your own app.

Why Next.js Redirects Break SEO More Than You Think

Next.js makes setting up redirects easy. Almost too easy. You drop something like this into next.config.js and move on:

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-blog/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
    ]
  },
}

That looks fine. And for a single hop, it mostly is. The problems start when:

You've accumulated redirects over time and some of them chain (A → B → C)
You have both a next.config.js redirect and a <meta http-equiv="refresh"> somewhere in the component tree
Your canonical tags point to URLs that themselves redirect
You migrated domains and your sitemap still lists the old URLs

Google's crawler follows up to 5 redirect hops before giving up, but it discounts PageRank at each step. A chain of three redirects can lose 15–25% of the equity that URL carried. More importantly, if your canonical URL redirects, Google may simply choose a different canonical, and that choice won't be yours.

Auditing Your Redirect Chain Before Writing Any Code

Before touching code, run an audit. The goal is to find chains, loops, and mismatches between your redirects and your canonical tags.

Step 1: Export your current redirects

If you have more than a handful, pull them into a flat array you can inspect:

// scripts/audit-redirects.js
const { execSync } = require('child_process')
const config = require('../next.config.js')

async function main() {
  const redirects = await config.redirects()
  const chains = []

  const destinationSet = new Set(redirects.map(r => r.destination))

  for (const redirect of redirects) {
    if (destinationSet.has(redirect.source)) {
      chains.push(`CHAIN DETECTED: ${redirect.source} → ${redirect.destination} → ...`)
    }
  }

  if (chains.length === 0) {
    console.log('✅ No redirect chains found')
  } else {
    console.log('⚠️  Redirect chain issues:')
    chains.forEach(c => console.log('  ', c))
  }
}

main()

Run it with node scripts/audit-redirects.js. It won't catch everything, but it surfaces the most common failure mode: a source URL that appears elsewhere as a destination.

Step 2: Validate your canonical tags match your final URLs

A canonical pointing to /blog/old-slug when the actual page is /blog/new-slug is one of the easiest mistakes to make during a migration. Grep your components for hardcoded canonical values and make sure they match your redirect destinations, not your sources.

Handling Redirects at the Right Layer

There are three places Next.js can redirect a user. Picking the wrong one hurts performance and SEO.

Layer	Use For	SEO Behavior
`next.config.js`	Permanent structural changes	301/308, fast, crawler-friendly
Middleware (`middleware.ts`)	Dynamic/conditional logic	Can be 307; be explicit about status
Page-level (`getServerSideProps`)	Auth-gated pages	302 unless you set `permanent: true`

The mistake developers make is using middleware for everything because it's flexible. But middleware redirects are 307 (temporary) by default meaning crawlers won't transfer link equity. You have to be explicit:

// middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
  if (request.nextUrl.pathname === '/old-pricing') {
    const url = request.nextUrl.clone()
    url.pathname = '/pricing'

    // Be explicit 308 is permanent redirect for non-GET methods
    return NextResponse.redirect(url, { status: 308 })
  }
}

If your redirect is permanent and structural, keep it in next.config.js. Only reach for middleware when you need runtime logic.

Automating Redirect Management with a Library

Once a project grows past ~20 redirects, managing them by hand in next.config.js becomes error-prone. You lose track of what redirected where, old entries never get cleaned up, and chains appear silently.

This is where a dedicated redirect management library pays off. One option I've been using is @power-seo, which wraps Next.js redirect config with validation and chain detection baked in.

Install it:

npm install @power-seo

Then update your config:

// next.config.js
const { withPowerSEO } = require('@power-seo')

module.exports = withPowerSEO({
  redirects: [
    { from: '/old-blog/:slug', to: '/blog/:slug', permanent: true },
    { from: '/pricing-old', to: '/pricing', permanent: true },
  ],
  // Throws a build error if it detects redirect chains
  strict: true,
})

The strict: true flag is the part I actually care about it will fail your build if it detects a redirect chain. That's exactly the kind of guardrail that prevents the 3-hour debugging session I described at the start.

It also handles canonical injection based on your redirect map, which closes the loop between your structural redirects and your <head> metadata. You can read more about the approach in this writeup on the CCBD dev blog.

Key Takeaways

Redirect chains are the silent killer. A → B → C loses PageRank at every hop and can cause crawlers to choose their own canonical not yours.
Layer matters for status codes. next.config.js gives you 301/308 automatically. Middleware defaults to 307. Always be explicit about permanent when you mean it.
Your canonical tags must match your final destinations, not your redirect sources. Audit them after every migration.
Build-time validation beats runtime debugging. Whether you use a library or write your own chain-detection script, catching redirect problems before deploy is dramatically cheaper than hunting them in production.

What's Your Setup?

How are you managing redirects at scale? I'm curious whether most teams keep them in next.config.js long-term, or eventually migrate to a CMS-driven approach or middleware. And have you ever been burned by a silent redirect chain in production?

Drop your war stories in the comments this is one of those problems where everyone has a slightly different version of the same painful lesson.

I Stopped Exporting GSC CSVs Every Monday. Here's the Automation That Replaced It

Mitu Das — Sun, 21 Jun 2026 17:46:51 +0000

Every Monday for two years, I opened Search Console, clicked "Export," waited for the CSV, dumped it into a spreadsheet, and manually compared it to last week's numbers. One Monday I timed it: 47 minutes, just to answer "did anything break?"

It turns out the Search Console API can answer that question in about 4 seconds. This post walks through building a small automation that pulls your data, flags regressions, and runs an SEO health checklist, no dashboard subscription required.

Why the GSC UI Isn't Built for Repeated Checks

The Search Console web interface is fine for a one-off look, but it's actively bad for tracking change over time. It shows you 16 months of data, but comparing "this week vs last week" requires manually adjusting two date ranges and squinting at two different tables. There's no alerting, no historical diffing, and exports cap out at 1,000 rows.

The actual data is much richer than the UI exposes. The Search Console API gives you query-level, page-level, and device-level metrics, and you can pull as much history as Google retains (16 months) in a single call.

Here's the minimal setup to query it directly with a service account. No OAuth consent screen dance required if you're just automating your own properties.

npm install googleapis

// gsc-client.js
const { google } = require('googleapis');

async function getSearchConsoleClient() {
  const auth = new google.auth.GoogleAuth({
    keyFile: './service-account-key.json',
    scopes: ['https://www.googleapis.com/auth/webmasters.readonly'],
  });

  return google.searchconsole({ version: 'v1', auth });
}

async function fetchSearchAnalytics(siteUrl, startDate, endDate) {
  const searchconsole = await getSearchConsoleClient();

  const res = await searchconsole.searchanalytics.query({
    siteUrl,
    requestBody: {
      startDate,
      endDate,
      dimensions: ['query', 'page'],
      rowLimit: 5000,
    },
  });

  return res.data.rows || [];
}

module.exports = { fetchSearchAnalytics };

One catch that cost me an hour: you have to add your service account's email as a user in Search Console under Settings → Users and Permissions, with at least "Restricted" access. The API key alone doesn't grant access. GSC permissions work the same for service accounts as they do for human users.

Diffing Two Weeks Automatically

Once you can pull data on demand, the real value comes from comparing periods instead of staring at one. This function pulls this week and last week, then flags pages where clicks dropped more than a threshold, which is usually what you actually care about on a Monday.

// compare-weeks.js
const { fetchSearchAnalytics } = require('./gsc-client');

function getDateRange(weeksAgo) {
  const end = new Date();
  end.setDate(end.getDate() - (weeksAgo * 7));
  const start = new Date(end);
  start.setDate(start.getDate() - 6);

  const fmt = (d) => d.toISOString().split('T')[0];
  return { startDate: fmt(start), endDate: fmt(end) };
}

async function compareWeeks(siteUrl, dropThresholdPct = 20) {
  const thisWeek = getDateRange(1);
  const lastWeek = getDateRange(2);

  const [current, previous] = await Promise.all([
    fetchSearchAnalytics(siteUrl, thisWeek.startDate, thisWeek.endDate),
    fetchSearchAnalytics(siteUrl, lastWeek.startDate, lastWeek.endDate),
  ]);

  const prevMap = new Map(
    previous.map((row) => [row.keys.join('|'), row.clicks])
  );

  const regressions = current
    .map((row) => {
      const key = row.keys.join('|');
      const prevClicks = prevMap.get(key) || 0;
      if (prevClicks < 5) return null; // ignore noise on low-volume pages

      const change = ((row.clicks - prevClicks) / prevClicks) * 100;
      if (change <= -dropThresholdPct) {
        return { page: row.keys[1], query: row.keys[0], prevClicks, clicks: row.clicks, change: change.toFixed(1) };
      }
      return null;
    })
    .filter(Boolean)
    .sort((a, b) => a.change - b.change);

  return regressions;
}

module.exports = { compareWeeks };

Run it, and instead of a spreadsheet you get a short list of exactly what to look at:

compareWeeks('https://example.com').then((regressions) => {
  console.table(regressions.slice(0, 10));
});

This is the part that actually saves time. Not having the data, but having it pre-filtered to the handful of rows that matter.

Turning It Into a Repeatable SEO Checklist

Raw click data is only half the picture. Most real regressions trace back to one of a few causes: a page got deindexed, a noindex tag slipped into a template, a canonical points somewhere wrong, or Core Web Vitals tanked after a deploy. I started scripting checks for these alongside the GSC pull so the "checklist" runs itself instead of living in my head.

// seo-checklist.js
const { fetchSearchAnalytics } = require('./gsc-client');

async function runChecklist(siteUrl, pages) {
  const results = [];

  for (const page of pages) {
    const checks = {
      page,
      indexed: await checkIndexStatus(page),
      hasCanonical: await checkCanonical(page),
      responseOk: await checkStatusCode(page),
    };
    results.push(checks);
  }

  return results.filter(
    (r) => !r.indexed || !r.hasCanonical || !r.responseOk
  );
}

async function checkStatusCode(url) {
  try {
    const res = await fetch(url, { method: 'HEAD' });
    return res.status === 200;
  } catch {
    return false;
  }
}

async function checkCanonical(url) {
  const res = await fetch(url);
  const html = await res.text();
  return /<link[^>]+rel=["']canonical["']/.test(html);
}

async function checkIndexStatus(url) {
  // Pulls last 7 days; if a previously-ranking page has zero
  // impressions, it's worth a manual URL inspection
  const rows = await fetchSearchAnalytics(url, '7daysAgo', 'today');
  return rows.length > 0;
}

module.exports = { runChecklist };

This isn't exhaustive. It won't catch everything Search Console's own URL Inspection tool can, but it catches the boring, common stuff before it becomes a Monday-morning fire drill.

When I outgrew maintaining this myself, I looked at a few open-source options instead of building a full scheduler from scratch. power-seo is one that wraps this same GSC-querying pattern with built-in regression alerts and the indexability checks above, so you don't have to hand-roll the cron job and diffing logic. It's a thin layer over the same API calls in this post, not a replacement for understanding them. Worth a look if you'd rather configure thresholds than write the diff function yourself.

What I Learned

The GSC UI and the GSC API are basically different products: The UI is for spot-checking; the API is for monitoring. If you're checking the same thing weekly, that's a sign it should be a script, not a habit.
Filter out low-traffic noise before alerting on percentage drops: A page going from 2 clicks to 1 click is a 50% drop and means nothing. Set a minimum volume threshold.
Most "ranking dropped" panics are actually technical issues:, a bad deploy, a stray noindex, a broken canonical, not algorithm changes. Check the boring stuff first.
Service account permissions in GSC are easy to forget: If your API calls return empty data instead of an error, check user permissions before you assume the query is wrong.

If you want to try this approach, here's the repo: https://ccbd.dev/blog/google-search-console-automation-i-stopped-exporting-csvs-every-monday.

Your Turn

What's the most annoying recurring SEO task you've automated (or still haven't)? I'm especially curious if anyone's solved Core Web Vitals monitoring without paying for a dashboard tool. Drop your approach in the comments.

I Spent 3 Hours Debugging Why Google Couldn't Read My Sitemap. Then I Found an SEO Sitemap Library for TypeScript That Fixed It

Mitu Das — Thu, 18 Jun 2026 10:14:21 +0000

I spent 3 hours debugging why Google Search Console kept showing "Couldn't fetch" on a sitemap that looked completely normal in my browser. The XML rendered fine. Every URL in it worked when I clicked them one by one. The actual problem was one unescaped & buried in product entry #4,312. That single character was enough to invalidate the entire file, not just that one row.

By the end of this post, you'll know how to generate a sitemap in TypeScript that can't break that way, how to scale it past the 50,000-URL limit, and how to validate it before Google ever sees it.

Why a Hand-Rolled Sitemap Breaks Silently

Most sitemaps start the same way: map over an array of routes, template-string them into XML, write the result to a file. It works fine right up until your content includes data your team doesn't fully control: product names, blog titles, anything with an ampersand, a quote, or an angle bracket in it.

XML parsers don't gracefully skip a malformed character. They reject the whole document. Once that happens, Search Console reports every URL in that sitemap as unfetched, including the ones that had nothing to do with the actual problem.

Here's the version that looks fine and isn't:

// sitemap.ts: works in dev, fails in prod
const routes = ['/', '/about', '/products/salt-&-pepper-shakers'];

const xml = `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
${routes.map(r => `<url><loc>https://example.com${r}</loc></url>`).join('\n')}
</urlset>`;

console.log(xml);

Result: this compiles and prints output that looks like valid XML. Paste it into any XML validator and it fails on the &. That character is reserved in XML and has to be written as &. One bad product name and your whole sitemap is invalid.

Building a Sitemap That Escapes Properly

The fix is straightforward: escape every dynamic value before it goes into the XML, and include the fields Google actually still uses. Worth knowing upfront: Google has said for years that it largely ignores priority and changefreq. lastmod is the field worth getting right.

// sitemap-generator.ts
import { writeFileSync } from 'fs';

interface SitemapUrl {
  loc: string;
  lastmod?: string;
  changefreq?: 'always' | 'hourly' | 'daily' | 'weekly' | 'monthly' | 'yearly' | 'never';
  priority?: number;
}

function escapeXml(value: string): string {
  return value
    .replace(/&/g, '&amp;')
    .replace(/</g, '&lt;')
    .replace(/>/g, '&gt;')
    .replace(/"/g, '&quot;')
    .replace(/'/g, '&apos;');
}

function buildSitemap(hostname: string, urls: SitemapUrl[]): string {
  const entries = urls
    .map(({ loc, lastmod, changefreq, priority }) => {
      const fullLoc = escapeXml(`${hostname}${loc}`);
      const tags = [
        lastmod ? `<lastmod>${lastmod}</lastmod>` : '',
        changefreq ? `<changefreq>${changefreq}</changefreq>` : '',
        priority !== undefined ? `<priority>${priority}</priority>` : '',
      ].join('');
      return `<url><loc>${fullLoc}</loc>${tags}</url>`;
    })
    .join('\n');

  return `<?xml version="1.0" encoding="UTF-8"?>\n<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">\n${entries}\n</urlset>`;
}

const urls: SitemapUrl[] = [
  { loc: '/', lastmod: '2026-06-01', changefreq: 'weekly', priority: 1.0 },
  { loc: '/products/salt-&-pepper-shakers', lastmod: '2026-05-28' },
];

writeFileSync('./public/sitemap.xml', buildSitemap('https://example.com', urls));

Result: the ampersand now comes out as &, the file validates cleanly, and Search Console stops flagging that route. For a five-page site or a small blog, this is genuinely enough. You don't need a dependency for this.

Scaling Past 50,000 URLs Without Crashing Your Build

The sitemap protocol caps a single file at 50,000 URLs or 50MB uncompressed. That limit hasn't moved in years, so it's safe to build automation around it. Once your catalog or CMS crosses that line, you need multiple sitemap files plus one index file that points to all of them.

// sitemap-index.ts
import { writeFileSync } from 'fs';

function chunk<T>(items: T[], size: number): T[][] {
  const chunks: T[][] = [];
  for (let i = 0; i < items.length; i += size) {
    chunks.push(items.slice(i, i + size));
  }
  return chunks;
}

function buildSitemapIndex(hostname: string, filenames: string[]): string {
  const entries = filenames
    .map((file) => `<sitemap><loc>${hostname}/${file}</loc></sitemap>`)
    .join('\n');
  return `<?xml version="1.0" encoding="UTF-8"?>\n<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">\n${entries}\n</sitemapindex>`;
}

const allUrls: SitemapUrl[] = await fetchAllProductUrls(); // could be 200,000+
const batches = chunk(allUrls, 45000); // stay safely under the 50k cap
const filenames: string[] = [];

batches.forEach((batchUrls, i) => {
  const filename = `sitemap-${i}.xml`;
  writeFileSync(`./public/${filename}`, buildSitemap('https://example.com', batchUrls));
  filenames.push(filename);
});

writeFileSync('./public/sitemap-index.xml', buildSitemapIndex('https://example.com', filenames));

Result: a 200,000-product catalog now produces several small sitemap files instead of one giant file that either gets rejected outright or times out mid-fetch.

Where I Stopped Writing This From Scratch Every Project

The functions above cover most real-world cases. What they don't cover: keeping memory flat when you're streaming from a database cursor instead of an in-memory array, image/video sitemap extensions, validating entries in CI before they ship, and running on edge runtimes that don't have fs or path at all.

Last time I needed this for a catalog with six figures of product pages, I reached for @power-seo/sitemap instead of rewriting these utilities again. It's the same chunking and escaping logic above, packaged with the parts that get tedious to maintain.

Streaming keeps memory flat when pulling from a cursor instead of building one giant string:

import { streamSitemap } from '@power-seo/sitemap';

const urlCursor = db.collection('products').find().stream(); // async iterable

const stream = streamSitemap('https://example.com', urlCursor);
for await (const chunk of stream) {
  response.write(chunk);
}
response.end();

And validating entries before they ever reach a deploy:

import { validateSitemapUrl } from '@power-seo/sitemap';

const result = validateSitemapUrl({ loc: '/blog/post-1', priority: 1.8 });

if (!result.valid) {
  console.error(result.errors); // ['priority must be between 0.0 and 1.0']
  process.exit(1); // fail the build instead of shipping a bad value
}

Result: catching a priority of 1.8 (the spec caps it at 1.0) in CI costs you a failed build. Shipping it costs you nothing visible immediately, which is exactly the problem: it just quietly erodes how much Google trusts your file over time. It's published on npm as @power-seo/sitemap, has no runtime dependencies beyond its own core package, and avoids Node-specific APIs internally, which matters if you're deploying to Cloudflare Workers or Vercel Edge instead of a traditional server.

My Pre-Deploy SEO Checklist for Sitemaps

Here's the short version: the actual SEO checklist I run before shipping anything sitemap-related now:

Escape every dynamic value: One unescaped &, <, or ' can invalidate the whole file, not just that entry.
Stop optimizing priority and changefreq: Google has said for years it largely ignores both. Spend that energy on accurate lastmod dates instead.
Build the 50,000-URL split logic before you need it: Retrofitting a sitemap index after Search Console starts throwing errors is a worse afternoon than building it up front.
Validate in CI, not in production: A bad URL caught at build time is a five-second fix. The same bug caught a week later is a week of degraded crawl trust you can't get back instantly.

If you want to try this approach, here's the repo: https://ccbd.dev/blog/seo-sitemap-library-for-typescript-a-complete-guide-to-power-seositemap.

Have you ever shipped a sitemap that silently broke without you noticing? What caught it for you: Search Console, an annoyed client, or pure luck? And if you've used a different TypeScript sitemap tool, I'd genuinely like to know how it compares. Drop your sitemap war stories in the comments.

Affordable Ecommerce Website Development: 4 Technical Decisions That Saved Me Weeks of Rework

Mitu Das — Wed, 17 Jun 2026 16:11:26 +0000

I thought building an ecommerce store on a tight budget would be the easy part.

The real challenge wasn't coding the product pages or setting up payments—it was fixing all the little issues that appeared after launch. Slow category pages. Duplicate metadata. Poor crawlability. Inconsistent performance across devices.

The surprising part?

Most of these problems weren't caused by the framework. They were caused by small architectural decisions made early in development.

In this article, I'll walk through four practical techniques I now use for affordable ecommerce website development, including code examples you can apply immediately. These fixes improved performance, simplified maintenance, and helped search engines understand the site structure much better.

Why Ecommerce Sites Become Slow Faster Than You Expect

One of the most common mistakes in ecommerce projects is loading everything on page render.

When a store has hundreds or thousands of products, unnecessary API requests and large payloads can quickly hurt performance.

Instead of fetching all products, fetch only what's needed.

// Express.js API example

app.get("/products", async (req, res) => {
  const page = Number(req.query.page) || 1;
  const limit = 20;

  const products = await Product.find()
    .skip((page - 1) * limit)
    .limit(limit);

  res.json(products);
});

On the frontend:

async function loadProducts(page = 1) {
  const response = await fetch(`/products?page=${page}`);
  const products = await response.json();

  renderProducts(products);
}

Result:

Smaller API responses
Faster page rendering
Better mobile experience
Reduced server costs

For affordable ecommerce projects, optimizing requests early prevents expensive scaling problems later.

Why Search Engines Struggle With Product Pages

Many ecommerce stores generate pages dynamically but forget to generate unique metadata.

As a result, dozens of pages end up sharing the same title and description.

A simple metadata generator solves this.

export function generateMetadata(product) {
  return {
    title: `${product.name} | My Store`,
    description: product.shortDescription,
    openGraph: {
      title: product.name,
      description: product.shortDescription,
      images: [product.image]
    }
  };
}

Using the helper:

const metadata = generateMetadata(product);

console.log(metadata.title);
console.log(metadata.description);

Result:

Better search visibility
Improved click-through rates
Cleaner social sharing previews
Easier indexing for search engines

While debugging metadata issues on one project, I used a lightweight analysis tool to inspect missing tags and duplicate page signals before deployment. It helped identify pages that looked fine visually but were missing important SEO information.

In situations like that, tools available through npm can make validation much faster during development rather than after launch.

Organizing Product Data Without Creating Maintenance Chaos

As ecommerce catalogs grow, developers often duplicate logic across multiple components.

The result is inconsistent pricing displays, duplicated formatting code, and difficult updates.

Centralizing transformation logic helps.

export function formatProduct(product) {
  return {
    id: product.id,
    name: product.name,
    price: `$${product.price.toFixed(2)}`,
    inStock: product.stock > 0
  };
}

Usage:

const formattedProduct = formatProduct({
  id: 1,
  name: "Wireless Mouse",
  price: 29.99,
  stock: 12
});

console.log(formattedProduct);

Result:

Cleaner components
Consistent product presentation
Easier testing
Faster feature development

This becomes especially important when managing large inventories where the same product data appears across category pages, search results, recommendations, and checkout flows.

Improving Core Web Vitals With Lazy Loading

Images are usually the largest assets on ecommerce pages.

Loading every image immediately wastes bandwidth and delays rendering.

Modern browsers make lazy loading incredibly easy.

<img
  src="/images/product-1.jpg"
  alt="Product Image"
  loading="lazy"
  width="600"
  height="600"
/>

For React:

function ProductCard({ product }) {
  return (
    <img
      src={product.image}
      alt={product.name}
      loading="lazy"
      width="400"
      height="400"
    />
  );
}

Result:

Faster page loads
Better Lighthouse scores
Improved Core Web Vitals
Reduced bandwidth usage

For ecommerce stores with hundreds of product images, this single change can create noticeable performance gains almost immediately.

What I Learned

After working through several ecommerce builds, a few lessons consistently stand out:

Performance problems usually start with architecture decisions, not server capacity.
Duplicate metadata is easier to prevent than fix after hundreds of pages are indexed.
Centralized data transformation saves enormous maintenance effort later.
Small optimizations like lazy loading often deliver bigger wins than major refactors.

One mistake I repeatedly see is focusing on new features before measuring performance, crawlability, and maintainability. The earlier these areas are addressed, the more affordable development remains as the store grows.

A useful mindset shift is treating SEO, performance, and maintainability as part of development—not as post-launch tasks.

If you want to try this approach, here's the repo:
https://ccbd.dev/blog/affordable-ecommerce-website-development-a-real-cost-breakdown

Final Thoughts

Affordable ecommerce website development isn't really about spending less money.

It's about making technical decisions that prevent expensive problems later.

Have you ever run into a performance, SEO, or architecture issue that seemed small at first but became a major problem after launch?

What’s your current approach to building scalable ecommerce projects?

Your React App Is a Blank Page to Googlebot. Fix It in 15 Minutes.

Mitu Das — Mon, 15 Jun 2026 10:11:49 +0000

I shipped a React app, submitted it to Google Search Console, and watched it sit at zero impressions for six weeks. No crawl errors. No penalty. Just… nothing. Turns out, my entire app was rendering as a blank <div id="root"></div> to Googlebot. Classic. If you're building React SPAs and ignoring SEO infrastructure, this article will save you weeks of guesswork. We'll cover why React breaks SEO by default, how to audit it properly, how to fix the most common issues with real code, and how to track SEO health as part of your dev workflow.

Why React Kills Your SEO (And You Won't Notice Until It's Too Late)

Google's crawler is better at executing JavaScript than it used to be but it's still unreliable, slow, and inconsistent. The problem isn't just rendering. It's that React SPAs typically:

Render a mostly empty HTML shell until JS loads
Set <title> and <meta> tags dynamically, after the initial parse
Generate no meaningful <h1> or semantic structure until client-side hydration
Have zero <link rel="canonical"> tags by default

Google might eventually see your content. Or it might cache the blank shell. You won't know which until you're three months into a traffic investigation.

The fix isn't always SSR or Next.js (though those help). Often, it's just fixing the metadata layer and auditing what Googlebot actually receives.

Step 1: Audit What Google Actually Sees

Before fixing anything, you need to know what Googlebot is getting. The lazy way is Google Search Console's "URL Inspection" tool. The developer way is to fetch your page the same way a bot does.

curl -A "Googlebot/2.1 (+http://www.google.com/bot.html)" https://yoursite.com | grep -E "<title>|<meta|<h1"

If this returns nothing useful or just your index.html shell you have a rendering problem.

For a more structured audit, write a quick Node script that checks the critical SEO fields:

// audit-seo.mjs
import { JSDOM } from 'jsdom';

async function auditPage(url) {
  const res = await fetch(url);
  const html = await res.text();
  const dom = new JSDOM(html);
  const doc = dom.window.document;

  const checks = {
    title: doc.querySelector('title')?.textContent || '❌ MISSING',
    description: doc.querySelector('meta[name="description"]')?.getAttribute('content') || '❌ MISSING',
    canonical: doc.querySelector('link[rel="canonical"]')?.getAttribute('href') || '❌ MISSING',
    h1: doc.querySelector('h1')?.textContent || '❌ MISSING',
    ogTitle: doc.querySelector('meta[property="og:title"]')?.getAttribute('content') || '❌ MISSING',
  };

  console.table(checks);
}

auditPage('https://yoursite.com');

npm install jsdom
node audit-seo.mjs

This gives you a fast, repeatable baseline. Run it against your staging URL before every deploy.

Step 2: Fix the Metadata Layer With React Helmet (or the Modern Alternative)

If you're on React 18+ with React Router, react-helmet-async is the standard approach for dynamic <head> management:

npm install react-helmet-async

Wrap your app:

// main.jsx
import { HelmetProvider } from 'react-helmet-async';

ReactDOM.createRoot(document.getElementById('root')).render(
  <HelmetProvider>
    <App />
  </HelmetProvider>
);

Then in each route component:

// pages/BlogPost.jsx
import { Helmet } from 'react-helmet-async';

export default function BlogPost({ post }) {
  return (
    <>
      <Helmet>
        <title>{post.title} | My Blog</title>
        <meta name="description" content={post.excerpt} />
        <link rel="canonical" href={`https://yoursite.com/blog/${post.slug}`} />
        <meta property="og:title" content={post.title} />
        <meta property="og:description" content={post.excerpt} />
        <meta property="og:type" content="article" />
      </Helmet>

      <article>
        <h1>{post.title}</h1>
        {/* ... */}
      </article>
    </>
  );
}

Four lines of Helmet config was literally all it took to fix my blank-shell problem. Google saw a title, a description, a canonical URL and started indexing within two weeks.

Note: If you're on Next.js 13+ App Router, use the built-in metadata export instead of Helmet. Same concept, different API.

Step 3: Build a React SEO Checklist Into Your CI Pipeline

The real problem isn't fixing SEO once. It's that a junior dev ships a new page in two weeks and forgets the <title> tag. You need a React SEO checklist that runs automatically.

Here's a lightweight Playwright test you can add to your CI:

// tests/seo.spec.js
import { test, expect } from '@playwright/test';

const routes = ['/', '/about', '/blog', '/contact'];

for (const route of routes) {
  test(`SEO basics: ${route}`, async ({ page }) => {
    await page.goto(`https://yoursite.com${route}`);

    // Title must exist and be meaningful
    const title = await page.title();
    expect(title.length).toBeGreaterThan(10);
    expect(title.length).toBeLessThan(70);

    // Meta description
    const desc = await page.getAttribute('meta[name="description"]', 'content');
    expect(desc).not.toBeNull();
    expect(desc.length).toBeGreaterThan(50);

    // Canonical
    const canonical = await page.getAttribute('link[rel="canonical"]', 'href');
    expect(canonical).not.toBeNull();

    // One H1 per page
    const h1s = await page.locator('h1').all();
    expect(h1s.length).toBe(1);
  });
}

This runs against your deployed URL and fails the build if any page is missing critical SEO tags. It's cheap, fast, and catches regressions before Google does.

Step 4: Track SEO Health as a Dev Metric (Not an Afterthought)

The above covers static checks. But SEO also means tracking what changes over time Core Web Vitals, crawl coverage, index status.

For this I've been using power-seo, a free React SEO tracking tool that hooks into your app and surfaces SEO issues at the component level during development. It's not a cloud service it runs locally and stays GDPR-compliant because nothing leaves your machine.

npm install power-seo

// Wrap your router in development
import { SEOProvider } from 'power-seo';

function App() {
  return (
    <SEOProvider debug={process.env.NODE_ENV === 'development'}>
      <Router>
        <Routes>
          {/* your routes */}
        </Routes>
      </Router>
    </SEOProvider>
  );
}

In dev mode, it overlays a panel showing missing tags, duplicate titles, and viewport issues for the current route. In production, the provider strips itself out zero bundle impact.

It's one of those tools that earns its place not by doing something magical, but by making the checklist you'd otherwise do manually into something automatic.

What I Learned

The blank shell problem is still real in 2025. Don't assume Google executes your JS. Audit with curl first, optimize second.
Dynamic metadata is table stakes. Every route needs its own <title>, <meta description>, and <canonical>. react-helmet-async makes this straightforward.
Automate your React SEO checklist. Playwright SEO tests in CI catch regressions before they cost you rankings. Set them up once; forget about them.
Track SEO health in dev, not just in prod. Finding a missing <h1> in a dev overlay is 100x cheaper than finding it three months later in Search Console.

If you want to try this approach, here's the repo: https://ccbd.dev/blog/free-react-seo-tracking-tool-thats-actually-gdpr-ready.

Your Turn

What's the most painful SEO bug you've shipped with a React app? Blank titles? Duplicate canonicals? A whole subdomain accidentally set to noindex? Drop it in the comments I'm genuinely curious whether the blank-shell issue is as common as I think, or if everyone else already knew to check for it and I was just late to the party.

My React App Was Invisible to Google - Here's How I Fixed It with an SEO API

Mitu Das — Thu, 11 Jun 2026 09:33:47 +0000

I spent one day debugging why Google couldn't index my Next.js app. Lighthouse gave it a 100. The HTML looked fine. Turns out, I was rendering all my <meta> tags client-side - which means crawlers saw an empty <head> before JavaScript ran. The fix was 4 lines of code in generateMetadata(). But finding all the other SEO gaps? That needed an API.

This article is a working guide to SEO API integration for Next.js: how to programmatically audit, generate, and validate metadata so you're not playing whack-a-mole with Lighthouse every deploy.

Why "Just Add a Meta Tag" Isn't Enough Anymore

Modern SEO has three layers that are easy to miss when you're heads-down in product code:

Static metadata - <title>, <meta name="description">, canonical URLs
Dynamic/social metadata - Open Graph, Twitter Cards, per-page og:image
Structured data - JSON-LD schemas that power rich results in Google Search

Most tutorials stop at layer one. But if a blog post shares badly on LinkedIn (wrong og:image) or your product page doesn't show a star rating in search results (missing JSON-LD), you're leaving clicks on the table.

Here's a systematic way to handle all three.

1. Fix the Root Cause: Server-Side Metadata in Next.js App Router

First, make sure your metadata is actually in the HTML that crawlers receive - not injected after hydration.

In the App Router (/app directory), use generateMetadata instead of touching <Head> in a component:

// app/blog/[slug]/page.tsx
import type { Metadata } from 'next'

type Props = { params: { slug: string } }

export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const post = await fetchPost(params.slug)

  return {
    title: post.title,
    description: post.excerpt,
    openGraph: {
      title: post.title,
      description: post.excerpt,
      images: [{ url: post.ogImage, width: 1200, height: 630 }],
      type: 'article',
      publishedTime: post.publishedAt,
    },
    twitter: {
      card: 'summary_large_image',
      title: post.title,
      images: [post.ogImage],
    },
    alternates: {
      canonical: `https://yoursite.com/blog/${params.slug}`,
    },
  }
}

export default function BlogPost({ params }: Props) {
  // your component
}

This runs on the server. Crawlers get the full <head> immediately. Problem one: solved.

Result: curl https://yoursite.com/blog/my-post | grep '<title>' now returns your actual title instead of a blank tag.

2. Automate Structured Data with JSON-LD

Google uses structured data (JSON-LD) to power rich results: breadcrumbs, article bylines, product ratings, FAQ dropdowns. Writing it by hand for every page type is error-prone. Here's a reusable component:

// components/JsonLd.tsx
type JsonLdProps = {
  data: Record<string, unknown>
}

export function JsonLd({ data }: JsonLdProps) {
  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(data) }}
    />
  )
}

// Usage in a blog post layout
import { JsonLd } from '@/components/JsonLd'

export default function BlogLayout({ post, children }) {
  const articleSchema = {
    '@context': 'https://schema.org',
    '@type': 'Article',
    headline: post.title,
    description: post.excerpt,
    author: { '@type': 'Person', name: post.author },
    datePublished: post.publishedAt,
    dateModified: post.updatedAt,
    image: post.ogImage,
  }

  return (
    <>
      <JsonLd data={articleSchema} />
      {children}
    </>
  )
}

Test it immediately with Google's Rich Results Test. Paste your URL - if the JSON-LD is server-rendered, it'll parse it correctly.

Result: Your articles can start showing author and date information in Google Search results.

3. Integrate an SEO API to Audit at Scale

Manual checks work for a page or two. But what happens when you have 200 blog posts, 50 product pages, and a new deploy every day? You need programmatic auditing.

This is where an SEO API earns its keep. I started using @power-seo after finding it while searching for an npm package that could run structured SEO checks without spinning up a headless browser for every URL.

Install it:

npm install @power-seo

Then hook it into a script you can run in CI:

// scripts/seo-audit.ts
import { createClient } from '@power-seo'

const client = createClient({ apiKey: process.env.POWER_SEO_API_KEY })

const pagesToAudit = [
  'https://yoursite.com/',
  'https://yoursite.com/blog',
  'https://yoursite.com/pricing',
]

async function runAudit() {
  for (const url of pagesToAudit) {
    const result = await client.audit(url)

    const issues = result.issues.filter(i => i.severity === 'error')
    if (issues.length > 0) {
      console.error(`\n❌ SEO errors on ${url}:`)
      issues.forEach(i => console.error(`  - [${i.code}] ${i.message}`))
      process.exit(1) // Fail the CI build
    }

    console.log(`✅ ${url} - score: ${result.score}/100`)
  }
}

runAudit()

Add it to your package.json:

"scripts": {
  "seo:audit": "ts-node scripts/seo-audit.ts"
}

And in your GitHub Actions workflow:

- name: SEO Audit
  run: npm run seo:audit
  env:
    POWER_SEO_API_KEY: ${{ secrets.POWER_SEO_API_KEY }}

Now a missing <title> or broken canonical URL blocks the deploy - the same way a TypeScript error would.

Result: SEO regressions get caught in PRs, not three weeks later when your traffic drops.

4. Your React SEO Checklist - Runnable, Not Just Readable

This React SEO checklist isn't a PDF you'll forget about. It's a test file you keep in your repo:

// __tests__/seo.test.ts
import { JSDOM } from 'jsdom'
import { readFileSync } from 'fs'

// Run `next build && next export` first, then test the static HTML
function getHeadFrom(htmlPath: string) {
  const html = readFileSync(htmlPath, 'utf8')
  const dom = new JSDOM(html)
  return dom.window.document.head
}

describe('Homepage SEO', () => {
  const head = getHeadFrom('.next/server/app/index.html')

  it('has a non-empty <title>', () => {
    const title = head.querySelector('title')?.textContent
    expect(title).toBeTruthy()
    expect(title!.length).toBeLessThan(60)
  })

  it('has a meta description under 160 chars', () => {
    const desc = head.querySelector('meta[name="description"]')?.getAttribute('content')
    expect(desc).toBeTruthy()
    expect(desc!.length).toBeLessThan(160)
  })

  it('has og:image with absolute URL', () => {
    const ogImage = head.querySelector('meta[property="og:image"]')?.getAttribute('content')
    expect(ogImage).toMatch(/^https?:\/\//)
  })

  it('has canonical link', () => {
    const canonical = head.querySelector('link[rel="canonical"]')?.getAttribute('href')
    expect(canonical).toBeTruthy()
  })

  it('has JSON-LD structured data', () => {
    const jsonLd = head.querySelector('script[type="application/ld+json"]')
    expect(jsonLd).not.toBeNull()
    // Validate it's parseable
    expect(() => JSON.parse(jsonLd!.textContent!)).not.toThrow()
  })
})

Run this in CI. If any assertion fails, the deploy stops.

What I Learned

Client-side <Head> is the #1 silent SEO killer in React apps. Always use generateMetadata in Next.js 13+ or getServerSideProps/getStaticProps + next/head in the Pages Router.
Structured data is underhyped. Most devs ignore JSON-LD until their competitors' results start showing star ratings and theirs don't.
SEO regressions are just bugs. Treating metadata as testable, CI-enforced output (not a manual checklist) is the mindset shift that makes this maintainable.
Automate the audit, not just the fix. Tools like @power-seo let you catch issues across hundreds of URLs without manual Lighthouse runs - worth it once your site grows past a handful of pages.

If you want to try this approach end-to-end, here's the full write-up with additional examples: https://ccbd.dev/blog/seo-api-integration-for-nextjs-the-complete-developer-guide.

What's Your SEO Setup?

Are you handling metadata manually, using a CMS that generates it for you, or do you have it in CI? I'm curious whether anyone has gone further - like auto-generating og:image screenshots per page with a Puppeteer lambda.

Drop your approach in the comments - genuinely interested in what's working at scale.