DEV Community: Mitu Das

I Built a TypeScript SEO Content Checker in ~100 Lines

Mitu Das — Thu, 01 Oct 2026 07:01:10 +0000

I shipped a blog post with a 94-character title, two H1s, and no meta description. Nobody caught it, not me, not code review, not the linter. Google caught it for me in the form of a truncated, ugly search snippet.

SEO mistakes are just bugs, and bugs can be tested. In this post we'll build a small TypeScript SEO content checker that validates metadata, headings, keyword density, and readability, then run it in CI so bad content fails the build. Everything is copy-paste ready.

Step 1: Check the Metadata

The cheapest wins are title and description length. Search engines truncate both, so they're easy to validate with plain functions. Start with a shared type so every check returns the same shape:

// seo-check.ts
export interface Issue {
  level: 'error' | 'warn';
  rule: string;
  message: string;
}

export function checkMetadata(title: string, description: string): Issue[] {
  const issues: Issue[] = [];

  if (!title) {
    issues.push({ level: 'error', rule: 'title-missing', message: 'Title is missing' });
  } else if (title.length < 30 || title.length > 60) {
    issues.push({
      level: 'warn',
      rule: 'title-length',
      message: `Title is ${title.length} chars (aim for 30–60)`,
    });
  }

  if (!description) {
    issues.push({ level: 'error', rule: 'description-missing', message: 'Meta description is missing' });
  } else if (description.length < 70 || description.length > 160) {
    issues.push({
      level: 'warn',
      rule: 'description-length',
      message: `Description is ${description.length} chars (aim for 70–160)`,
    });
  }

  return issues;
}

Returning plain data instead of throwing keeps the checker composable. You can print the issues, render them in a UI, or fail a build on them.

Step 2: Analyze the Heading Structure

Headings are where content quietly breaks. Common problems are multiple H1s, a missing H1, and skipped levels (an H2 jumping straight to an H4). A regex is fine for a quick checker. For production, use a real HTML parser like node-html-parser.

export function checkHeadings(html: string): Issue[] {
  const issues: Issue[] = [];
  const levels = [...html.matchAll(/<h([1-6])[\s>]/gi)].map((m) => Number(m[1]));

  const h1Count = levels.filter((l) => l === 1).length;
  if (h1Count === 0) {
    issues.push({ level: 'error', rule: 'h1-missing', message: 'Page has no H1' });
  } else if (h1Count > 1) {
    issues.push({ level: 'warn', rule: 'h1-multiple', message: `Page has ${h1Count} H1 tags` });
  }

  for (let i = 1; i < levels.length; i++) {
    if (levels[i] - levels[i - 1] > 1) {
      issues.push({
        level: 'warn',
        rule: 'heading-skip',
        message: `Heading jumps from H${levels[i - 1]} to H${levels[i]}`,
      });
    }
  }

  return issues;
}

Run it on <h1>A</h1><h3>B</h3> and you get one warning: Heading jumps from H1 to H3.

Step 3: Keyword Density and Readability

Two content-level checks next. Keyword density tells you whether your focus keyword shows up at all (or way too much). Flesch Reading Ease gives a rough readability score.

const stripHtml = (html: string): string =>
  html.replace(/<[^>]*>/g, ' ').replace(/\s+/g, ' ').trim();

function countSyllables(word: string): number {
  const w = word.toLowerCase().replace(/[^a-z]/g, '');
  if (!w) return 0;
  if (w.length <= 3) return 1;
  const groups = w
    .replace(/(?:[^laeiouy]es|ed|[^laeiouy]e)$/, '')
    .replace(/^y/, '')
    .match(/[aeiouy]{1,2}/g);
  return groups ? groups.length : 1;
}

export function keywordDensity(text: string, keyword: string): number {
  const words = text.toLowerCase().split(/\s+/).filter(Boolean);
  if (words.length === 0) return 0;
  const phrase = keyword.toLowerCase().split(/\s+/);
  let hits = 0;
  for (let i = 0; i <= words.length - phrase.length; i++) {
    if (phrase.every((p, j) => words[i + j] === p)) hits++;
  }
  return (hits * phrase.length / words.length) * 100;
}

export function fleschScore(text: string): number {
  const sentences = Math.max(1, (text.match(/[.!?]+/g) ?? []).length);
  const words = text.split(/\s+/).filter(Boolean);
  if (words.length === 0) return 0;
  const syllables = words.reduce((sum, w) => sum + countSyllables(w), 0);
  return 206.835 - 1.015 * (words.length / sentences) - 84.6 * (syllables / words.length);
}

export function checkContent(html: string, keyword: string): Issue[] {
  const issues: Issue[] = [];
  const text = stripHtml(html);
  const wordCount = text.split(/\s+/).filter(Boolean).length;

  if (wordCount < 300) {
    issues.push({ level: 'warn', rule: 'thin-content', message: `Only ${wordCount} words (aim for 300+)` });
  }

  const density = keywordDensity(text, keyword);
  if (density === 0) {
    issues.push({ level: 'error', rule: 'keyword-missing', message: `"${keyword}" never appears` });
  } else if (density > 3) {
    issues.push({ level: 'warn', rule: 'keyword-stuffing', message: `Density is ${density.toFixed(1)}% (keep under 3%)` });
  }

  const flesch = fleschScore(text);
  if (flesch < 50) {
    issues.push({ level: 'warn', rule: 'hard-to-read', message: `Flesch score ${flesch.toFixed(0)} (60+ is easy to read)` });
  }

  return issues;
}

The 3% ceiling and the Flesch cutoffs aren't laws of nature, just sane defaults. Treat them as tunable config, not gospel.

Step 4: Run It in CI

Now combine everything into a script that exits non-zero on errors. Warnings print but don't block the build.

// run-check.ts
import { readFileSync } from 'node:fs';
import { checkMetadata, checkHeadings, checkContent, Issue } from './seo-check';

const [file, keyword, title = '', description = ''] = process.argv.slice(2);
const html = readFileSync(file, 'utf8');

const issues: Issue[] = [
  ...checkMetadata(title, description),
  ...checkHeadings(html),
  ...checkContent(html, keyword),
];

for (const i of issues) {
  console.log(`${i.level === 'error' ? '✗' : '!'} [${i.rule}] ${i.message}`);
}

const errors = issues.filter((i) => i.level === 'error').length;
console.log(`\n${errors} error(s), ${issues.length - errors} warning(s)`);
process.exit(errors > 0 ? 1 : 0);

Run it with npx tsx run-check.ts post.html "typescript seo" "My Title" "My description". Add that line to a GitHub Actions step and SEO regressions become failing builds instead of mystery traffic drops.

When to Stop Hand-Rolling

My checker is intentionally simple. Once you want Yoast-style scoring, such as keyphrase in the first paragraph, subheading distribution, and link checks, you're maintaining a rules engine. That's where I switched to an existing library for the scoring part. I used @power-seo/content-analysis because it's TypeScript-native:

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

const result = analyzeContent({
  title: 'TypeScript SEO Content Checker',
  content: '<h1>TypeScript SEO Content Checker</h1><p>Your article HTML...</p>',
  focusKeyphrase: 'typescript seo content checker',
});

console.log(result.score);           // numeric score
console.log(result.recommendations); // string[] of fixes

That gave me a score and a list of recommendations in a few lines. I kept my own metadata and heading checks for the project-specific rules (like a house style on title length). If you want to see how this kind of checker fits into a broader workflow, this write-up on ccbd.dev goes deeper. Check the package docs for the current API, since options may change between versions.

What I Learned

Treat SEO as testable output: If a rule can be expressed as a function returning Issue[], it can run in CI.
Errors vs. warnings matter: Fail builds only on things that are objectively broken (no H1, no description). Everything else should be advisory, or the team will disable the check.
Regex is fine until it isn't: It works for headings and word counts, but switch to a real HTML parser before you trust it on messy CMS output.
Don't over-engineer scoring: Hand-roll the checks specific to your site, and use a library for generic content scoring.

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

Your Turn

What's the most embarrassing SEO bug you've shipped to production, and would an automated check have caught it? Drop it in the comments. I'm also curious whether you'd run something like this at build time or as a pre-commit hook.

Every Page of My React App Had the Same Title (Here's the Fix)

Mitu Das — Mon, 28 Sep 2026 10:21:37 +0000

I spent five hours debugging why Google couldn't tell my React pages apart. The fix was four lines of code. Every route was serving the same <title> from index.html, and no amount of clever components was changing it.

If your Search Console shows "Crawled, not indexed" and your link previews look blank, this is probably why. Below: why client-rendered React breaks head tags, how to set per-page titles, canonicals, and Open Graph, how to add JSON-LD, and where an SEO npm package for React earns its keep.

Why your React app has one title for every page

A client-rendered React app mounts into one <div id="root">. Titles, descriptions, and Open Graph tags live in <head>, outside that tree, so every route inherits whatever is hard-coded in index.html.

Check yours in ten seconds: open View Source on three different routes. If the <title> is identical, you have the problem. Google can render JavaScript, but rendering happens after crawling and can lag. Many social preview bots don't run JS at all.

Here's the fastest fix. React 19 hoists <title>, <meta>, and <link> into the head natively:

// BlogPost.jsx (React 19+)
export default function BlogPost({ post }) {
  const url = `https://example.com/blog/${post.slug}`;

  return (
    <article>
      <title>{`${post.title} | My Site`}</title>
      <meta name="description" content={post.excerpt} />
      <link rel="canonical" href={url} />
      <h1>{post.title}</h1>
      {/* content */}
    </article>
  );
}

Result: the tab title and head tags now change per route in the rendered DOM. On React 18 or below, react-helmet-async does the same job with a <Helmet> wrapper and a <HelmetProvider> at your root.

One caveat: this fixes the rendered DOM. For bots that skip JavaScript, you still want SSR, SSG, or prerendering. Head management and rendering strategy are separate problems.

Canonical URLs, Open Graph, and Twitter Cards

Once titles work, three tags cause most of the remaining pain:

Canonical: SPAs often serve one page at /page, /page/, and /page?ref=twitter. A canonical tells search engines which one counts. Google treats it as a strong hint, not a command.
Open Graph: controls link previews on Slack, LinkedIn, Facebook, and most messengers. Use a 1200×630 image.
Twitter Cards: summary_large_image gives you the big preview.

Here's a reusable component so you don't copy-paste tags into every page:

// Seo.jsx
export function Seo({ title, description, url, image }) {
  return (
    <>
      <title>{title}</title>
      <meta name="description" content={description} />
      <link rel="canonical" href={url} />

      <meta property="og:type" content="website" />
      <meta property="og:title" content={title} />
      <meta property="og:description" content={description} />
      <meta property="og:url" content={url} />
      <meta property="og:image" content={image} />

      <meta name="twitter:card" content="summary_large_image" />
      <meta name="twitter:title" content={title} />
      <meta name="twitter:description" content={description} />
      <meta name="twitter:image" content={image} />
    </>
  );
}

// Usage
<Seo
  title="React SEO Guide | My Site"
  description="Meta tags, canonicals, and JSON-LD for React apps."
  url="https://example.com/blog/react-seo"
  image="https://example.com/og/react-seo.png"
/>

Result: paste any URL into a link-preview debugger and you should see the right title, description, and image. Keep descriptions around 150–160 characters and titles under roughly 60, since search results truncate both.

JSON-LD structured data

Structured data tells search engines what a page is: an article, a product, a FAQ. Google recommends JSON-LD as the format. Valid markup makes you eligible for rich results, but it doesn't guarantee them.

The catch with hand-written JSON-LD is escaping. If your data contains </script>, you've broken the page. This component handles it:

// JsonLd.jsx
export function JsonLd({ data }) {
  const json = JSON.stringify(data).replace(/</g, '\\u003c');
  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: json }}
    />
  );
}

<JsonLd
  data={{
    '@context': 'https://schema.org',
    '@type': 'Article',
    headline: post.title,
    datePublished: post.publishedAt,
    author: { '@type': 'Person', name: post.author },
    image: post.coverImage,
  }}
/>

Result: run the page through Google's Rich Results Test and the Article should parse without errors. Misspell a property and nothing complains, though. Nothing here is typed or validated.

When hand-rolled tags stop scaling

The pieces above work fine for a small site. At around 30 routes, I hit the annoying parts: forgetting a canonical on one page, typing a bad robots directive that nobody noticed, and repeating the same defaults everywhere.

That's when a dedicated SEO npm package for React makes sense. It only has to do three things well: site-wide defaults, typed props, and structured data helpers. I've been using @power-seo/react plus its schema package. It's MIT-licensed and works in Vite, Gatsby, and other non-Next setups. The whole setup looks like this:

npm install @power-seo/react @power-seo/schema

import { DefaultSEO, SEO, Robots } from '@power-seo/react';
import { ArticleJsonLd } from '@power-seo/schema/react';

function App() {
  return (
    <DefaultSEO
      titleTemplate="%s | My Site"
      defaultTitle="My Site"
      openGraph={{ type: 'website', siteName: 'My Site' }}
      twitter={{ site: '@mysite', cardType: 'summary_large_image' }}
    >
      <Router>
        <Routes />
      </Router>
    </DefaultSEO>
  );
}

function BlogPost({ post }) {
  return (
    <>
      <SEO
        title={post.title}
        description={post.excerpt}
        canonical={`https://example.com/blog/${post.slug}`}
        openGraph={{
          type: 'article',
          images: [{ url: post.coverImage, width: 1200, height: 630 }],
        }}
      />
      <Robots index follow maxImagePreview="large" maxSnippet={160} />
      <ArticleJsonLd
        headline={post.title}
        datePublished={post.publishedAt}
        author={{ name: post.author, url: 'https://example.com/authors/jane' }}
      />
      <article>{/* content */}</article>
    </>
  );
}

Result: defaults cascade, each page overrides only what it needs, and a typo like maxImagePreview="huge" fails at build time instead of shipping. That typed safety net is the main reason I switched. I also wrote a longer comparison of head managers vs. toolkits for the same problem.

Disclosure: power-seo is built by the team at CyberCraft Bangladesh (ccbd.dev), where I work with it. If you're on Next.js App Router, the built-in Metadata API may be all you need.

What I learned

View source first. Compare <title> across several routes before touching any code.
Head tags and rendering are separate problems. Fix per-route metadata, then decide whether you need SSR or prerendering.
Canonicals matter more than they look. Add one to every indexable page from day one.
Type your SEO props. Silent typos in robots or schema are the bugs you find months later.

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

Your turn

What's the worst React SEO bug you've shipped: blank previews, a stray noindex, or something stranger? And are you handling head tags with React 19 natively, Helmet, or a toolkit? Drop it in the comments. I'm collecting war stories.

I Compared Next.js's Built-in Sitemap to Two Popular Libraries

Mitu Das — Tue, 22 Sep 2026 10:36:18 +0000

I once shipped a 40,000-page e-commerce site with a sitemap that only listed 50 URLs. Nobody noticed for three weeks until organic traffic flatlined. The bug wasn't in my product data. It was in how I generated the sitemap. In this post, I'll walk through three ways to generate a Next.js sitemap, built-in, next-sitemap and power-seo/sitemapand when each one breaks.

Why Sitemaps Are Harder Than They Look

A sitemap seems trivial: loop over your routes, output XML, done. The problem shows up at scale. Google enforces a hard limit of 50,000 URLs (or 50MB uncompressed) per sitemap file. Past that, you need a sitemap index that points to multiple child sitemaps. You also need lastmod, changefreq, and sometimes image or alternate-language annotations and all of it has to regenerate whenever your CMS content changes, not just at build time.

Most tutorials show you the happy path with 10 static routes. Nobody shows you what happens with 80,000 dynamic product pages pulled from a database at build time on a serverless function with a memory ceiling.

Method 1: Next.js's Built-in `sitemap.ts`

Since Next.js 13.3, the App Router supports a native sitemap.ts file. This is the right starting point for most projects — zero dependencies, fully typed.

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

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const posts = await fetch('https://api.example.com/posts').then((r) => r.json());

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

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

Result: This works beautifully up to a few thousand URLs. But there's a catch — if sitemap() returns more than 50,000 entries, Next.js doesn't automatically split it. You have to manually implement generateSitemaps() to produce a paginated set of sitemap files. It's doable, but it's on you to get the chunking math right, and there's no built-in index file that lists all chunks for Google — you have to hand-roll that too.

Method 2: `next-sitemap` for Config-Driven Generation

next-sitemap is the long-standing community package for this. Instead of writing code, you write a config file, and it generates static XML files as a post-build step.

// next-sitemap.config.js
/** @type {import('next-sitemap').IConfig} */
module.exports = {
  siteUrl: 'https://example.com',
  generateRobotsTxt: true,
  sitemapSize: 5000,
  exclude: ['/admin/*', '/api/*'],
};

// package.json
{
  "scripts": {
    "postbuild": "next-sitemap"
  }
}

Result: It automatically splits output into multiple sitemap-0.xml, sitemap-1.xml, etc., plus a sitemap-index.xml, and generates robots.txt referencing it — all with zero manual chunking logic. The tradeoff: it runs as a separate post-build script rather than inside the Next.js data pipeline, so dynamic content that changes between builds (e.g., a CMS webhook triggering new pages) needs an ISR-style revalidation workaround or an on-demand rebuild trigger.

Method 3: Streaming Generation for Very Large Sites

Here's where things get interesting for genuinely large sites — think marketplaces or directories with hundreds of thousands of listings. Loading every URL into memory to build the sitemap array can blow past serverless memory limits or just time out.

This is the actual hard problem, and it's why I started looking at streaming-based sitemap generators instead of array-based ones. @power-seo/sitemap takes this approach it streams entries instead of materializing the whole array, and ships a Next.js adapter so you don't have to hand-write the XML:

// app/sitemap.ts
import { toNextSitemap } from '@power-seo/sitemap/next';

export default async function sitemap() {
  const urls = await fetchAllUrls(); // your paginated DB query
  return toNextSitemap(urls);
}

Installed with:

npm install @power-seo/sitemap

Result: For a large catalog, the meaningful difference isn't the API surface (all three approaches end up producing valid XML) — it's whether the generation step can process URLs incrementally versus holding the entire set in memory before writing output. If your fetchAllUrls() function is itself paginated/streamed, this pattern avoids the memory spike that array-based approaches hit at high URL counts. You can see the source and options on the project's GitHub repo or check the package on npm.

To be clear: for sites under ~10,000 URLs, this is overkill. The built-in sitemap.ts or next-sitemap will serve you fine.

What I Learned

Start with the built-in sitemap.ts. Don't add a dependency until you hit an actual limit (URL count, memory, or missing feature like auto-generated robots.txt).
Know your URL count before picking a tool. Under 10K: built-in is fine. 10K–50K: next-sitemap handles chunking for you. 50K+ with a live database: look at streaming-based generation.
Test your sitemap in Google Search Console, not just by opening the XML file. A syntactically valid sitemap can still get partially rejected for bad lastmod formats or duplicate URLs.
Rebuild triggers matter as much as generation logic. A perfect sitemap that's three days stale because nothing triggered a rebuild is worse than a simple one that's current.

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

Let's Discuss

What's the largest URL count you've had to handle in a sitemap, and what broke first memory, build time, or Google's crawl budget? I'm curious whether anyone's rolled their own streaming solution before reaching for a library.

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.

DEV Community: Mitu Das

I Built a TypeScript SEO Content Checker in ~100 Lines

Step 1: Check the Metadata

Step 2: Analyze the Heading Structure

Step 3: Keyword Density and Readability

Step 4: Run It in CI

When to Stop Hand-Rolling

What I Learned

Your Turn

Every Page of My React App Had the Same Title (Here's the Fix)

Why your React app has one title for every page

Canonical URLs, Open Graph, and Twitter Cards

JSON-LD structured data

When hand-rolled tags stop scaling

What I learned

Your turn

I Compared Next.js's Built-in Sitemap to Two Popular Libraries

Why Sitemaps Are Harder Than They Look

Method 1: Next.js's Built-in sitemap.ts

Method 2: next-sitemap for Config-Driven Generation

Method 3: Streaming Generation for Very Large Sites

What I Learned

Let's Discuss

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

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

Fixing React SEO Meta Tags for SSR and SPA Apps

Structured Data: The Part Every React SEO Checklist Skips

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

What I Learned About React SEO

Let's Talk

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

React vs WordPress SEO: Why WordPress Wins by Default

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

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

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

What I Learned About React vs WordPress SEO

Let's Talk

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

Why React SEO Breaks Down for E-commerce Specifically

1. Fix Rendering First: Server-Side Metadata

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

3. Fix Images: The Overlooked SEO Leak

What I Learned

Let's Talk

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

Best Open Source SEO Tools at a Glance

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

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

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

4. sitemap: Keeping Your Sitemap From Going Stale

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

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

What I Learned

Let's Talk

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

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

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

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

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

Key Takeaways: How to Fix SEO Issues in React Apps

Let's Talk React SEO

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

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

Fixing Dynamic Meta Tags (Step 1 of React SEO)

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

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

What I Learned

Let's Talk

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

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

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

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

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

What I Learned Testing These Tools

Let's Talk

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

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

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

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

Fix #3: Structured Data That Earns Rich Results

Method 1: Next.js's Built-in `sitemap.ts`

Method 2: `next-sitemap` for Config-Driven Generation