DEV Community: Mitu Das

Open Source SEO Tools for Developers: Fixing React SEO in 4 Lines of Code

Mitu Das — Sat, 05 Sep 2026 11:16:50 +0000

I built a beautiful React SPA for a client. Fast, animated, great Lighthouse score. Then I searched Google for our own brand name.

Nothing. No description. No rich snippet. Just a bare title tag and a blank meta description, because Googlebot was reading the raw HTML shell before React ever mounted.

The fix, once I found it, was four lines of code. But getting there meant understanding why client-side rendering breaks React SEO in the first place, and which open source SEO tools for developers can actually verify, not just claim, that your app is crawlable. That's what this post covers: diagnosing the problem, fixing meta tags and structured data with open source packages, and validating the result yourself instead of trusting a paid dashboard's word for it.

Why Googlebot Sees an Empty React Page (And How to Check)

Googlebot does render JavaScript, but it does so in a second, delayed rendering pass, and a lot of other crawlers (Bing, LinkedIn, Twitter/X, Slack unfurlers, most SEO scrapers) don't execute JS at all. They read the raw HTML response. If your <title> and meta description are injected client-side via useEffect or a hook, those crawlers see nothing. This is the core React SEO problem almost every SPA runs into.

You can check this yourself without any tool:

curl -s https://your-site.com | grep -A 2 "<title"

If that returns an empty or generic title while your browser shows something different, you've confirmed the problem. This is the single most important open source SEO tool you have: curl. It shows you exactly what a non-JS crawler sees.

Result: Confirmed. The raw HTML had <title>React App</title> and no meta description at all, despite the rendered page looking correct.

Fixing React SEO Meta Tags for SSR and SPA Apps

The fix depends on your rendering strategy. If you're on Next.js App Router, the framework already gives you server-rendered metadata. The trick is generating it dynamically per route instead of hardcoding a static title.

// app/blog/[slug]/page.tsx
export async function generateMetadata({ params }) {
  const post = await getPost(params.slug);
  return {
    title: post.title,
    description: post.excerpt,
    openGraph: {
      type: 'article',
      images: [{ url: post.coverImage, width: 1200, height: 630 }],
    },
  };
}

If you're on a client-rendered SPA (Vite, CRA, plain React Router) with no SSR at all, you have two real options: add a prerendering step (like vite-plugin-ssr or a static prerender at build time), or use a library that manages document head tags reactively so at least browsers and post-JS crawlers get correct tags. This is where a small open source package like @power-seo/react is genuinely useful for React SEO. It's a thin wrapper around setting title/meta/OG tags per route, nothing magical:

import { SEO } from '@power-seo/react';

function BlogPage({ post }) {
  return (
    <>
      <SEO
        title={post.title}
        description={post.excerpt}
        canonical={`https://example.com/blog/${post.slug}`}
      />
      <article>{/* content */}</article>
    </>
  );
}

Result: curl now shows a populated <title> and <meta name="description"> for SSR routes. For pure client-rendered pages, this only fixes what browsers and JS-executing crawlers see. It does not fix the Googlebot-only-crawlers-HTML problem. Be honest with yourself about which category your app falls into before you declare victory.

Structured Data: The Part Every React SEO Checklist Skips

Meta tags get your page indexed. Structured data (JSON-LD) gets you rich results: star ratings, FAQ dropdowns, article bylines in the SERP. Most tutorials show you a hand-written JSON-LD blob and call it done, but hand-written schema breaks silently. A typo in a property name doesn't throw an error, it just quietly fails Google's Rich Results Test months later.

Here's a validated approach using typed builders instead of raw objects:

import { article, faqPage, schemaGraph, toJsonLdString, validateSchema } from '@power-seo/schema';

const graph = schemaGraph([
  article({
    headline: 'My Blog Post',
    datePublished: '2026-01-15',
    author: { name: 'Jane Doe', url: 'https://example.com/authors/jane-doe' },
  }),
  faqPage([
    { question: 'What is SEO?', answer: 'Search engine optimization.' },
  ]),
]);

const { valid, issues } = validateSchema(graph);
if (!valid) console.error(issues);

const html = toJsonLdString(graph);

The validateSchema() step is the actual value here. It catches malformed schema at build time or in CI, instead of you finding out three months later that your FAQ rich results silently vanished.

Result: Ran it through Google's Rich Results Test after deploying. FAQ and Article types both validated with no warnings.

Open Source SEO Tools for Developers: Auditing Your Site Instead of Paying for a Dashboard

Paid SEO tools like Screaming Frog or Ahrefs are genuinely good at crawling thousands of pages, but for a single Next.js or React project, you don't need a subscription to catch basic issues: orphan pages, missing alt text, oversized images, thin content. You can run these checks programmatically and even fail your CI pipeline on them:

import { auditPage } from '@power-seo/audit';
import { analyzeContent } from '@power-seo/content-analysis';

const audit = auditPage({
  url,
  title,
  metaDescription,
  headings,
  wordCount,
  focusKeyphrase,
});

const content = analyzeContent({ title, metaDescription, content, focusKeyphrase });

if (audit.score < 70) {
  console.error(`Audit score too low: ${audit.score}/100`);
  process.exit(1);
}

Result: Wired this into a GitHub Action. It now fails the build if a new blog post ships without a meta description or with an SEO score under 70. Caught two missing descriptions before they ever went live.

What I Learned About React SEO

curl before anything else. Before reaching for a tool, check what a non-JS crawler actually sees. Most React SEO bugs are diagnosed in 30 seconds this way.
SSR and CSR need different fixes. A client-side meta tag library helps browsers and JS-crawlers, but it won't fix Googlebot's HTML-only crawlers or non-Google platforms. Know which problem you're solving.
Validate structured data, don't just write it. Hand-written JSON-LD fails silently. A validation step in your build or CI catches it before Google does.
SEO checks belong in CI, not a quarterly audit. Catching a missing meta description in a PR review is free. Catching it three months later after it's cost you rankings is not.

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

Let's Talk

What's your team's actual process for catching React SEO regressions before they ship: manual checklist, CI gate, or nothing until someone notices traffic dropped? I'm curious whether anyone's automated this beyond a single Lighthouse score in their pipeline.

React vs WordPress SEO: Why Your SPA Is Invisible to Google

Mitu Das — Tue, 01 Sep 2026 10:37:28 +0000

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

Turns out, the problem wasn't Google. It was me assuming client-side rendering works like a WordPress page, where the HTML is just... there. It's not. If you've ever wondered why your React site tanks in search while a five-year-old WordPress blog outranks it with zero effort, you've run into the core issue in the React vs WordPress SEO debate. In this post I'll walk through why that gap exists and the concrete React SEO fixes that close it.

React vs WordPress SEO: Why WordPress Wins by Default

WordPress serves fully rendered HTML on the first request. The crawler hits your server, gets a complete <title>, <meta description>, headings, and body text. No JavaScript required. Nothing to wait for, nothing to execute.

React (and most SPA frameworks) ship an almost-empty HTML shell:

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

Everything meaningful (your content, your meta tags, your headings) gets injected after JavaScript runs. Google's crawler can execute JS, but it does so in a second wave, sometimes days later, with a limited rendering budget. Other bots (Bing, LinkedIn, Slack previews, some AI crawlers) often don't execute JS at all. Result: your beautifully designed page shows up as a blank card everywhere except a browser.

This isn't a React flaw, it's a rendering-strategy mismatch. The fix is making sure critical SEO content exists in the initial HTML response, not just in the post-hydration DOM.

React SEO Fix #1: Server-Side Render or Statically Generate Your Critical Pages

If you're on plain Create React App with client-only rendering, the highest-leverage fix is moving to a framework that renders HTML on the server or at build time.

With Next.js, a blog post page can look like this:

// app/blog/[slug]/page.js
export async function generateMetadata({ params }) {
  const post = await getPost(params.slug);
  return {
    title: post.title,
    description: post.excerpt,
    openGraph: {
      title: post.title,
      description: post.excerpt,
      images: [post.coverImage],
    },
  };
}

export default async function BlogPost({ params }) {
  const post = await getPost(params.slug);
  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );
}

Result: view-source on this page now shows the actual <h1>, meta description, and Open Graph tags before a single line of client JS runs. Test it with curl:

curl -s https://yoursite.com/blog/your-post | grep -A1 "<title>"

If you see your real title instead of "React App," you're done with step one.

React SEO Fix #2: Don't Forget Structured Data (Schema.org)

Even with SSR, most React tutorials skip structured data entirely, which is a shame, because it's often the difference between a plain blue link and a rich result with star ratings, breadcrumbs, or FAQ dropdowns.

Here's a minimal, framework-agnostic way to inject JSON-LD:

function ArticleSchema({ post }) {
  const schema = {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    headline: post.title,
    datePublished: post.date,
    author: { "@type": "Person", name: post.author },
    image: post.coverImage,
  };

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

Result: paste your page URL into Google's Rich Results Test and you'll see it parse the BlogPosting type correctly. This alone has gotten pages of mine into rich snippets within a couple of weeks.

Managing this by hand across dozens of pages gets tedious fast, which is why a lot of React teams reach for a small metadata layer instead of copy-pasting schema blocks everywhere. I've been using @power-seo for this. It wraps generateMetadata-style config and JSON-LD injection into one hook so you set title/description/schema once per route instead of scattering <script> tags across components:

import { usePowerSEO } from "@power-seo/react";

function BlogPost({ post }) {
  usePowerSEO({
    title: post.title,
    description: post.excerpt,
    schema: { type: "BlogPosting", ...post },
  });

  return <article>{/* content */}</article>;
}

It's not magic, under the hood it's doing the same <head> manipulation and JSON-LD injection shown above. It's just less to maintain once you have more than a handful of pages. Plain hand-rolled functions work fine too; this is a convenience, not a requirement.

React SEO Fix #3: Fix Your Sitemap and robots.txt (The Boring Part That Actually Matters)

WordPress auto-generates a sitemap. React apps often ship with none, or a stale static one nobody updates.

A quick dynamic sitemap in Next.js:

// app/sitemap.js
export default async function sitemap() {
  const posts = await getAllPosts();
  return posts.map((post) => ({
    url: `https://yoursite.com/blog/${post.slug}`,
    lastModified: post.updatedAt,
    changeFrequency: "weekly",
    priority: 0.7,
  }));
}

Result: https://yoursite.com/sitemap.xml now reflects reality, and Google Search Console's Coverage report stops showing "Discovered, currently not indexed" for pages that have existed for months. I've watched indexation jump from ~40% to ~90% of submitted URLs within three weeks of fixing just this. You can read a longer breakdown of this specific case at ccbd.dev if you want the full before/after data.

What I Learned About React vs WordPress SEO

WordPress isn't "better" for SEO, it's just rendering HTML earlier in the pipeline. Match that, and React is on equal footing.
SSR/SSG matters more than any meta tag trick. Fix the rendering strategy first; everything else is polish.
Structured data is underused by React devs because the DX around it is worse than plain HTML templates, worth automating early.
Sitemaps and robots.txt are boring but non-negotiable. Crawlers can't index what they can't find.

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

Let's Talk

What's actually slowed you down more: getting React to render SEO-friendly HTML, or getting Google to actually crawl and index it once it does? Curious if others are hitting the indexing wall even after fixing SSR.

React E-commerce SEO: Why Google Can't See Your Product Pages (And How to Fix It)

Mitu Das — Thu, 27 Aug 2026 11:21:56 +0000

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

I'd shipped a React storefront, checked Search Console, and found half my product pages weren't indexed. No meta descriptions. No star ratings. Blank social share cards. The problem wasn't my content. It's a rendering issue specific to how React e-commerce SEO works: Google's first crawl of a React SPA often sees an empty <div id="root">, and the "real" render happens later, if it happens at all.

Here's what actually fixed it: three concrete problems, three working solutions.

Why React SEO Breaks Down for E-commerce Specifically

Client-side-rendered React apps ship an empty HTML shell. Googlebot fetches it, sees almost nothing useful, and queues the page for a second, JavaScript-executing pass, which can happen days later, or not at all if your crawl budget runs out first.

For a blog, that's an annoyance. For a store with thousands of SKUs, each one a potential landing page for buyer-intent keywords, it's the difference between ranking and not existing in search at all. This is the core reason React e-commerce SEO needs a different playbook than a typical marketing site: the fix has to happen at the rendering layer, not the content layer.

1. Fix Rendering First: Server-Side Metadata

The fix is rendering the important stuff (title, price, description, structured data) on the server, before any client-side JS runs. In Next.js App Router, that's just generateMetadata() plus server components:

// app/products/[slug]/page.tsx
import { getProduct } from '@/lib/products';

export async function generateMetadata({ params }: { params: { slug: string } }) {
  const product = await getProduct(params.slug);
  return {
    title: product.name,
    description: product.summary,
    alternates: { canonical: `https://example.com/products/${product.slug}` },
    openGraph: {
      images: [{ url: product.image, width: 1200, height: 630, alt: product.name }],
    },
  };
}

export default async function ProductPage({ params }: { params: { slug: string } }) {
  const product = await getProduct(params.slug);
  return <article>{/* your product UI */}</article>;
}

Result: the HTML Google receives on the first request already has the title, description, and OG image baked in. No waiting on a second render pass that might never come.

If a full migration off client-side rendering isn't realistic right now, prerendering just your product and category routes gets you most of the SEO benefit without touching the rest of the app.

2. Add Structured Data, And Validate It Before You Ship

Product structured data (JSON-LD) tells Google exactly what a page is: a product, at this price, with this availability and rating, instead of making it guess from visible text. Get it right and you're eligible for star ratings and price snippets in search results. Get one required field wrong, and Google doesn't warn you. It just silently drops the markup from rich-result consideration. No error, no flag in Search Console, just no rich result, ever.

export default function ProductPage({ product }) {
  const schema = {
    '@context': 'https://schema.org',
    '@type': 'Product',
    name: product.name,
    description: product.description,
    image: product.image,
    offers: {
      '@type': 'Offer',
      price: product.price,
      priceCurrency: 'USD',
      availability: 'https://schema.org/InStock',
    },
    aggregateRating: {
      '@type': 'AggregateRating',
      ratingValue: product.rating,
      reviewCount: product.reviewCount,
    },
  };

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

Write a small validator alongside it and run it in CI, so a missing offers or image field fails the build instead of shipping quietly:

function validateProductSchema(schema) {
  const required = ['name', 'image', 'offers'];
  const missing = required.filter((field) => !schema[field]);
  if (missing.length) {
    throw new Error(`Missing required schema fields: ${missing.join(', ')}`);
  }
}

There are open-source packages that wrap this pattern (type-safe builders, built-in validation) if you'd rather not maintain it yourself, but the underlying practice matters more than the tool. Validate structured data before every deploy, not after you notice rankings look off.

3. Fix Images: The Overlooked SEO Leak

Product images break SEO in three specific ways, and none of them show up in a normal linter pass:

Bad alt text: empty strings, raw filenames (IMG_9821.jpg), or the same alt text copy-pasted across every color variant. Alt text should describe the actual image ("Blue wireless headphones, side view"), not just repeat the product name.
Wrong lazy-loading: loading="lazy" on your above-the-fold hero image delays Largest Contentful Paint, one of Google's Core Web Vitals ranking signals. Below-the-fold images without lazy-loading waste bandwidth on first load.
No image sitemap: Google Images uses a separate image: sitemap extension as a discovery signal, independent of your regular page sitemap.

The lazy-loading check is a one-liner per image:

function auditImage(img) {
  if (img.isAboveFold && img.loading === 'lazy') {
    return { severity: 'error', message: 'Above-fold image should not be lazy-loaded' };
  }
  if (!img.isAboveFold && img.loading !== 'lazy') {
    return { severity: 'warning', message: 'Below-fold image should be lazy-loaded' };
  }
  return null;
}

Run that across your product grid and you'll usually find at least a few hero images quietly tanking your LCP. No design change needed, just flipping a boolean.

What I Learned

Rendering is the root cause, not content: If your React e-commerce SEO problem is "pages aren't indexed," check server-side rendering before you touch a single meta tag.
Google fails silently on structured data: No warning, no flag, the markup just doesn't qualify for rich results. Validate before you ship, not after.
Lazy-loading is binary and easy to get backwards: Above-the-fold means never lazy. Below-the-fold means always lazy. Check every hero image specifically.
Fix things systematically, not page-by-page: Ad hoc fixes don't scale past a few hundred SKUs. A repeatable checklist (rendering, then metadata, then schema, then images) does.

Let's Talk

What's the worst React SEO surprise you've found in Search Console? I'm especially curious if anyone's dealt with orphan product pages, pages that are in your sitemap but have zero internal links pointing to them. Drop your war stories below.

6 Open Source SEO Tools Developers Actually Use in CI (With Working Code)

Mitu Das — Thu, 20 Aug 2026 11:13:39 +0000

I once spent an entire afternoon debugging why Google couldn't see my React app. The fix was 4 lines of code: a missing robots meta tag was quietly blocking the whole /blog route. That bug taught me something: SEO isn't a marketing problem, it's an engineering problem, and there's a real open source SEO tools stack for solving it, no paid dashboard required.

Quick answer: the best open source SEO tools for developers, by job:

Lighthouse CI: official Google tool, runs SEO/perf/a11y audits per PR
Unlighthouse: runs Lighthouse across your entire site, not just one URL
broken-link-checker: crawls a site for dead links
sitemap: generates XML sitemaps from your actual routes
schema-dts + a JSON-LD validator: catches broken structured data
power-seo: bundles checks like the above into one CI command

Here's how each one actually works, with code.

Best Open Source SEO Tools at a Glance

If you're comparing open source SEO tools for a CI setup, here's how these six stack up:

Tool	Checks	Runs As	Best For
Lighthouse CI	Perf, SEO, a11y score	CLI / GitHub Action	Auditing one URL on every PR
Unlighthouse	Same, site-wide	CLI	Catching issues on pages nobody remembers to test
broken-link-checker	Dead internal/external links	Node CLI/library	Link rot before Google finds it
sitemap	XML sitemap generation	Node library	Keeping sitemap.xml in sync with routes
schema-dts + validator	JSON-LD correctness	TS types + script	Structured data that silently breaks
power-seo	Bundles the above	CLI	One command, one CI step

1. Lighthouse CI: the Official, Battle-Tested Auditor

Lighthouse is the engine behind Chrome DevTools' audit tab, and it's fully open source. Lighthouse CI wraps it so you can fail a build on score regressions instead of eyeballing a report once a quarter.

npm install -g @lhci/cli

# lighthouserc.js
module.exports = {
  ci: {
    collect: {
      url: ['http://localhost:3000/', 'http://localhost:3000/blog'],
      numberOfRuns: 3,
    },
    assert: {
      assertions: {
        'categories:seo': ['error', { minScore: 0.9 }],
      },
    },
    upload: { target: 'temporary-public-storage' },
  },
};

lhci autorun

Result: the run fails with a non-zero exit code the moment SEO score drops below 90. For example, a deploy that accidentally strips <meta name="viewport"> gets caught before merge, not after a client complains.

2. Unlighthouse: Auditing Every Page, Not Just the Homepage

Lighthouse CI is great, but you have to list every URL by hand. Unlighthouse crawls your live site and runs Lighthouse against every discovered page automatically, which is how you catch the one blog post from 2023 nobody's checked since.

npx unlighthouse --site https://yoursite.com

That's it, no config file required for a first pass. It opens a local dashboard showing SEO/perf/a11y scores for every crawled URL, and you can pass --budget flags to fail CI on a site-wide threshold instead of a single page.

Result: on a 40-page marketing site, this surfaced 6 pages missing canonical tags that Lighthouse CI's manual URL list had simply never included.

3. broken-link-checker: Catching Link Rot Before Google Does

Broken internal links waste crawl budget and tank UX; broken outbound links quietly signal a stale, low-effort page. broken-link-checker crawls a site (or a single HTML string) and reports every dead link.

npm install broken-link-checker --save-dev

// check-links.js
const { SiteChecker } = require('broken-link-checker');

const checker = new SiteChecker(
  { excludeExternalLinks: false },
  {
    link: (result) => {
      if (result.broken) {
        console.warn(`❌ Broken: ${result.url.original} (found on ${result.base.original})`);
      }
    },
    end: () => console.log('✅ Link check complete'),
  }
);

checker.enqueue('https://yoursite.com');

Result: this caught three internal links pointing at a renamed /docs/v1/ path six months after a docs restructure. Search Console wouldn't have flagged it for weeks.

4. sitemap: Keeping Your Sitemap From Going Stale

Hand-written sitemaps rot. Generate the XML from your actual route list at build time so it can never drift.

npm install sitemap --save-dev

// generate-sitemap.js
const { SitemapStream, streamToPromise } = require('sitemap');
const { createWriteStream } = require('fs');
const routes = require('./routes.json'); // your actual route list

async function generateSitemap() {
  const sitemap = new SitemapStream({ hostname: 'https://yoursite.com' });
  const writeStream = createWriteStream('./public/sitemap.xml');
  sitemap.pipe(writeStream);

  routes.forEach((route) => {
    sitemap.write({
      url: route.path,
      changefreq: route.changefreq || 'weekly',
      priority: route.priority || 0.5,
      lastmod: route.lastModified,
    });
  });

  sitemap.end();
  await streamToPromise(sitemap);
  console.log(`✅ Sitemap generated with ${routes.length} URLs`);
}

generateSitemap();

Wire it into "prebuild": "node generate-sitemap.js" in package.json.

Result: caught 14 orphaned URLs still submitted to Search Console months after the pages were removed, pure crawl-budget waste.

5. schema-dts + a JSON-LD Validator: Structured Data That Doesn't Silently Break

Broken JSON-LD doesn't throw a JS error or break your UI. It just fails to earn rich results. schema-dts gives you TypeScript types for schema.org so a missing required field is a compile error, not a runtime mystery. Pair it with a runtime check for anything rendered outside TypeScript's reach:

npm install schema-dts --save-dev
npm install jsdom --save-dev

// validate-structured-data.js
const { JSDOM } = require('jsdom');

function validateJsonLd(html) {
  const dom = new JSDOM(html);
  const scripts = dom.window.document.querySelectorAll('script[type="application/ld+json"]');

  if (scripts.length === 0) {
    console.warn('⚠️  No structured data found on this page');
    return;
  }

  scripts.forEach((script, i) => {
    try {
      const data = JSON.parse(script.textContent);
      if (!data['@type']) console.warn(`⚠️  Block ${i}: missing @type`);
      else console.log(`✅ Block ${i}: valid @type "${data['@type']}"`);
    } catch (e) {
      console.error(`❌ Block ${i}: invalid JSON: ${e.message}`);
    }
  });
}

const html = require('fs').readFileSync('./rendered-page.html', 'utf8');
validateJsonLd(html);

For a spec-complete check, cross-reference against Google's Rich Results Test too. This script catches malformed JSON, not every schema.org requirement.

Result: caught a template outputting undefined into a JSON-LD block when a product's price field was missing, silently breaking the whole block, not just that field.

6. power-seo: Bundling All of the Above Into One CI Step

Running five separate scripts works until someone forgets to run one. power-seo bundles checks like the ones above (missing meta tags, duplicate titles, broken canonicals, orphaned sitemap entries) into a single CLI command for CI.

# .github/workflows/seo-check.yml
name: SEO Audit
on: [pull_request]

jobs:
  seo-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install
      - run: npx power-seo audit --url http://localhost:3000 --fail-on-warning

Disclosure: I work with the team behind this package, so take the recommendation with that context. The code above is real, MIT-licensed, and you can read every check it runs before trusting it with your build. The value isn't the tool itself, it's that the check runs on every PR instead of when someone remembers. You could wire the same pipeline yourself from tools 1–5; power-seo just saves the glue code. Longer writeup on the reasoning is on ccbd.dev if you want it.

What I Learned

Single-page tools (Lighthouse CI) and site-wide crawlers (Unlighthouse) catch different bugs, so use both, not one instead of the other.
Link rot and broken structured data are both silent failures. Neither throws an error; both need a dedicated check.
Automate the sitemap. A hand-maintained one is a lie waiting to happen.
None of this replaces off-page tools (backlinks, keyword volume). It just closes the technical-SEO gaps that are 100% within a developer's control.
If you only adopt one thing from this list, make it CI enforcement, that's what turns "open source SEO tools" from a bookmarked list into something that actually protects your rankings.

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

Let's Talk

Which of these have you actually used, and which open source SEO tool should've been on this list? I'll start: still looking for a good open source alternative to Screaming Frog's UI-based crawl reports. Drop your pick below.

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.