DEV Community: Mitu Das

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

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

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

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

Metadata That Actually Renders Per-Page

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

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

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

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

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

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

Sitemaps and Robots.txt as Code, Not Afterthoughts

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

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

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

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

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

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

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

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

Structured Data Without the JSON-LD Headache

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

A plain script tag works fine:

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

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

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

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

import { generateArticleSchema } from "power-seo";

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

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

Verifying It Actually Worked

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

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

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

What I Learned

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

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

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

Your Turn

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

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

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

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

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

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

Why Next.js Redirects Break SEO More Than You Think

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

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

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

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

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

Auditing Your Redirect Chain Before Writing Any Code

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

Step 1: Export your current redirects

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

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

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

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

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

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

main()

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

Step 2: Validate your canonical tags match your final URLs

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

Handling Redirects at the Right Layer

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

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

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

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

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

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

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

Automating Redirect Management with a Library

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

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

Install it:

npm install @power-seo

Then update your config:

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

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

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

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

Key Takeaways

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

What's Your Setup?

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

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

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

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

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

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

Why the GSC UI Isn't Built for Repeated Checks

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

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

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

npm install googleapis

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

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

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

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

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

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

module.exports = { fetchSearchAnalytics };

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

Diffing Two Weeks Automatically

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

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

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

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

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

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

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

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

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

  return regressions;
}

module.exports = { compareWeeks };

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

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

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

Turning It Into a Repeatable SEO Checklist

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

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

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

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

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

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

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

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

module.exports = { runChecklist };

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

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

What I Learned

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

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

Your Turn

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

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

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

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

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

Why a Hand-Rolled Sitemap Breaks Silently

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

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

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

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

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

console.log(xml);

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

Building a Sitemap That Escapes Properly

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

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

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

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

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

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

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

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

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

Scaling Past 50,000 URLs Without Crashing Your Build

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

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

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

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

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

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

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

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

Where I Stopped Writing This From Scratch Every Project

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

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

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

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

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

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

And validating entries before they ever reach a deploy:

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

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

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

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

My Pre-Deploy SEO Checklist for Sitemaps

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

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

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

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

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

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

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

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

The surprising part?

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

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

Why Ecommerce Sites Become Slow Faster Than You Expect

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

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

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

// Express.js API example

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

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

  res.json(products);
});

On the frontend:

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

  renderProducts(products);
}

Result:

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

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

Why Search Engines Struggle With Product Pages

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

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

A simple metadata generator solves this.

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

Using the helper:

const metadata = generateMetadata(product);

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

Result:

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

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

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

Organizing Product Data Without Creating Maintenance Chaos

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

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

Centralizing transformation logic helps.

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

Usage:

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

console.log(formattedProduct);

Result:

Cleaner components
Consistent product presentation
Easier testing
Faster feature development

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

Improving Core Web Vitals With Lazy Loading

Images are usually the largest assets on ecommerce pages.

Loading every image immediately wastes bandwidth and delays rendering.

Modern browsers make lazy loading incredibly easy.

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

For React:

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

Result:

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

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

What I Learned

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

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

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

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

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

Final Thoughts

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

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

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

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

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

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

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

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

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

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

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

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

Step 1: Audit What Google Actually Sees

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

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

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

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

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

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

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

  console.table(checks);
}

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

npm install jsdom
node audit-seo.mjs

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

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

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

npm install react-helmet-async

Wrap your app:

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

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

Then in each route component:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

npm install power-seo

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

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

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

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

What I Learned

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

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

Your Turn

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

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

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

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

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

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

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

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

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

Here's a systematic way to handle all three.

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

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

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

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

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

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

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

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

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

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

2. Automate Structured Data with JSON-LD

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

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

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

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

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

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

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

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

3. Integrate an SEO API to Audit at Scale

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

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

Install it:

npm install @power-seo

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

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

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

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

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

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

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

runAudit()

Add it to your package.json:

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

And in your GitHub Actions workflow:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What I Learned

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

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

What's Your SEO Setup?

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

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

I Built an SEO Content Checker Into My React App Here's the Exact Setup

Mitu Das — Mon, 08 Jun 2026 10:01:15 +0000

I spent 6 hours debugging why Google Search Console showed zero impressions for a landing page I'd just shipped. The culprit? A missing <title> tag because a lazy useEffect was overwriting it with an empty string on hydration. The fix was 4 lines of code. The wasted Friday afternoon was entirely avoidable.

If you're building React apps and treating SEO as an afterthought, this article is for you. I'll show you how to wire a real SEO content checker into your workflow so you catch these issues before they ever reach production.

Why React Apps Have an SEO Blind Spot

Server-rendered frameworks like Next.js have improved things, but a huge chunk of React apps are still SPAs that rely on client-side rendering. Crawlers have gotten smarter, but they're not perfect and even in SSR setups, meta tags get silently dropped, duplicated, or overwritten by nested component trees.

The bugs are subtle:

A <Helmet> component deep in a route component overrides the parent's <title>
Dynamic OG images point to undefined because the data hadn't loaded yet
Description tags hit 300+ characters because someone copy-pasted a paragraph

You don't notice these locally because you can read the page. Google notices and demotes you.

The fix isn't better discipline. It's automated checking.

Step 1: Audit Your Existing Pages With a Node Script

Before adding tooling, you need a baseline. Here's a dead-simple script that crawls your rendered HTML and checks for common SEO problems:

// scripts/seo-audit.ts
import { JSDOM } from "jsdom";
import fetch from "node-fetch";

interface SEOReport {
  url: string;
  title: string | null;
  titleLength: number;
  description: string | null;
  descriptionLength: number;
  issues: string[];
}

async function auditPage(url: string): Promise<SEOReport> {
  const res = await fetch(url);
  const html = await res.text();
  const dom = new JSDOM(html);
  const doc = dom.window.document;

  const title = doc.querySelector("title")?.textContent ?? null;
  const descEl = doc.querySelector('meta[name="description"]');
  const description = descEl?.getAttribute("content") ?? null;

  const issues: string[] = [];

  if (!title) issues.push("Missing <title> tag");
  else if (title.length < 30) issues.push(`Title too short (${title.length} chars)`);
  else if (title.length > 60) issues.push(`Title too long (${title.length} chars)`);

  if (!description) issues.push("Missing meta description");
  else if (description.length < 70) issues.push(`Description too short (${description.length} chars)`);
  else if (description.length > 160) issues.push(`Description too long (${description.length} chars)`);

  if (!doc.querySelector('meta[property="og:image"]'))
    issues.push("Missing og:image");

  if (!doc.querySelector("h1"))
    issues.push("No <h1> tag found");

  return {
    url,
    title,
    titleLength: title?.length ?? 0,
    description,
    descriptionLength: description?.length ?? 0,
    issues,
  };
}

async function main() {
  const urls = [
    "http://localhost:3000",
    "http://localhost:3000/about",
    "http://localhost:3000/blog",
  ];

  for (const url of urls) {
    const report = await auditPage(url);
    console.log(`\n📄 ${report.url}`);
    if (report.issues.length === 0) {
      console.log("  ✅ All checks passed");
    } else {
      report.issues.forEach((issue) => console.log(`  ❌ ${issue}`));
    }
  }
}

main();

Run it against your local dev server:

npx ts-node scripts/seo-audit.ts

Result: You get a per-page issue list in 10 seconds. This alone will surface embarrassing problems you've been shipping silently.

Step 2: Add a React SEO Checklist as a Dev-Mode Overlay

The audit script is great for CI, but during development you want instant feedback. Here's a lightweight component that renders an SEO checklist overlay in dev mode no page reload required.

// components/SEODebugOverlay.tsx
import { useEffect, useState } from "react";

interface Check {
  label: string;
  pass: boolean;
  detail?: string;
}

function runChecks(): Check[] {
  const title = document.title;
  const descEl = document.querySelector<HTMLMetaElement>(
    'meta[name="description"]'
  );
  const desc = descEl?.content ?? "";
  const ogImage = document.querySelector('meta[property="og:image"]');
  const h1s = document.querySelectorAll("h1");
  const canonical = document.querySelector('link[rel="canonical"]');

  return [
    {
      label: "Title length (30–60 chars)",
      pass: title.length >= 30 && title.length <= 60,
      detail: `${title.length} chars: "${title.slice(0, 40)}…"`,
    },
    {
      label: "Meta description (70–160 chars)",
      pass: desc.length >= 70 && desc.length <= 160,
      detail: desc ? `${desc.length} chars` : "Missing",
    },
    {
      label: "OG image present",
      pass: !!ogImage,
    },
    {
      label: "Exactly one <h1>",
      pass: h1s.length === 1,
      detail: `Found ${h1s.length}`,
    },
    {
      label: "Canonical URL set",
      pass: !!canonical,
    },
  ];
}

export function SEODebugOverlay() {
  const [checks, setChecks] = useState<Check[]>([]);
  const [open, setOpen] = useState(false);

  useEffect(() => {
    setChecks(runChecks());
  }, []);

  if (process.env.NODE_ENV !== "development") return null;

  const failCount = checks.filter((c) => !c.pass).length;

  return (
    <div style={{ position: "fixed", bottom: 16, right: 16, zIndex: 9999 }}>
      <button
        onClick={() => setOpen((o) => !o)}
        style={{
          background: failCount > 0 ? "#ef4444" : "#22c55e",
          color: "#fff",
          border: "none",
          borderRadius: 8,
          padding: "6px 12px",
          cursor: "pointer",
          fontFamily: "monospace",
          fontSize: 13,
        }}
      >
        SEO {failCount > 0 ? `⚠ ${failCount} issues` : "✓"}
      </button>

      {open && (
        <div
          style={{
            background: "#1e1e2e",
            color: "#cdd6f4",
            borderRadius: 8,
            padding: 16,
            marginTop: 8,
            width: 320,
            fontFamily: "monospace",
            fontSize: 12,
          }}
        >
          {checks.map((c) => (
            <div key={c.label} style={{ marginBottom: 8 }}>
              <span style={{ color: c.pass ? "#a6e3a1" : "#f38ba8" }}>
                {c.pass ? "✓" : "✗"}
              </span>{" "}
              {c.label}
              {c.detail && (
                <div style={{ color: "#6c7086", marginLeft: 16 }}>
                  {c.detail}
                </div>
              )}
            </div>
          ))}
        </div>
      )}
    </div>
  );
}

Drop <SEODebugOverlay /> into your root layout. It shows a green/red badge in the corner click it to see the full React SEO checklist without leaving the page.

Step 3: Pull It Into CI With a Proper Checker Package

The overlay and script are solid for most projects. When you're managing multiple routes or content-heavy pages (think: blogs, product pages, landing page variants), you want something more structured.

This is where @power-seo fits naturally. It's a TypeScript-first SEO content checker tool that runs programmatically against your rendered output no headless browser required. I started using it after the setup above got repetitive across three client projects.

npm install @power-seo

// scripts/check-seo.ts
import { checkSEO } from "@power-seo";

const result = await checkSEO({
  html: await fetch("http://localhost:3000/blog/my-post").then((r) => r.text()),
  url: "https://yourdomain.com/blog/my-post",
});

if (!result.pass) {
  console.error("SEO issues found:");
  result.issues.forEach((issue) => {
    console.error(`  [${issue.severity}] ${issue.message}`);
  });
  process.exit(1); // Fail the CI build
}

What I like about it: the severity field. Not every SEO issue is a blocker a missing OG image is a warning; a missing <title> is a critical error. That distinction matters when you're wiring this into a CI gate and you don't want to block deploys over minor things. The deeper write-up of how it handles edge cases (duplicate canonicals, hreflang conflicts, structured data validation) is on ccbd.dev.

What I Actually Learned

SEO bugs are invisible until they're expensive. Add the debug overlay from day one it costs you 20 minutes to set up and saves hours of Googling "why isn't my page indexed."
Test rendered HTML, not your JSX. Component props look fine. The DOM at runtime is where things break. Always audit the actual output.
The React SEO checklist you need is short. Title (30–60), description (70–160), one <h1>, OG image, canonical. Everything else is optimization. Get these five right first.
Fail builds on critical SEO issues. Treat a missing <title> like a missing return statement. It's a bug.

What's your SEO workflow?

Do you check meta tags manually, use a browser extension, or do you have something automated? I'm curious whether anyone has integrated SEO auditing into their preview deployment pipeline (Vercel/Netlify preview URLs specifically) that's the next thing I'm trying to solve. Drop your setup in the comments.

Internal linking gaps are silently killing your React app's SEO

Mitu Das — Thu, 04 Jun 2026 17:12:19 +0000

I built a React SPA, deployed it, submitted the sitemap, and waited. Three weeks later, Google Search Console was indexing maybe 30% of my pages. I assumed it was a crawl budget problem or a slow server. It wasn't.

It was internal links, or the complete lack of them.

My app had dozens of pages that were only reachable through JavaScript-driven navigation. No <a href> tags. No static links Google could follow. The pages existed, but from Google's perspective, they were islands.

This article is going to show you exactly how I found those orphaned pages, how I fixed the linking structure, and how you can audit your own app programmatically so you don't lose three weeks the same way I did.

Why React Apps Are Especially Bad at Internal Linking

This is the React SEO mistake I see most often, and it's subtle. When you use useNavigate() or history.push() to move between pages, you're doing JavaScript navigation. It works perfectly for users. For Googlebot, it's a wall.

// ❌ This looks fine to users. Googlebot can't follow it.
const GoToProduct = ({ id }) => {
  const navigate = useNavigate();
  return (
    <button onClick={() => navigate(`/product/${id}`)}>
      View Product
    </button>
  );
};

// ✅ This is crawlable. Same user experience.
const GoToProduct = ({ id }) => {
  return (
    <Link to={`/product/${id}`}>
      View Product
    </Link>
  );
};

The difference is just four characters, Link vs a button with onClick. But the SEO difference is enormous.

React Router's <Link> component renders an actual <a href> tag in the DOM. Googlebot can see it, follow it, and build a graph of your site. A button with navigate() renders... a button. That's it. Dead end.

And the worst part? This pattern is everywhere in React codebases. Dashboard links, product cards, article teasers, "back" buttons, they all tend to get implemented as buttons or divs with click handlers because it feels more "React-y." It isn't wrong to the user. It's invisible to crawlers.

Step 1: Find Your Orphaned Pages Programmatically

Before you fix anything, you need to know the scope of the problem. Here's a script I use to crawl a built React app and find pages that have no inbound <a href> links from other pages.

// audit-links.mjs
// Run with: node audit-links.mjs https://yoursite.com

import * as cheerio from "cheerio";

const BASE_URL = process.argv[2];
const visited = new Set();
const inboundLinks = {}; // page -> Set of pages that link to it
const queue = [BASE_URL];

async function fetchPage(url) {
  try {
    const res = await fetch(url);
    const html = await res.text();
    return cheerio.load(html);
  } catch {
    return null;
  }
}

function normalizeUrl(href, fromUrl) {
  try {
    const url = new URL(href, fromUrl);
    if (url.origin !== new URL(BASE_URL).origin) return null;
    url.hash = "";
    url.search = "";
    return url.href;
  } catch {
    return null;
  }
}

async function crawl() {
  while (queue.length > 0) {
    const url = queue.shift();
    if (visited.has(url)) continue;
    visited.add(url);

    if (!inboundLinks[url]) inboundLinks[url] = new Set();

    const $ = await fetchPage(url);
    if (!$) continue;

    $("a[href]").each((_, el) => {
      const href = $(el).attr("href");
      const normalized = normalizeUrl(href, url);
      if (!normalized) return;

      if (!inboundLinks[normalized]) inboundLinks[normalized] = new Set();
      inboundLinks[normalized].add(url);

      if (!visited.has(normalized)) queue.push(normalized);
    });

    console.log(`Crawled: ${url} (${queue.length} remaining)`);
  }
}

async function main() {
  await crawl();

  const orphans = Object.entries(inboundLinks)
    .filter(([_, sources]) => sources.size === 0)
    .map(([url]) => url);

  console.log("\n=== ORPHANED PAGES (no inbound <a> links) ===");
  orphans.forEach((url) => console.log(` - ${url}`));
  console.log(`\nTotal pages found: ${visited.size}`);
  console.log(`Orphaned pages: ${orphans.length}`);
}

main();

Install the one dep and run it:

npm install cheerio
node audit-links.mjs https://yoursite.com

This gives you a concrete list of pages Google can't reach by following links. That's your fix list.

Step 2: Fix the Most Common Patterns

Once you have the list, the fixes usually fall into a few patterns. Here's what I found in my own app and how I addressed each one.

Pattern 1: Buttons pretending to be links

// Before
<div onClick={() => navigate(`/blog/${post.slug}`)}>
  <h2>{post.title}</h2>
</div>

// After — wraps the whole card in a real link
<Link to={`/blog/${post.slug}`} style={{ textDecoration: "none", color: "inherit" }}>
  <div>
    <h2>{post.title}</h2>
  </div>
</Link>

Pattern 2: Programmatic navigation in menus

// Before — a common pattern in sidebar navs
<MenuItem onClick={() => navigate("/settings/profile")}>Profile</MenuItem>

// After
<MenuItem component={Link} to="/settings/profile">Profile</MenuItem>
// Or if your component doesn't accept `component`:
<Link to="/settings/profile"><MenuItem>Profile</MenuItem></Link>

Pattern 3: "View more" buttons in lists

These are especially bad because they're often the only entry point into detail pages.

// Before
<button onClick={() => navigate(`/product/${id}`)}>View Details</button>

// After — identical appearance, crawlable
<Link to={`/product/${id}`}>
  <button>View Details</button>
</Link>

Note: wrapping a <button> in an <a> is technically invalid HTML, but it works in all browsers. If you care about strict validity, use <Link> with button styling instead:

<Link to={`/product/${id}`} className="btn btn-primary">
  View Details
</Link>

Step 3: Automate This Check Going Forward

Finding and fixing the current gaps is a one-time effort. Making sure you don't reintroduce them is the ongoing challenge.

I ended up using a package called @power-seo to automate this audit in CI. It wraps the kind of crawl logic above and flags orphaned pages as part of a build check.

// seo-check.mjs
import { auditInternalLinks } from "@power-seo/audit";

const result = await auditInternalLinks({
  baseUrl: "http://localhost:3000",
  startPath: "/",
});

if (result.orphanedPages.length > 0) {
  console.error("SEO FAIL: Orphaned pages found:");
  result.orphanedPages.forEach((p) => console.error(` - ${p}`));
  process.exit(1); // Fails the build
}

console.log(`✓ All ${result.totalPages} pages are reachable via <a> links`);

You add that to your package.json:

"scripts": {
  "seo:check": "node seo-check.mjs",
  "build": "vite build && npm run seo:check"
}

Now the build fails if someone introduces an orphaned page. The problem can't sneak back in.

If you want to go deeper on how this audit works under the hood, including gap analysis between your sitemap and your crawled link graph — there's a solid walkthrough at ccbd.dev/blog/how-to-find-and-fix-internal-linking-gaps-programmatically.

What I Actually Learned From This

<Link> over navigate() for anything user-facing. Reserve programmatic navigation for post-form-submit redirects, auth flows, and similar cases where there's no visual element to link from. If there's a card, button, or menu item a user can see, it should be a real anchor tag.
Orphaned pages hurt more than missing pages. If a page doesn't exist, Google just doesn't index it. If a page exists but can't be reached by following links, Google might index it once from the sitemap, then deprioritize it because nothing points to it. Low PageRank by default.
Run the audit before launch, not after. I didn't check until I noticed the indexing gap three weeks post-launch. Running a link audit on localhost:3000 before deploying takes five minutes and saves weeks of confusion.
Automated CI checks are the only checks that actually run. Adding the seo:check script to the build pipeline meant I stopped thinking about it manually and that's the point.

Let's Talk

Have you run into this problem in your own React projects? I'm curious, is the button onClick pattern something you've inherited from an existing codebase, or something that crept in organically?

Drop your experience in the comments. I'd especially love to hear if there are other common React SEO mistakes you've caught the hard way, I'm sure I haven't found all of mine yet.

My Images Were Silently Killing My SEO (And JavaScript Is Both the Cause and the Fix)

Mitu Das — Mon, 01 Jun 2026 09:12:04 +0000

I spent weeks perfecting my site's code, sweating over bundle sizes and Time to Interactive. Then Lighthouse ran and my performance score was 47. The culprit? A 3.2 MB hero image served as a PNG with no lazy loading, no alt text, and dimensions that existed nowhere in my HTML. Google noticed. My users noticed. I didn't.

Image optimization is one of the highest-ROI things I've done for web performance, and most of it can be automated entirely in JavaScript. Here's the practical, copy-paste pipeline I now use, covering the four things that actually moved the needle.

1. Lazy Loading: The Two-Line Win I Was Missing

Native lazy loading has been in browsers since 2019, but I still review codebases weekly where every image loads eagerly. Here's what that costs: every image above and below the fold fires on initial page load, competing for bandwidth with critical resources.

<!-- Before: loads everything immediately -->
<img src="product-photo.jpg" alt="Blue sneaker" />

<!-- After: defers off-screen images -->
<img src="product-photo.jpg" alt="Blue sneaker" loading="lazy" />

That's it for static HTML. But if images are rendered dynamically in JavaScript, I do it like this from the start:

function createOptimizedImage({ src, alt, width, height }) {
  const img = document.createElement('img');
  img.src = src;
  img.alt = alt;
  img.loading = 'lazy';
  img.decoding = 'async'; // non-blocking decode
  if (width) img.width = width;
  if (height) img.height = height; // prevents layout shift (CLS)
  return img;
}

// Usage
const productImg = createOptimizedImage({
  src: '/images/sneaker-blue.jpg',
  alt: 'Blue sneaker, side view',
  width: 800,
  height: 600,
});
document.querySelector('.product-grid').appendChild(productImg);

I always set explicit width and height now. Skipping them is the number one cause of Cumulative Layout Shift (CLS), a Core Web Vital that directly impacts search ranking.

Result: Pages with lazy loading + explicit dimensions routinely cut initial payload by 60-80% on image-heavy pages.

2. Format Conversion: WebP and AVIF Are Not Optional Anymore

JPEG and PNG are legacy formats. WebP delivers equivalent visual quality at 25-35% smaller file sizes. AVIF goes even further, often 50% smaller than JPEG. Both are supported in all modern browsers.

The right way to serve them is with the <picture> element, which lets the browser pick the best format it supports:

<picture>
  <source srcset="/images/hero.avif" type="image/avif" />
  <source srcset="/images/hero.webp" type="image/webp" />
  <img src="/images/hero.jpg" alt="Mountain landscape at dusk" width="1200" height="630" loading="lazy" />
</picture>

To generate those formats as part of a build pipeline, I use Sharp, the fastest Node.js image processing library:

// build/optimize-images.js
import sharp from 'sharp';
import { glob } from 'glob';
import path from 'path';

async function convertToModernFormats(inputGlob) {
  const files = await glob(inputGlob);

  for (const file of files) {
    const dir = path.dirname(file);
    const name = path.basename(file, path.extname(file));
    const image = sharp(file);
    const meta = await image.metadata();

    // Skip if already small
    if (meta.width < 200) continue;

    // Generate WebP
    await image
      .webp({ quality: 80 })
      .toFile(path.join(dir, `${name}.webp`));

    // Generate AVIF (slower to encode, but worth it for static assets)
    await image
      .avif({ quality: 65 })
      .toFile(path.join(dir, `${name}.avif`));

    console.log(`✓ Converted: ${file}`);
  }
}

convertToModernFormats('public/images/**/*.{jpg,jpeg,png}');

I wire this into my package.json build step:

{
  "scripts": {
    "build:images": "node build/optimize-images.js",
    "build": "npm run build:images && vite build"
  }
}

Result: On a recent e-commerce project, this alone dropped total image transfer from 8.4 MB to 3.1 MB, a 63% reduction with no visible quality loss.

3. Responsive Images: I Was Serving 2400px Images to Mobile

Even with WebP, serving a 2400px-wide image to a 390px mobile screen wastes ~90% of the bytes. The srcset and sizes attributes fix this:

<img
  srcset="
    /images/hero-400.webp   400w,
    /images/hero-800.webp   800w,
    /images/hero-1200.webp 1200w,
    /images/hero-2400.webp 2400w
  "
  sizes="
    (max-width: 600px)  100vw,
    (max-width: 1200px) 80vw,
    1200px
  "
  src="/images/hero-1200.webp"
  alt="Hero image"
  width="1200"
  height="630"
  loading="lazy"
/>

I generate those multiple sizes automatically with Sharp:

// build/generate-responsive.js
import sharp from 'sharp';

const BREAKPOINTS = [400, 800, 1200, 1920, 2400];

async function generateResponsiveSizes(inputPath) {
  const image = sharp(inputPath);
  const meta = await image.metadata();
  const name = inputPath.replace(/\.[^.]+$/, '');

  for (const width of BREAKPOINTS) {
    // Don't upscale
    if (width > meta.width) continue;

    await image
      .resize(width)
      .webp({ quality: 80 })
      .toFile(`${name}-${width}.webp`);
  }

  console.log(`✓ Responsive sizes generated for: ${inputPath}`);
}

generateResponsiveSizes('public/images/hero.jpg');

Result: Mobile users download the right-sized image, not a desktop image scaled down by CSS. A 2400px hero image at ~450 KB becomes a 400px version at ~28 KB for mobile, a 16x difference.

4. SEO Metadata: What Google Actually Reads

Page speed is only half the equation. Google also reads alt text, structured data, and Open Graph tags to understand what images are. Getting this right matters for image search ranking and rich results.

For structured data (which powers rich snippets), I inject JSON-LD into the page head. This works programmatically in any framework:

// utils/seo-metadata.js
export function buildImageStructuredData({ url, contentUrl, description, width, height }) {
  return {
    '@context': 'https://schema.org',
    '@type': 'ImageObject',
    url,
    contentUrl,
    description,
    width,
    height,
  };
}

export function injectStructuredData(data) {
  const script = document.createElement('script');
  script.type = 'application/ld+json';
  script.textContent = JSON.stringify(data);
  document.head.appendChild(script);
}

// Usage
injectStructuredData(
  buildImageStructuredData({
    url: 'https://yoursite.com/blog/sneaker-review',
    contentUrl: 'https://yoursite.com/images/sneaker-blue-800.webp',
    description: 'Blue Nike Air Max in profile view on white background',
    width: 800,
    height: 600,
  })
);

For Open Graph (controls how a page looks when shared on social), I add these meta tags server-side or in my framework's head component:

<meta property="og:image" content="https://yoursite.com/images/hero-1200.webp" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="Descriptive alt text here" />

For sites with lots of dynamic content, I've been using the @power-seo npm package to handle structured data generation, Open Graph injection, and canonical tag management in one place. It cut out a lot of boilerplate I was copying between pages. There's a deeper breakdown of what it automates in this guide on javascript image optimization.

What I Learned (The Hard Way)

Explicit width and height on every <img> are non-negotiable. CLS from missing dimensions tanked my Core Web Vitals score more reliably than almost anything else.
Run the image build step before, not after, the JS build. When my bundler processed HTML before WebP files existed, I silently served broken <source> tags in production for two weeks.
alt text is dual-purpose. It's accessibility and an SEO signal. I write it for the user first, but I don't skip it. Images with empty or missing alt are invisible to Google Image Search.
Automate everything in a build script. Manual optimization doesn't survive a deadline. A one-time build:images script running in CI means I never have to think about it again, and neither does anyone else on the team.

What's Your Biggest Image Headache?

Is it the build pipeline? Getting the team to adopt modern formats? Or is it the SEO side, figuring out what Google actually needs to index images properly?

Drop a comment. I'm especially curious whether anyone is using AVIF in production yet, or still holding back because of encode time. The tradeoffs are real and worth talking about.

React App is Invisible to Google: How to Fix It With Open-Source SEO Tools

Mitu Das — Sun, 24 May 2026 07:15:56 +0000

I spent three hours debugging why my freshly deployed React app wasn't showing up in Google Search Console. No crawl errors. No manual penalties. Just... nothing indexed. Turns out, Googlebot was fetching a <div id="root"></div> and giving up before hydration ever happened. The fix was four lines of Next.js config, but I only found it because I stopped trusting dashboards and started reading raw HTTP responses myself.

If you've ever shipped a JS-heavy app and watched your organic traffic flatline, this article is for you. We'll build a real, scriptable SEO audit pipeline using open-source tools. No $299/month Ahrefs subscription required.

Why Paid SEO Platforms Hide the Details That Actually Matter

Commercial SEO tools are optimized for marketers, not engineers. They surface scores and suggestions, but they abstract away the raw signals that tell you why something is broken. You get a "3/10 (Low)" on Technical SEO with a recommendation to "improve page speed" and zero stack trace.

Open-source tools give you the opposite: raw data, full programmatic control, and the ability to integrate audits into your CI pipeline. Let's look at three areas where this matters most.

1. Auditing Rendered HTML vs. Server Response

The single biggest SEO trap for React/Vue/Angular apps is the gap between what your browser sees and what Googlebot fetches. Your browser executes JavaScript. Googlebot's crawler often doesn't. Or it does, but with a ~5-second timeout.

The tool: lighthouse (CLI version, npm i -g lighthouse)

# What Googlebot actually receives (no JS execution)
curl -A "Googlebot/2.1" https://yoursite.com | grep -i "<title>\|<meta name=\"description\"\|<h1"

# What a real browser renders
lighthouse https://yoursite.com \
  --only-categories=seo \
  --output=json \
  --output-path=./seo-report.json \
  --chrome-flags="--headless"

Then diff the two:

// parse-seo-report.js
const fs = require("fs");
const report = JSON.parse(fs.readFileSync("./seo-report.json", "utf8"));

const audits = report.categories.seo.auditRefs
  .map((ref) => report.audits[ref.id])
  .filter((a) => a.score !== null && a.score < 1);

audits.forEach((a) => {
  console.log(`❌ [${a.score}] ${a.title}: ${a.description}`);
});

Run this in CI on every deploy. If your title tag is missing from the curl output but present in Lighthouse, you have a server-side rendering gap. That's your indexing problem, right there.

2. Structured Data Validation Without the GUI

Google's Rich Results Test is a great UI tool, but it doesn't scale. If you have 800 product pages, you need programmatic validation.

The tool: schema-dts (TypeScript types for schema.org) + ajv for runtime validation.

npm install schema-dts ajv

// validate-schema.ts
import Ajv from "ajv";
import addFormats from "ajv-formats";

const ajv = new Ajv({ strict: false });
addFormats(ajv);

// Minimal Article schema (extend as needed)
const articleSchema = {
  type: "object",
  required: ["@context", "@type", "headline", "author", "datePublished"],
  properties: {
    "@context": { type: "string", const: "https://schema.org" },
    "@type": { type: "string", const: "Article" },
    headline: { type: "string", maxLength: 110 },
    author: {
      type: "object",
      required: ["@type", "name"],
    },
    datePublished: { type: "string", format: "date-time" },
  },
};

const validate = ajv.compile(articleSchema);

export function auditStructuredData(jsonLd: object): string[] {
  const valid = validate(jsonLd);
  if (valid) return [];
  return (validate.errors ?? []).map(
    (e) => `${e.instancePath || "root"}: ${e.message}`
  );
}

// Usage
const pageData = {
  "@context": "https://schema.org",
  "@type": "Article",
  headline: "My Post",
  // Missing author and datePublished (will error)
};

const errors = auditStructuredData(pageData);
if (errors.length) {
  console.error("Schema errors:", errors);
  process.exit(1); // Fail the build
}

Wire this into your build step and you'll never accidentally ship a product page with broken structured data again.

3. Automated Crawl Audits With `power-seo`

For a higher-level audit that ties everything together (meta tags, canonical URLs, Open Graph, robots directives, sitemap coverage), I've been using @power-seo. It's an open-source npm package that runs a structured SEO audit on any URL and returns a machine-readable result.

npm install @power-seo

// audit.js
const { auditUrl } = require("@power-seo");

async function runAudit(url) {
  const result = await auditUrl(url);

  const failures = Object.entries(result.checks)
    .filter(([, check]) => check.status === "fail")
    .map(([key, check]) => `  ✗ ${key}: ${check.message}`);

  if (failures.length === 0) {
    console.log(`✅ ${url} passed all checks`);
  } else {
    console.log(`\n❌ ${url} failed ${failures.length} check(s):\n`);
    console.log(failures.join("\n"));
    process.exit(1);
  }
}

runAudit(process.argv[2] || "https://yoursite.com");

Run it as a post-deploy smoke test:

node audit.js https://yoursite.com/blog/my-latest-post

What I like about this approach (and why I write about it over at ccbd.dev) is that it fits into existing engineering workflows. It's not a dashboard you check once a quarter. It's a check that runs on every PR.

What I Learned

The crawl gap is real. If your app doesn't render critical meta content server-side, Googlebot may never see it, regardless of how your site looks in a browser.
Fail fast in CI. SEO regressions are easy to introduce and hard to notice. Treating structured data and meta tags as testable assets (with exit codes) catches them before they ship.
Raw signals beat dashboards. A curl with a Googlebot user-agent tells you more about your indexability than a score out of 100.
Open-source composability wins. Combining lighthouse, ajv, and a lightweight audit package like @power-seo gives you a full audit pipeline for exactly $0/month.

What's Your Setup?

Are you running any SEO checks in your CI pipeline, or is auditing still a manual quarterly thing at your company? I'm especially curious whether anyone has wired Lighthouse scores into GitHub Actions with a hard failure threshold. I've been experimenting with that and it's surprisingly effective.

Drop your setup in the comments.

Why Google Can't See Your React Breadcrumbs (And the 4-Line Fix)

Mitu Das — Sat, 23 May 2026 06:43:33 +0000

I wasted an entire afternoon wondering why Google Search Console kept showing zero rich results for my React app. The breadcrumbs looked perfect in the browser. Users could see them. But Google? Completely blind. The problem wasn't my breadcrumb component it was that I'd never told Google what those breadcrumbs actually were. Structured data. Four lines of JSON-LD. That was it. Here's everything I learned, so you don't lose the same afternoon.

Why React Breadcrumbs Are Invisible to Google

React apps render in the browser. Google's crawler is getting better at parsing JavaScript, but structured data embedded in client-rendered markup is still unreliable for rich results. The gold standard for breadcrumb rich results in Google Search is JSON-LD schema markup injected into <head> not your visible DOM breadcrumb trail.

The two things are completely separate:

Your breadcrumb UI component what users see
Breadcrumb Schema markup what search engines read

Most tutorials show you how to build the UI. Almost none explain the schema side. That's why your breadcrumbs look fine to you but don't show up as rich results in Google.

Here's what a valid BreadcrumbList schema looks like, per Schema.org:

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://example.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "My Article",
      "item": "https://example.com/blog/my-article"
    }
  ]
}

Your job is to get exactly this into a <script type="application/ld+json"> tag in <head> on every page that has breadcrumbs.

The Manual Approach: A Custom React Hook

If you're not using any SEO library, here's a clean, copy-paste hook that builds and injects breadcrumb schema based on your current route.

// hooks/useBreadcrumbSchema.js
import { useEffect } from "react";

export function useBreadcrumbSchema(crumbs) {
  useEffect(() => {
    const schema = {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      itemListElement: crumbs.map((crumb, index) => ({
        "@type": "ListItem",
        position: index + 1,
        name: crumb.label,
        item: crumb.url,
      })),
    };

    const script = document.createElement("script");
    script.type = "application/ld+json";
    script.id = "breadcrumb-schema";
    script.textContent = JSON.stringify(schema);

    // Remove any existing breadcrumb schema before inserting
    document.getElementById("breadcrumb-schema")?.remove();
    document.head.appendChild(script);

    return () => {
      document.getElementById("breadcrumb-schema")?.remove();
    };
  }, [crumbs]);
}

Then in your page component:

// pages/BlogPost.jsx
import { useBreadcrumbSchema } from "../hooks/useBreadcrumbSchema";

export default function BlogPost({ post }) {
  useBreadcrumbSchema([
    { label: "Home", url: "https://example.com" },
    { label: "Blog", url: "https://example.com/blog" },
    { label: post.title, url: `https://example.com/blog/${post.slug}` },
  ]);

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

Result: Every time the component mounts, the correct JSON-LD block is injected into <head> and cleaned up on unmount. Paste it into Google's Rich Results Test and you'll see a green checkmark.

One caveat: if you're using SSR (Next.js, Remix, etc.), this useEffect approach only runs client-side. For SSR, you need to render the script tag server-side which brings us to the next section.

The SSR Problem: Getting Schema Into `<head>` at Build Time

With Next.js, you can't rely on useEffect for schema that needs to be in the initial HTML response. The fix is rendering a <script> tag directly in your component using next/head or the App Router's <Head>:

// app/blog/[slug]/page.jsx (Next.js App Router)
import Head from "next/head";

function buildBreadcrumbSchema(crumbs) {
  return {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    itemListElement: crumbs.map((crumb, i) => ({
      "@type": "ListItem",
      position: i + 1,
      name: crumb.label,
      item: crumb.url,
    })),
  };
}

export default function BlogPost({ params }) {
  const crumbs = [
    { label: "Home", url: "https://example.com" },
    { label: "Blog", url: "https://example.com/blog" },
    { label: "My Post", url: `https://example.com/blog/${params.slug}` },
  ];

  const schema = buildBreadcrumbSchema(crumbs);

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

Now the schema is part of the server-rendered HTML Google sees it immediately, no JavaScript execution required.

Using a Library: When Manual Gets Tedious

The manual approach is fine for one or two page types. But if your app has ten different page templates (product pages, category pages, blog posts, docs), you'll end up copy-pasting and slightly mangling that schema builder everywhere. That's where a dedicated library helps.

I tried a few options and ended up using @power-seo because it handles breadcrumb schema, OpenGraph, and canonical tags from a single config object which matched how I was already thinking about per-page SEO.

npm install @power-seo

import { SEO } from "@power-seo";

export default function BlogPost({ post }) {
  return (
    <>
      <SEO
        breadcrumbs={[
          { label: "Home", url: "https://example.com" },
          { label: "Blog", url: "https://example.com/blog" },
          { label: post.title, url: `https://example.com/blog/${post.slug}` },
        ]}
        title={post.title}
        canonical={`https://example.com/blog/${post.slug}`}
      />
      <article>{/* your content */}</article>
    </>
  );
}

It generates the same JSON-LD output as the manual approach no magic, just less repetition. Whether that's worth a dependency is your call. For small projects, the hook above is plenty.

What I Learned

Your visible breadcrumb UI and your breadcrumb schema are two separate things. One is for users, one is for search engines. Both need to exist.
useEffect-injected schema works for CSR apps, but for SSR/SSG (Next.js, Remix), render the <script> tag server-side inside <head> to guarantee it's in the initial HTML.
Always validate with Google's Rich Results Test (search.google.com/test/rich-results) before assuming it works. It'll show you exactly what schema Google can parse.
Keep your schema in sync with your actual URLs. Stale or mismatched item values in your schema are a silent SEO killer Google will ignore the breadcrumb entirely if the URLs don't resolve.

If you want to see how the full implementation looks in a real Next.js blog (including dynamic route handling), here's a detailed walkthrough: https://ccbd.dev/blog/how-to-implement-breadcrumb-schema-in-react-using-power-seo

What's your setup?

Are you handling structured data manually, using a library, or just skipping it entirely and hoping for the best? I'm curious how other React devs are solving this especially on large apps with lots of page templates. Drop your approach in the comments. If you've found a cleaner pattern than what I've shown here, I genuinely want to know.

DEV Community: Mitu Das

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

Metadata That Actually Renders Per-Page

Sitemaps and Robots.txt as Code, Not Afterthoughts

Structured Data Without the JSON-LD Headache

Verifying It Actually Worked

What I Learned

Your Turn

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

Why Next.js Redirects Break SEO More Than You Think

Auditing Your Redirect Chain Before Writing Any Code

Handling Redirects at the Right Layer

Automating Redirect Management with a Library

Key Takeaways

What's Your Setup?

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

Why the GSC UI Isn't Built for Repeated Checks

Diffing Two Weeks Automatically

Turning It Into a Repeatable SEO Checklist

What I Learned

Your Turn

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

Why a Hand-Rolled Sitemap Breaks Silently

Building a Sitemap That Escapes Properly

Scaling Past 50,000 URLs Without Crashing Your Build

Where I Stopped Writing This From Scratch Every Project

My Pre-Deploy SEO Checklist for Sitemaps

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

Why Ecommerce Sites Become Slow Faster Than You Expect

Why Search Engines Struggle With Product Pages

Organizing Product Data Without Creating Maintenance Chaos

Improving Core Web Vitals With Lazy Loading

What I Learned

Final Thoughts

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

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

Step 1: Audit What Google Actually Sees

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

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

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

What I Learned

Your Turn

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

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

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

2. Automate Structured Data with JSON-LD

3. Integrate an SEO API to Audit at Scale

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

What I Learned

What's Your SEO Setup?

I Built an SEO Content Checker Into My React App Here's the Exact Setup

Why React Apps Have an SEO Blind Spot

Step 1: Audit Your Existing Pages With a Node Script

Step 2: Add a React SEO Checklist as a Dev-Mode Overlay

Step 3: Pull It Into CI With a Proper Checker Package

What I Actually Learned

What's your SEO workflow?

Internal linking gaps are silently killing your React app's SEO

Why React Apps Are Especially Bad at Internal Linking

Step 1: Find Your Orphaned Pages Programmatically

Step 2: Fix the Most Common Patterns

Step 3: Automate This Check Going Forward

What I Actually Learned From This

Let's Talk

My Images Were Silently Killing My SEO (And JavaScript Is Both the Cause and the Fix)

1. Lazy Loading: The Two-Line Win I Was Missing

2. Format Conversion: WebP and AVIF Are Not Optional Anymore

3. Responsive Images: I Was Serving 2400px Images to Mobile

4. SEO Metadata: What Google Actually Reads

What I Learned (The Hard Way)

What's Your Biggest Image Headache?

React App is Invisible to Google: How to Fix It With Open-Source SEO Tools

Why Paid SEO Platforms Hide the Details That Actually Matter

1. Auditing Rendered HTML vs. Server Response

2. Structured Data Validation Without the GUI

3. Automated Crawl Audits With power-seo

What I Learned

What's Your Setup?

Why Google Can't See Your React Breadcrumbs (And the 4-Line Fix)

Why React Breadcrumbs Are Invisible to Google

3. Automated Crawl Audits With `power-seo`

The SSR Problem: Getting Schema Into `<head>` at Build Time