DEV Community: Mitu Das

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.

Next.js SEO Meta Tags: The Mistakes That Cost Me 3 Weeks of Traffic

Mitu Das — Wed, 20 May 2026 10:25:00 +0000

I launched a Next.js project, waited three weeks for Google traffic, and got nothing. Not "slow growth" nothing completely invisible nothing. The Search Console showed Googlebot visiting but not indexing. The culprit? I had metadata in the wrong place, and my <title> tag was rendering client-side, after Googlebot had already moved on.

If you're building with Next.js (App Router or Pages Router), this article will walk you through setting meta tags correctly including dynamic tags per page, Open Graph for social sharing, and canonical URLs. No fluff, just working code.

Why Next.js Meta Tags Break More Than You'd Expect

The core problem is rendering timing. In a traditional React SPA, everything renders in the browser which means Googlebot often crawls your page before JavaScript runs, sees a blank <head>, and either defers indexing or skips it.

Next.js solves this with server-side rendering, but only if you use the right APIs. A lot of developers (myself included, initially) reach for react-helmet or manually insert <head> tags in components. That works on the client but not reliably during SSR.

The rule: Always use Next.js's built-in metadata system. In the App Router, that's the metadata export or generateMetadata. In the Pages Router, it's next/head.

App Router: Static and Dynamic Metadata

Static metadata (layout or page level)

For pages where the title and description don't change, export a metadata object:

// app/about/page.tsx
import type { Metadata } from 'next'

export const metadata: Metadata = {
  title: 'About Us  Acme Corp',
  description: 'Learn about the team behind Acme Corp and our mission.',
  openGraph: {
    title: 'About Us  Acme Corp',
    description: 'Learn about the team behind Acme Corp and our mission.',
    url: 'https://acmecorp.com/about',
    siteName: 'Acme Corp',
    type: 'website',
  },
  twitter: {
    card: 'summary_large_image',
    title: 'About Us  Acme Corp',
    description: 'Learn about the team behind Acme Corp and our mission.',
  },
  alternates: {
    canonical: 'https://acmecorp.com/about',
  },
}

export default function AboutPage() {
  return <main>...</main>
}

This gets rendered server-side. Googlebot sees it immediately, no JavaScript required.

Dynamic metadata (for blog posts, product pages, etc.)

When titles and descriptions come from a database or CMS, use generateMetadata:

// 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) // your data-fetching function

  return {
    title: `${post.title}  My Blog`,
    description: post.excerpt,
    openGraph: {
      title: post.title,
      description: post.excerpt,
      url: `https://myblog.com/blog/${params.slug}`,
      type: 'article',
      publishedTime: post.publishedAt,
      images: [
        {
          url: post.coverImage,
          width: 1200,
          height: 630,
          alt: post.title,
        },
      ],
    },
    alternates: {
      canonical: `https://myblog.com/blog/${params.slug}`,
    },
  }
}

Next.js calls generateMetadata on the server before rendering. The fetched data is automatically deduped with any matching fetch calls in the page component itself you won't hit your API twice.

Pages Router: Using `next/head`

If you're on the Pages Router, the equivalent is importing Head from next/head:

// pages/blog/[slug].tsx
import Head from 'next/head'
import { GetServerSideProps } from 'next'

type Post = {
  title: string
  excerpt: string
  slug: string
  coverImage: string
}

export default function BlogPost({ post }: { post: Post }) {
  const url = `https://myblog.com/blog/${post.slug}`

  return (
    <>
      <Head>
        <title>{post.title}  My Blog</title>
        <meta name="description" content={post.excerpt} />
        <link rel="canonical" href={url} />
        <meta property="og:title" content={post.title} />
        <meta property="og:description" content={post.excerpt} />
        <meta property="og:url" content={url} />
        <meta property="og:type" content="article" />
        <meta property="og:image" content={post.coverImage} />
        <meta name="twitter:card" content="summary_large_image" />
      </Head>
      <main>...</main>
    </>
  )
}

export const getServerSideProps: GetServerSideProps = async ({ params }) => {
  const post = await fetchPost(params?.slug as string)
  return { props: { post } }
}

Because getServerSideProps runs on the server, the Head content is populated before the HTML reaches the browser. This is what you want.

What not to do: Don't put <Head> tags inside a useEffect. They'll be client-only and won't be seen by crawlers.

One Thing That Helped Me Catch Tag Problems Early

After fixing the core implementation, I was still second-guessing myself on every new page had I remembered canonical URLs? Were the OG image dimensions right? Was the description truncated?

I ended up using a package called @power-seo that audits your metadata at build time and flags issues (missing descriptions, duplicate titles, canonical mismatches) as warnings. You integrate it in your CI pipeline and it catches regressions before they ship.

The setup is straightforward:

npm install @power-seo --save-dev

// In your CI script or as a Next.js plugin
import { auditMetadata } from '@power-seo'

// Runs against your sitemap or a list of URLs
await auditMetadata({
  urls: ['https://yoursite.com', 'https://yoursite.com/blog'],
  rules: ['title', 'description', 'canonical', 'og:image'],
})

It's not magic you still need to write the metadata correctly. But it stops the "wait three weeks to find out Google couldn't see anything" loop. More background on common pitfalls that cause silent SEO failures: https://ccbd.dev/blog/nextjs-seo-meta-tags-mistake-that-cost-3-weeks-of-traffic

What I Learned (The Hard Way)

Server-side is non-negotiable. Any metadata set inside useEffect or a client component is invisible to Googlebot. Use generateMetadata or getServerSideProps/getStaticProps always.
Canonical URLs prevent duplicate content penalties. If your blog post lives at /blog/my-post and also gets queried at /blog/my-post?ref=twitter, Google sees two URLs with the same content. Add a canonical pointing to the clean URL on every page.
OG images need exact dimensions. Twitter/X expects 1200×630px for summary_large_image. A close-but-wrong size often renders as a tiny thumbnail or no image at all. Automate image generation with next/og if your designs allow it.
Title templates save time and prevent inconsistency. In the App Router, define a title.template in your root layout.tsx like "%s | My Site" child pages just set the %s part and the suffix is added automatically.

If you want to try this approach, here's the repo: https://ccbd.dev/blog/nextjs-seo-meta-tags-mistake-that-cost-3-weeks-of-traffic

What's the weirdest SEO bug you've hit in a Next.js project? I'm convinced there's an entire graveyard of launches that went unnoticed because of a missing generateMetadata export. Drop your war stories below I'd genuinely love to hear what tripped you up, and maybe we can save someone else the same pain.

SEO Mistakes That Are Silently Killing Your Dev Projects

Mitu Das — Tue, 19 May 2026 09:58:03 +0000

I spent 3 hours debugging why Google couldn't crawl my React app. Lighthouse scores were green. The app loaded fine in the browser. But Googlebot was seeing a blank <div id="root"></div> and walking away confused. The fix was 4 lines of meta tags and a prerender config I'd been skipping for months.

If you've ever launched a side project and wondered why it sits at position 94 forever this one's for you. These are the SEO mistakes I see constantly in developer-built projects, with the actual code to fix each one.

Mistake #1: Your `<head>` Is Almost Empty

This is the most common one. You scaffold a Vite or CRA project, get lost in the fun part (building features), and ship with a <title> tag that just says "React App."

Google uses your <head> to understand what your page is about. If it's empty or generic, you're asking the algorithm to guess and it usually guesses wrong.

Here's what a proper meta setup looks like:

<!-- index.html or your _document.tsx in Next.js -->
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />

  <!-- The basics Google actually reads -->
  <title>SyncBoard – Real-Time Collaborative Whiteboards for Remote Teams</title>
  <meta name="description" content="Create, share, and collaborate on visual boards in real time. No signup needed. Works in any browser." />

  <!-- Open Graph for social sharing (also used by some search engines) -->
  <meta property="og:title" content="SyncBoard – Real-Time Collaborative Whiteboards" />
  <meta property="og:description" content="Visual collaboration for remote teams. No signup needed." />
  <meta property="og:image" content="https://syncboard.app/og-image.png" />
  <meta property="og:url" content="https://syncboard.app" />
  <meta property="og:type" content="website" />

  <!-- Twitter Card -->
  <meta name="twitter:card" content="summary_large_image" />
  <meta name="twitter:title" content="SyncBoard – Real-Time Collaborative Whiteboards" />
  <meta name="twitter:description" content="Visual collaboration for remote teams." />
  <meta name="twitter:image" content="https://syncboard.app/og-image.png" />
</head>

Result: Google now has a clear signal for what to rank your page for. Your Twitter/LinkedIn shares show a proper preview card instead of a broken link. That alone increases click-through rates.

For multi-page apps, each route needs its own unique title and description. In React, use react-helmet-async. In Next.js, use the built-in <Head> component or the newer metadata export.

Mistake #2: Client-Side Rendering Is Invisible to Crawlers (Sometimes)

Googlebot can execute JavaScript but it does so in a low-priority queue that can take days or weeks. For a brand-new site, that means your content might not get indexed for a long time, if ever.

The safest fix: generate your HTML on the server, or at build time.

// Next.js generateStaticParams for static generation
// This creates actual HTML files at build time. Zero JS required for indexing.

export async function generateStaticParams() {
  const posts = await fetch('https://your-api.com/posts').then(r => r.json());
  return posts.map(post => ({ slug: post.slug }));
}

export default async function BlogPost({ params }) {
  const post = await fetch(`https://your-api.com/posts/${params.slug}`)
    .then(r => r.json());

  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.excerpt}</p>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );
}

If you're not on Next.js and can't do SSR/SSG, consider prerendering. Tools like prerender.io or vite-plugin-ssr can serve static HTML snapshots to crawlers while still delivering the full SPA experience to real users.

The key diagnostic: open your browser's DevTools, disable JavaScript, and reload your page. If it's blank so is Googlebot's view of your site.

Mistake #3: You Have No Structured Data

Structured data (JSON-LD) is how you communicate with search engines in their native language. It's what powers rich results star ratings in search, FAQ dropdowns, article publishing dates, product prices. You're leaving real estate on the results page unclaimed.

This one is frustratingly easy to add and almost nobody does it:

<!-- Add this to your <head> or just before </body> -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "SEO Mistakes That Are Silently Killing Your Dev Projects",
  "description": "The most common SEO errors in developer-built projects, with working code fixes.",
  "datePublished": "2026-05-19",
  "dateModified": "2026-05-19",
  "author": {
    "@type": "Person",
    "name": "Your Name",
    "url": "https://yoursite.dev"
  },
  "publisher": {
    "@type": "Organization",
    "name": "YourBlog",
    "logo": {
      "@type": "ImageObject",
      "url": "https://yoursite.dev/logo.png"
    }
  },
  "image": "https://yoursite.dev/article-image.png",
  "url": "https://yoursite.dev/articles/seo-mistakes"
}
</script>

For e-commerce, add Product schema. For tools and SaaS, SoftwareApplication schema. For FAQ pages, FAQPage schema. The Schema.org validator will tell you immediately if you've got it right.

Mistake #4: Your sitemap.xml Is Missing or Stale

Google finds new pages by crawling links but a sitemap is the express lane. Without one, internal pages (especially anything not linked from your homepage) might never get discovered.

Here's a minimal sitemap generator you can run at build time:

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

const BASE_URL = 'https://yoursite.dev';

// Pull your routes from wherever they live a CMS, a file system, a DB
const routes = [
  { path: '/', changefreq: 'weekly', priority: 1.0 },
  { path: '/blog', changefreq: 'daily', priority: 0.9 },
  { path: '/projects', changefreq: 'monthly', priority: 0.7 },
  { path: '/about', changefreq: 'yearly', priority: 0.5 },
];

const sitemap = `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
${routes.map(route => `
  <url>
    <loc>${BASE_URL}${route.path}</loc>
    <changefreq>${route.changefreq}</changefreq>
    <priority>${route.priority}</priority>
    <lastmod>${new Date().toISOString().split('T')[0]}</lastmod>
  </url>`).join('')}
</urlset>`;

fs.writeFileSync('./public/sitemap.xml', sitemap.trim());
console.log(`✓ Sitemap generated with ${routes.length} URLs`);

Add node scripts/generate-sitemap.js to your build script, then submit https://yoursite.dev/sitemap.xml in Google Search Console. You'll start seeing crawl coverage improve within a few days.

For projects where you want all of this meta tags, OG images, JSON-LD, sitemaps managed in one place, I recently came across @power-seo, an npm package that handles the boilerplate of setting these up consistently across a site. It's worth a look if you're tired of copy-pasting meta tag templates between projects.

What I Actually Learned

The blank <head> problem is epidemic in dev projects. It takes 20 minutes to fix and has an outsized impact on whether anyone discovers your work.
Test with JS disabled. It's the fastest way to see exactly what Googlebot sees. If your content disappears, you need SSR or prerendering.
JSON-LD is low-effort, high-reward. One <script> tag can unlock rich results. Most devs skip it; that's your competitive edge.
Sitemaps aren't just for enterprise sites. Even a 5-page portfolio benefits from one. Generate it at build time and forget about it.

If you want to see how I pulled all of this together on a recent project, here's the writeup: https://ccbd.dev/blog/seo-mistakes-fixed-using-the-power-seo-toolkit

What's Your Biggest SEO Headache?

I'm curious which of these bit you hardest? Did you ship a React app that sat invisible in search for months? Are you on a team where "we'll add SEO later" is a running joke? Drop it in the comments. I read every one, and honestly the war stories are the best part of this community.

I Built a Free JavaScript SEO Audit Tool After Google Ignored My React App for 3 Months

Mitu Das — Mon, 18 May 2026 10:25:11 +0000

I spent three months wondering why my React app was getting zero organic traffic. Google Search Console showed pages being "discovered" but not indexed. The Lighthouse score looked fine. Everything seemed okay.

Then I fetched my site through Googlebot's eyes using fetch as Google and saw a blank white page.

The culprit? Client-side rendering with no fallback, missing meta tags injected after hydration, and a canonical URL pointing to a development URL I forgot to update. None of these showed up in my usual workflow. In 2026, JavaScript SEO is still a trap most developers fall into at least once. Here's how to catch these issues before Google does.

Why JavaScript Apps Break SEO in Ways Static HTML Doesn't

The fundamental problem is timing. Googlebot is smart, but it crawls JavaScript apps differently than a browser would:

It fetches the initial HTML response
It queues the page for JavaScript rendering (which can take days)
It renders, then re-indexes

If your meta tags, canonical URLs, or structured data are injected after JavaScript runs, you're at the mercy of Google's render queue. For new pages, this can mean weeks of invisibility.

Static HTML sites don't have this problem. A <title> tag in a .html file is immediately readable. A <title> set via document.title = "..." in a React useEffect is not at least not reliably on first crawl.

Here's a quick check you can run in Node.js to see what Googlebot actually sees:

// seo-check.js  fetch your page without JavaScript, like a basic crawler would
const https = require('https');

function crawlPage(url) {
  return new Promise((resolve, reject) => {
    const options = {
      headers: {
        'User-Agent': 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)'
      }
    };

    https.get(url, options, (res) => {
      let data = '';
      res.on('data', chunk => data += chunk);
      res.on('end', () => {
        const hasTitle = /<title>(.+?)<\/title>/i.test(data);
        const hasDescription = /name="description"/i.test(data);
        const hasCanonical = /rel="canonical"/i.test(data);
        const hasH1 = /<h1/i.test(data);

        console.log('SEO Snapshot (pre-JS render):');
        console.log('  Title tag present:', hasTitle);
        console.log('  Meta description:', hasDescription);
        console.log('  Canonical URL:', hasCanonical);
        console.log('  H1 tag:', hasH1);

        resolve({ hasTitle, hasDescription, hasCanonical, hasH1 });
      });
    }).on('error', reject);
  });
}

crawlPage('https://yoursite.com').then(result => {
  const score = Object.values(result).filter(Boolean).length;
  console.log(`\nBasic SEO score: ${score}/4`);
});

Run it. If you get Title tag present: false on a React app, you have a problem.

Auditing Structured Data and Open Graph Tags Programmatically

Missing meta tags are just the beginning. Structured data (JSON-LD) errors are invisible to the naked eye but actively hurt rich results eligibility. Open Graph tags determine how your links look when shared on Slack, X, or LinkedIn.

You can audit both with cheerio a server-side HTML parser that doesn't execute JavaScript (which is exactly the point):

npm install cheerio node-fetch

// audit-metadata.js
import fetch from 'node-fetch';
import * as cheerio from 'cheerio';

async function auditPage(url) {
  const res = await fetch(url);
  const html = await res.text();
  const $ = cheerio.load(html);

  // Check Open Graph
  const og = {
    title: $('meta[property="og:title"]').attr('content'),
    description: $('meta[property="og:description"]').attr('content'),
    image: $('meta[property="og:image"]').attr('content'),
    url: $('meta[property="og:url"]').attr('content'),
  };

  // Check JSON-LD structured data
  const jsonLdBlocks = [];
  $('script[type="application/ld+json"]').each((_, el) => {
    try {
      jsonLdBlocks.push(JSON.parse($(el).html()));
    } catch (e) {
      jsonLdBlocks.push({ error: 'Invalid JSON', raw: $(el).html().slice(0, 100) });
    }
  });

  // Check canonical
  const canonical = $('link[rel="canonical"]').attr('href');

  console.log('\n=== Open Graph ===');
  Object.entries(og).forEach(([key, val]) => {
    console.log(`  og:${key}: ${val || '❌ MISSING'}`);
  });

  console.log('\n=== Canonical ===');
  console.log(' ', canonical || '❌ MISSING');

  console.log('\n=== JSON-LD Blocks Found ===');
  console.log(` ${jsonLdBlocks.length} block(s)`);
  jsonLdBlocks.forEach((block, i) => {
    if (block.error) {
      console.log(`  Block ${i + 1}: ❌ Parse error  ${block.error}`);
    } else {
      console.log(`  Block ${i + 1}: ✅ Type = ${block['@type'] || 'unknown'}`);
    }
  });
}

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

This gives you a static HTML snapshot of exactly what a non-JS crawler sees. If your OG tags show ❌ MISSING but you know you set them in your React component, they're being injected after render fix them server-side or use a proper SSR/SSG setup.

Automating Multi-Page Audits with a Crawl Script

Checking one page is useful. Checking your entire sitemap is necessary. Here's a minimal crawler that pulls URLs from your sitemap and runs the audit across all of them:

// crawl-sitemap.js
import fetch from 'node-fetch';
import * as cheerio from 'cheerio';

async function getSitemapUrls(sitemapUrl) {
  const res = await fetch(sitemapUrl);
  const xml = await res.text();
  const $ = cheerio.load(xml, { xmlMode: true });
  return $('loc').map((_, el) => $(el).text()).get();
}

async function quickAudit(url) {
  try {
    const res = await fetch(url, { timeout: 8000 });
    const html = await res.text();
    const $ = cheerio.load(html);
    return {
      url,
      title: $('title').text() || null,
      canonical: $('link[rel="canonical"]').attr('href') || null,
      h1Count: $('h1').length,
      hasDescription: !!$('meta[name="description"]').attr('content'),
    };
  } catch (e) {
    return { url, error: e.message };
  }
}

async function auditSitemap(sitemapUrl) {
  console.log(`Fetching sitemap: ${sitemapUrl}\n`);
  const urls = await getSitemapUrls(sitemapUrl);
  console.log(`Found ${urls.length} URLs. Auditing...\n`);

  const results = [];
  for (const url of urls) {
    const result = await quickAudit(url);
    results.push(result);

    const issues = [];
    if (!result.title) issues.push('no title');
    if (!result.canonical) issues.push('no canonical');
    if (result.h1Count !== 1) issues.push(`${result.h1Count} H1 tags`);
    if (!result.hasDescription) issues.push('no meta description');

    const status = issues.length === 0 ? '✅' : '⚠️ ';
    console.log(`${status} ${url}`);
    if (issues.length > 0) console.log(`   Issues: ${issues.join(', ')}`);
  }

  const clean = results.filter(r => !r.error && r.title && r.canonical).length;
  console.log(`\nSummary: ${clean}/${urls.length} pages passed basic audit`);
}

auditSitemap('https://yoursite.com/sitemap.xml');

Run this before every major deploy. It catches the obvious stuff missing titles, duplicate H1s, canonical mismatches in under a minute.

Going Deeper: When You Need More Than a Script

These scripts cover the fundamentals well, but they don't catch everything: Core Web Vitals, crawl depth, internal link structure, redirect chains, or hreflang mismatches. For a more complete picture without spinning up Screaming Frog or paying for an enterprise tool, I came across power-seo a free, open-source npm package built for JavaScript-heavy sites.

What caught my attention: it runs a headless browser audit (so it sees your post-render HTML, not just the raw response), checks Core Web Vitals, and flags JavaScript-specific issues like render-blocking scripts and hydration mismatches. It's not magic, but it filled the gap between "I wrote a crawler script" and "I need a $400/month SEO platform."

You install it globally and point it at a URL:

npm install -g power-seo
power-seo audit https://yoursite.com --output report.json

The JSON output is structured enough to pipe into CI so you can fail a build if, say, a critical page loses its title tag after a component refactor.

For a full walkthrough of how it handles JavaScript rendering specifically, the team wrote it up here: Free JavaScript SEO Audit Tool Every Developer Needs in 2026.

What I Learned (After Losing 3 Months of Potential Traffic)

Never assume your meta tags are in the HTML. Use curl -A "Googlebot" or a raw fetch without JS execution to verify what crawlers actually see on first hit.
One H1 per page, always. It's the most common mistake in component-driven UIs multiple components each thinking they "own" the heading.
Canonical URLs in SPAs are a footgun. If you're using client-side routing, double-check that your canonical tag updates correctly on navigation. A static canonical pointing to / on every route is an indexing disaster.
Build SEO checks into your CI pipeline. A five-minute audit script catching a missing title before deploy is infinitely better than discovering it two weeks later in Search Console.

What's your biggest JavaScript SEO headache?

I'm genuinely curious is it the render timing issue, or something more obscure like hreflang in a Next.js app, or structured data that validates in the Rich Results Test but never shows up in SERPs?

Drop it in the comments. I've probably hit it too, and if I haven't, someone else in this thread has. These problems are a lot less frustrating when you're not debugging them alone at 11pm.

React E-commerce App Is Invisible to Google - Here's Why (and the Fix)

Mitu Das — Sun, 17 May 2026 11:35:35 +0000

I spent a weekend wondering why a client's Next.js store had zero Google Shopping impressions after three months live. The site looked great. Performance scores were solid. But Googlebot was essentially blind to 80% of the product catalog.

The culprit wasn't the framework. It was a handful of missing metadata patterns that most frontend developers never learn because they're not in any React tutorial. This article walks through the exact fixes - structured data, canonical URLs, dynamic meta tags, and crawlability traps - with copy-paste code for each.

Why React E-commerce Apps Fail at SEO (The Actual Reason)

Server-side rendering is not enough on its own. A lot of developers ship Next.js and assume SSR = SEO sorted. It's not.

Google can render JavaScript, but it does so in a secondary crawl queue - sometimes days later. More importantly, even if your HTML is server-rendered, if it's missing the signals that tell Google what kind of page it is, you lose rich results: the star ratings, price ranges, and availability labels that lift click-through rate by 20–30%.

The three layers that matter for e-commerce SEO:

Structured data - JSON-LD that tells Google "this is a product with a price and reviews"
Dynamic meta tags - unique <title>, <description>, and <og:*> per page, not one global template
Canonical + pagination signals - prevents duplicate content from filters, sorting, and faceted navigation eating your crawl budget

Let's fix all three.

1. Add Product Structured Data (JSON-LD)

This is the biggest missed opportunity. Without it, Google will never show price, availability, or review stars in search results.

Create a reusable component:

// components/ProductSchema.tsx
import Head from 'next/head';

interface ProductSchemaProps {
  name: string;
  description: string;
  image: string;
  price: number;
  currency: string;
  availability: 'InStock' | 'OutOfStock' | 'PreOrder';
  sku: string;
  brand: string;
  ratingValue?: number;
  reviewCount?: number;
}

export function ProductSchema({
  name, description, image, price, currency,
  availability, sku, brand, ratingValue, reviewCount,
}: ProductSchemaProps) {
  const schema = {
    '@context': 'https://schema.org',
    '@type': 'Product',
    name,
    description,
    image,
    sku,
    brand: { '@type': 'Brand', name: brand },
    offers: {
      '@type': 'Offer',
      price: price.toFixed(2),
      priceCurrency: currency,
      availability: `https://schema.org/${availability}`,
      url: typeof window !== 'undefined' ? window.location.href : '',
    },
    ...(ratingValue && reviewCount && {
      aggregateRating: {
        '@type': 'AggregateRating',
        ratingValue,
        reviewCount,
      },
    }),
  };

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

Use it in your product page:

// pages/products/[slug].tsx
import { ProductSchema } from '@/components/ProductSchema';

export default function ProductPage({ product }) {
  return (
    <>
      <ProductSchema
        name={product.name}
        description={product.description}
        image={product.images[0].url}
        price={product.price}
        currency="USD"
        availability={product.inStock ? 'InStock' : 'OutOfStock'}
        sku={product.sku}
        brand={product.brand}
        ratingValue={product.rating.average}
        reviewCount={product.rating.count}
      />
      {/* rest of page */}
    </>
  );
}

Result: Google can now surface price, availability, and stars directly in search results. Validate with Rich Results Test.

2. Dynamic Meta Tags Per Product Page

One of the most common e-commerce SEO sins: a single <title> template that outputs "Product | Store Name" on every single page, with a description that never changes.

Here's a Next.js generateMetadata pattern that does it properly:

// app/products/[slug]/page.tsx (Next.js 13+ App Router)
import type { Metadata } from 'next';

interface Props {
  params: { slug: string };
}

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

  const title = `${product.name} - ${product.brand} | ${product.price} ${product.currency}`;
  const description = `${product.description.slice(0, 140)}. Free shipping on orders over $50.`;

  return {
    title,
    description,
    openGraph: {
      title,
      description,
      images: [{ url: product.images[0].url, width: 1200, height: 630 }],
      type: 'website',
    },
    // Prevent indexing of out-of-stock or archived products
    robots: product.archived
      ? { index: false, follow: false }
      : { index: true, follow: true },
  };
}

For Pages Router (Next.js 12 and earlier), use next/head inside getServerSideProps or getStaticProps - same pattern, different delivery mechanism.

Result: Every product page gets a unique, keyword-rich title and description. This alone can meaningfully improve organic CTR.

3. Canonical URLs and Faceted Navigation

This is the silent crawl budget killer. Your /products?color=red&sort=price-asc and /products?sort=price-asc&color=red are two different URLs serving the same content. Multiply that by 15 filter dimensions and you've created thousands of duplicate pages that dilute your link equity and waste Googlebot's time.

Fix it with canonical tags:

// lib/getCanonicalUrl.ts
export function getCanonicalUrl(basePath: string, preservedParams: string[] = []) {
  if (typeof window === 'undefined') return basePath;

  const url = new URL(window.location.href);
  const canonical = new URL(basePath, window.location.origin);

  // Only keep SEO-meaningful params (e.g., category, page)
  // Drop sort, color, size, etc.
  preservedParams.forEach(param => {
    if (url.searchParams.has(param)) {
      canonical.searchParams.set(param, url.searchParams.get(param)!);
    }
  });

  return canonical.toString();
}

// In your category/listing page
import Head from 'next/head';
import { getCanonicalUrl } from '@/lib/getCanonicalUrl';

export default function CategoryPage() {
  const canonical = getCanonicalUrl('/products/shoes', ['page', 'category']);

  return (
    <Head>
      <link rel="canonical" href={canonical} />
    </Head>
  );
}

For pagination, add rel="next" and rel="prev" - Google still uses these as hints even though they're no longer "officially" supported:

{currentPage > 1 && (
  <link rel="prev" href={`/products?page=${currentPage - 1}`} />
)}
{currentPage < totalPages && (
  <link rel="next" href={`/products?page=${currentPage + 1}`} />
)}

Result: You consolidate link equity onto the canonical URL instead of scattering it across hundreds of filter permutations.

4. Automating This Across a Large Catalog

Doing all of the above manually for a 5,000-SKU catalog is impractical. This is where a metadata orchestration layer helps. I've been testing @power-seo for exactly this - it's an npm package that generates structured data, meta tags, and canonical patterns from your product data model, without needing to hand-write schemas for every page type.

npm install @power-seo

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

const { structuredData, metaTags, canonical } = generateProductMeta({
  product,
  baseUrl: 'https://yourstore.com',
  preservedFilterParams: ['category', 'page'],
});

It handles the JSON-LD generation, deduplication logic, and meta tag formatting in one pass. Not a magic bullet - you still need to understand what it's doing - but it removes the boilerplate when you're working at scale.

What I Learned

Structured data is not optional for e-commerce. Rich results (price, availability, stars) are only possible with JSON-LD. Without it, you're competing in plain blue-link results against sites that have it.
"SSR means SEO is handled" is a dangerous assumption. SSR gets your HTML crawled; it doesn't tell Google what the page means.
Faceted navigation is the most underestimated crawl budget problem in e-commerce. Canonical tags are cheap to implement and pay off significantly on large catalogs.
Dynamic meta tags per page are table stakes. A shared template is better than nothing; unique, data-driven titles and descriptions are better still.

If you want to try this approach, here's the repo: https://ccbd.dev/blog/e-commerce-seo-playbook-for-maximum-traffic-in-2026

What's Your Biggest E-commerce SEO Headache?

I've found structured data and canonicalization cover about 70% of the technical debt in most React stores - but every catalog is different. What SEO issue has caused you the most pain on a commerce project? Internationalization with hreflang? Core Web Vitals on image-heavy product pages? Crawl budget on huge catalogs?

Drop it in the comments - genuinely curious what patterns others are running into, and happy to dig into specific problems.

Open Graph React SEO: Why React App Looks Broken on Twitter And How to Fix It

Mitu Das — Thu, 14 May 2026 06:50:31 +0000

I spent nearly 3 hours debugging why my React app looked perfect in the browser but turned into a blank card when shared on Twitter.

No image. No title. No description.

Just a sad naked URL.

The frustrating part was that my meta tags were technically correct. The real issue was simpler: most social crawlers do not execute client-side React the same way browsers do.

In this article, you’ll learn how to fix Open Graph React SEO properly using server-rendered meta tags, generate dynamic OG images, and avoid the most common SEO mistakes in React apps without rebuilding your entire stack.

The React SEO Problem Nobody Notices Until Production

If you’ve built a React SPA using Vite, CRA, or React Router, your index.html probably looks something like this:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>My React App</title>
    <meta name="description" content="Cool app" />
  </head>
  <body>
    <div id="root"></div>
    <script type="module" src="/src/main.jsx"></script>
  </body>
</html>

Then somewhere inside React:

import { Helmet } from "react-helmet";

export default function BlogPost() {
  return (
    <>
      <Helmet>
        <title>React SEO Guide</title>

        <meta
          property="og:title"
          content="React SEO Guide"
        />

        <meta
          property="og:description"
          content="How to fix Open Graph tags in React"
        />
      </Helmet>

      <h1>Blog Post</h1>
    </>
  );
}

Looks correct, right?

But many crawlers fetch the initial HTML before React hydrates.

That means they only see:

<title>My React App</title>

…and completely miss your dynamic Open Graph tags.

Result:

Broken social previews
Wrong titles on Discord, Twitter, and LinkedIn
Poor indexing
Lower click-through rates

This is one of the most common Open Graph React SEO issues developers run into.

The Fastest Fix Is Injecting OG Tags Server Side

You do not need to migrate your app to Next.js.

You just need the server to return fully rendered meta tags.

Here’s a lightweight Express setup that works with existing React apps.

Step 1: Create an Express server

Install Express:

npm install express

Create server.js:

import express from "express";
import fs from "fs";
import path from "path";

const app = express();

app.use(express.static("dist"));

app.get("/post/:slug", (req, res) => {
  const slug = req.params.slug;

  const post = {
    title: "Fix React Open Graph Tags",
    description: "Dynamic OG tags for React apps",
    image: "https://mysite.com/og-image.png"
  };

  let html = fs.readFileSync(
    path.resolve("dist/index.html"),
    "utf8"
  );

  html = html
    .replace("__TITLE__", post.title)
    .replace("__DESCRIPTION__", post.description)
    .replace("__IMAGE__", post.image);

  res.send(html);
});

app.listen(3000);

Step 2: Add placeholders to `index.html`

<head>
  <title>__TITLE__</title>

  <meta
    property="og:title"
    content="__TITLE__"
  />

  <meta
    property="og:description"
    content="__DESCRIPTION__"
  />

  <meta
    property="og:image"
    content="__IMAGE__"
  />
</head>

Now crawlers receive the correct tags immediately.

No hydration required.

Result

When someone shares:

https://mysite.com/post/react-seo-guide

Twitter, Discord, LinkedIn, and Facebook now render:

Correct title
Correct description
Preview image

This is the core fix behind most Open Graph React SEO problems.

Dynamic OG Images Improve CTR More Than Most Developers Expect

Most developers stop after adding titles and descriptions.

But preview images dramatically improve click-through rates.

Static images work, but dynamic images are much better for blogs, changelogs, dashboards, and documentation pages.

Here’s a simple dynamic OG image endpoint using React and Satori.

Install dependencies:

npm install satori sharp

Create og.js:

import satori from "satori";
import sharp from "sharp";

export async function generateOgImage(title) {
  const svg = await satori(
    {
      type: "div",
      props: {
        style: {
          display: "flex",
          width: "1200px",
          height: "630px",
          background: "#111",
          color: "#fff",
          alignItems: "center",
          justifyContent: "center",
          fontSize: "64px",
          padding: "40px"
        },
        children: title
      }
    },
    {
      width: 1200,
      height: 630
    }
  );

  return sharp(Buffer.from(svg))
    .png()
    .toBuffer();
}

Add route:

app.get("/og/:title", async (req, res) => {
  const image = await generateOgImage(
    req.params.title
  );

  res.set("Content-Type", "image/png");
  res.send(image);
});

Now your OG tag becomes:

<meta
  property="og:image"
  content="https://mysite.com/og/react-seo-guide"
/>

Result

Every shared article automatically gets a branded preview image.

That alone can significantly improve engagement on:

Dev.to
Twitter/X
Reddit
LinkedIn
Discord

Crawlers also cache aggressively, so dynamic images help prevent stale previews from sticking around too long.

A Cleaner Approach Using @power-seo

After manually wiring this up across multiple projects, I got tired of repeating the same boilerplate.

Especially:

Meta tag injection
Route matching
OG image generation
Crawler compatibility
SSR edge cases

Instead of manually replacing placeholders, you define SEO data per route.

Example:

import { createSEO } from "@power-seo/core";

const seo = createSEO({
  routes: {
    "/post/:slug": async ({ slug }) => {
      const post = await getPost(slug);

      return {
        title: post.title,
        description: post.description,
        image: post.image
      };
    }
  }
});

Then mount middleware:

app.use(seo.middleware());

That’s it.

The important thing is not the library itself. The important thing is the architecture:

Generate tags server-side
Return crawler-friendly HTML
Keep metadata tied to routes
Avoid client-only rendering for SEO

The package simply removes repetitive plumbing.

I wrote a deeper breakdown here:

Open Graph React SEO guide

How to Verify Your Open Graph Tags Actually Work

A lot of developers assume tags work because they appear in DevTools.

That’s not enough.

You need to test what crawlers actually see.

Twitter Card Validator

https://cards-dev.twitter.com/validator

LinkedIn Post Inspector

https://www.linkedin.com/post-inspector/

Facebook Sharing Debugger

https://developers.facebook.com/tools/debug/

Paste your URL and verify:

Title
Description
Image
Canonical URL

If something looks wrong, the usual causes are:

Tags are client-rendered
Crawlers cached old HTML
Invalid image dimensions
Missing absolute URLs

Common Open Graph React SEO Mistakes

1. Using React Helmet Alone

react-helmet is useful for browsers.

It is not enough for crawler compatibility unless paired with SSR or prerendering.

2. Forgetting Absolute URLs

This breaks frequently:

<meta property="og:image" content="/image.png" />

Use:

<meta
  property="og:image"
  content="https://mysite.com/image.png"
/>

3. Wrong Image Size

Recommended dimensions:

1200 × 630

Smaller images often render poorly or fail entirely.

4. Not Caching OG Images

Dynamic generation can become expensive quickly.

Cache aggressively:

res.set(
  "Cache-Control",
  "public, max-age=86400"
);

What I Learned

React SPAs often fail social previews because crawlers do not fully execute client-side rendering
Open Graph React SEO works best when meta tags are generated server-side
Dynamic OG images improve click-through rates more than most developers expect
react-helmet helps browsers, but SSR or prerendering fixes crawler visibility
You do not need a full Next.js migration to solve this problem
Libraries like @[power-seo](https://www.npmjs.com/org/power-seo) are useful because they automate repetitive server-side SEO plumbing.

What’s your current React SEO setup?

Are you using SSR, prerendering, middleware injection, or just hoping crawlers execute your app correctly?

I’m curious what approaches people are using in production right now.

React SEO Guide: Making Google Actually See Your React App

Mitu Das — Tue, 12 May 2026 09:17:21 +0000

I once deployed a perfectly working React app, shared the link, waited for traffic, and Google basically ignored it. No indexing. No previews. Nothing. I spent 5 hours digging through Lighthouse reports, meta tags, and server configs before realizing something uncomfortable: React apps do not fail SEO, they are just invisible by default.

If you have ever wondered why your React project does not show up properly on Google or social media, this React SEO Guide will walk you through the exact fixes that actually work in production.

Why React Apps Are Invisible to Search Engines

Most React apps are Single Page Applications (SPAs). That means the browser receives a nearly empty HTML file and builds everything with JavaScript.

The problem is that search engines do not always execute your JavaScript the same way a browser does.

Here is a minimal React app:

// App.jsx
import React from "react";

export default function App() {
  return (
    <div>
      <h1>My Awesome Portfolio</h1>
      <p>Welcome to my site</p>
    </div>
  );
}

When the browser renders it, everything looks fine. But when Google first crawls it, it may only see:

<div id="root"></div>

That is it. No title. No description. No context.

The result:

Pages do not rank properly
Social media previews are broken
Crawlers miss key content

The real issue:

SEO for React is not about content alone, it is about rendering strategy.

Step 1: Add Proper Meta Tags (Baseline Fix)

The first and easiest fix is adding metadata using a tool like react-helmet.

Install it:

npm install react-helmet

Now update your component:

import React from "react";
import { Helmet } from "react-helmet";

export default function App() {
  return (
    <>
      <Helmet>
        <title>My Awesome Portfolio</title>
        <meta name="description" content="Frontend developer portfolio built with React" />
        <meta property="og:title" content="My Awesome Portfolio" />
        <meta property="og:description" content="Check out my React projects and skills" />
        <meta property="og:type" content="website" />
      </Helmet>

      <div>
        <h1>My Awesome Portfolio</h1>
      </div>
    </>
  );
}

What changed?

Now your app provides:

A real page title
A searchable description
Social media preview data for Open Graph

Result:

When crawlers execute JavaScript, they finally see meaningful metadata.

But this still depends on JavaScript execution, which is not always reliable.

Step 2: Server Side Rendering or Pre rendering

If SEO matters even a little, client only rendering is not enough.

You need HTML that already contains content before JavaScript runs.

Option A: SSR with Node and Express

import express from "express";
import React from "react";
import { renderToString } from "react-dom/server";
import App from "./App";

const app = express();

app.get("*", (req, res) => {
  const appHtml = renderToString(<App />);

  const html = `
    <!DOCTYPE html>
    <html>
      <head>
        <title>My SEO Friendly React App</title>
        <meta name="description" content="Server rendered React app" />
      </head>
      <body>
        <div id="root">${appHtml}</div>
        <script src="/bundle.js"></script>
      </body>
    </html>
  `;

  res.send(html);
});

app.listen(3000);

What this fixes:

Google sees full HTML immediately
Faster indexing
Better performance signals

Option B: Static pre rendering

If SSR feels heavy, pre rendering tools generate static HTML during build time.

This is ideal for:

Portfolio sites
Landing pages
Blogs

Step 3: Automating SEO Without Manual Meta Work

In real projects, SEO gets repetitive fast.

You do not want to manually manage:

Page titles
Descriptions
Open Graph tags

This is where tools like @power-seo become useful in a practical way.

Instead of manually defining tags everywhere, you pass structured data once:

npm install @power-seo

Then integrate it:

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

export default function BlogPost({ post }) {
  return (
    <>
      <SEO
        title={post.title}
        description={post.summary}
        image={post.coverImage}
        url={`https://your-site.com/blog/${post.slug}`}
      />

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

Why this helps in real projects:

Instead of thinking:
Did I forget meta tags on this page

You define SEO data once and keep consistency across your app.

It does not replace SSR or architecture decisions, it supports them.

Package reference:
https://www.npmjs.com/package/@power-seo

Practical walkthrough:
https://ccbd.dev/blog/react-seo-guide-boost-your-apps-search-visibility

Result:

Fewer missing SEO tags
Consistent metadata
Less manual repetition across pages

Step 4: Invisible SEO Factors Developers Miss

SEO is not only metadata. React apps often miss structural signals.

1. Semantic HTML

Bad:

<div onClick={handleClick}>Read more</div>

Better:

<button onClick={handleClick}>Read more</button>

Search engines understand semantic elements better.

2. Clean URL structure

Bad:

/page?id=123

Better:

/blog/react-seo-guide

Clean URLs improve indexing and readability.

3. Sitemap generation

Basic sitemap example:

const pages = ["/", "/about", "/blog"];

const sitemap = `
  <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
    ${pages
      .map(
        (page) => `
      <url>
        <loc>https://your-site.com${page}</loc>
      </url>`
      )
      .join("")}
  </urlset>
`;

Submit it in Google Search Console so crawlers understand your site structure.

What I Learned (Key Takeaways)

React SEO is mostly about rendering strategy, not just keywords
Client side rendering alone is not reliable for indexing
SSR or pre rendering significantly improves visibility and performance
Tools like react helmet and @power-seo reduce manual SEO work but do not replace good architecture decisions

A lot of React apps still rely only on client side rendering, even when SEO matters. I am curious how you handle it in your projects. Are you using SSR, pre rendering, or still SPA only setups? What has been your biggest SEO challenge with React so far?

DEV Community: Mitu Das

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

The Manual Approach: A Custom React Hook

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

Using a Library: When Manual Gets Tedious

What I Learned

What's your setup?

Next.js SEO Meta Tags: The Mistakes That Cost Me 3 Weeks of Traffic

Why Next.js Meta Tags Break More Than You'd Expect

App Router: Static and Dynamic Metadata

Static metadata (layout or page level)

Dynamic metadata (for blog posts, product pages, etc.)

Pages Router: Using next/head

One Thing That Helped Me Catch Tag Problems Early

What I Learned (The Hard Way)

SEO Mistakes That Are Silently Killing Your Dev Projects

Mistake #1: Your <head> Is Almost Empty

Mistake #2: Client-Side Rendering Is Invisible to Crawlers (Sometimes)

Mistake #3: You Have No Structured Data

Mistake #4: Your sitemap.xml Is Missing or Stale

What I Actually Learned

What's Your Biggest SEO Headache?

I Built a Free JavaScript SEO Audit Tool After Google Ignored My React App for 3 Months

Why JavaScript Apps Break SEO in Ways Static HTML Doesn't

Auditing Structured Data and Open Graph Tags Programmatically

Automating Multi-Page Audits with a Crawl Script

Going Deeper: When You Need More Than a Script

What I Learned (After Losing 3 Months of Potential Traffic)

What's your biggest JavaScript SEO headache?

React E-commerce App Is Invisible to Google - Here's Why (and the Fix)

Why React E-commerce Apps Fail at SEO (The Actual Reason)

1. Add Product Structured Data (JSON-LD)

2. Dynamic Meta Tags Per Product Page

3. Canonical URLs and Faceted Navigation

4. Automating This Across a Large Catalog

What I Learned

What's Your Biggest E-commerce SEO Headache?

Open Graph React SEO: Why React App Looks Broken on Twitter And How to Fix It

The React SEO Problem Nobody Notices Until Production

The Fastest Fix Is Injecting OG Tags Server Side

Step 1: Create an Express server

Step 2: Add placeholders to index.html

Result

3. Automated Crawl Audits With `power-seo`

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

Pages Router: Using `next/head`

Mistake #1: Your `<head>` Is Almost Empty

Step 2: Add placeholders to `index.html`