Forem: Alamin

My Next.js Sitemap Was Missing Pages for Weeks. I Fixed It by Ditching next-sitemap

Alamin — Wed, 15 Apr 2026 11:36:55 +0000

I spent two weeks wondering why Google Search Console kept showing "Discovered — currently not indexed" for entire sections of my Next.js app. The pages were live. Lighthouse passed. Everything looked fine locally.

Then I found it: every URL inside an App Router route group — like (marketing)/about or (shop)/products/[slug] — was completely absent from my sitemap. Not an error. No warning. Just silently missing from the XML file next-sitemap was generating.

This article is about that bug, why it exists, and the proper fix. I'll also show you a few things about Next.js sitemap generation that most tutorials skip over entirely.

The Problem: next-sitemap and App Router Route Groups

next-sitemap is the most downloaded sitemap package for Next.js. Around 416,000 weekly downloads. It has been the go-to choice for years — and honestly, for a long time it was excellent.

But it was built for the Pages Router. Its architecture is a postbuild script that crawls your built output and writes static XML files into public/. That model predates the App Router entirely.

GitHub issue #700 — open since August 2023 — documents that pages inside route groups like (marketing), (shop), or (auth) don't appear in the generated sitemap. Route groups are a standard App Router pattern. You use them to organize layouts without affecting the URL structure.

The dangerous part isn't that the bug exists. It's that there's no error message. The build succeeds. The sitemap generates. You deploy. And then quietly, over days and weeks, Google doesn't index those pages because they're not in your sitemap.

I only caught it during a routine Google Search Console audit. By then, it had been broken for almost three weeks.

Here's how to check if you're affected:

# After your build, inspect the generated sitemap
cat public/sitemap.xml | grep "(marketing)"
# If your route groups use parentheses, this should return nothing
# But those pages SHOULD be in your sitemap

# Better check: count your sitemap URLs vs your actual pages
cat public/sitemap.xml | grep -c "<loc>"

If the URL count is lower than your actual page count — and you're using route groups — you've likely hit this bug.

Why next-sitemap Can't Easily Fix This

The root issue is architectural. next-sitemap uses fs and path to crawl your built .next/server/pages and .next/server/app directories at build time. Route group folder names include parentheses, and the crawler strips them when constructing URLs (because that's the correct behavior for actual URLs) — but in doing so, it loses track of which files it has actually processed.

This is a hard fix. The logic for resolving route group paths to actual URLs is tightly coupled to how Next.js resolves them internally, and next-sitemap doesn't use Next.js internals directly.

Additionally, next-sitemap's last published version is 4.2.3 from approximately 2022. The project has not had a meaningful update since App Router shipped as stable.

The Fix: App Router Route Handlers

The cleanest solution for App Router projects is to stop using a build-time crawling script entirely and generate the sitemap dynamically via a Route Handler.

You keep full control over which URLs are included. Route group logic is irrelevant because you are building the URL list directly from your database or CMS — not inferring it from the filesystem.

Here's a minimal working example:

// app/sitemap.xml/route.ts
import { NextResponse } from 'next/server';

const hostname = 'https://yoursite.com';

export async function GET() {
  const staticUrls = [
    { loc: '/', priority: 1.0, changefreq: 'daily' },
    { loc: '/about', priority: 0.8, changefreq: 'monthly' },
    { loc: '/blog', priority: 0.9, changefreq: 'weekly' },
  ];

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

  return new Response(xml, {
    headers: { 'Content-Type': 'application/xml' },
  });
}

This works. But you're immediately writing XML escaping, URL validation, and changefreq type safety by hand. For a 5-page site, that's fine. For a product catalog with 10,000 dynamic URLs and image extensions, you want a library.

Adding Dynamic URLs with a Sitemap Library

For larger projects, I switched to @power-seo/sitemap — a newer package from CyberCraft Bangladesh that is built specifically around the Route Handler pattern. Zero Node.js-specific dependencies (so it works on edge runtimes), TypeScript-first, and supports image, video, and news sitemap extensions.

Here's the same product catalog example using it:

// app/sitemap.xml/route.ts
import { generateSitemap, validateSitemapUrl } from '@power-seo/sitemap';
import { db } from '@/lib/db';

export const dynamic = 'force-dynamic';

export async function GET() {
  const products = await db.product.findMany({
    select: { slug: true, updatedAt: true, imageUrl: true, name: true },
  });

  const urls = [
    { loc: '/', changefreq: 'daily' as const, priority: 1.0 },
    { loc: '/products', changefreq: 'daily' as const, priority: 0.9 },
    ...products.map((p) => ({
      loc: `/products/${p.slug}`,
      lastmod: p.updatedAt.toISOString(),
      changefreq: 'weekly' as const,
      priority: 0.8,
      images: [{ loc: p.imageUrl, caption: p.name, title: p.name }],
    })),
  ];

  // Catch bad data before Google does
  const invalid = urls.filter((url) => !validateSitemapUrl(url).valid);
  if (invalid.length > 0) {
    console.warn(`${invalid.length} invalid sitemap URLs detected`);
  }

  const xml = generateSitemap({ hostname: 'https://yoursite.com', urls });

  return new Response(xml, {
    headers: {
      'Content-Type': 'application/xml',
      'Cache-Control': 'public, max-age=3600, stale-while-revalidate=86400',
    },
  });
}

A few things worth noting here:

The image extensions actually matter for Google Images. If you have product photos, adding <image:image> tags to your sitemap entries is how Google Images picks them up alongside regular search results. next-sitemap doesn't support this in additionalPaths. Writing it by hand in raw XML is error-prone.

Runtime data means your sitemap is always fresh. A product added at 2pm appears in the sitemap the next time Google crawls /sitemap.xml — no rebuild required. With next-sitemap, your sitemap is frozen at build time.

validateSitemapUrl() is a safety net. One malformed URL in a large catalog can cause Google to reject the entire sitemap file. Catching bad data before you serve it is worth the two extra lines.

Handling Large Catalogs (50,000+ URLs)

The XML Sitemap spec caps a single file at 50,000 URLs. If you're building a large e-commerce site, a news site, or a marketplace, you'll need a sitemap index pointing to multiple child sitemaps.

@power-seo/sitemap handles this with splitSitemap():

// scripts/generate-sitemaps.ts
import { splitSitemap } from '@power-seo/sitemap';
import { writeFileSync, mkdirSync } from 'fs';

async function main() {
  const allUrls = await fetchAllUrls(); // your 75,000 SitemapURL[]

  const { index, sitemaps } = splitSitemap(
    { hostname: 'https://yoursite.com', urls: allUrls },
    '/sitemaps/chunk-{index}.xml'
  );

  mkdirSync('./public/sitemaps', { recursive: true });
  writeFileSync('./public/sitemap.xml', index);

  sitemaps.forEach(({ filename, xml }) => {
    writeFileSync(`./public${filename}`, xml);
  });

  console.log(`Generated ${sitemaps.length} child sitemaps + sitemap index`);
}

main();

For memory-constrained environments or very large catalogs, the streamSitemap() generator keeps memory usage constant by yielding XML chunks one <url> at a time — around 5x lighter on heap than building the full string in memory.

robots.txt Without next-sitemap

One thing next-sitemap does that @power-seo/sitemap intentionally doesn't: robots.txt generation. If you're migrating, the clean replacement is Next.js's native app/robots.ts convention:

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

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

Eight lines. No extra package. Native Next.js. Done.

What I Actually Learned From This

Silent failures are the most dangerous kind. A build error stops you. A missing warning doesn't. Always verify your sitemap against your actual page list — not just "does the file exist."
Build-time sitemap generation has real limitations. For content that changes frequently (products, blog posts, user profiles), a static sitemap file ages poorly between deployments.
The route group pattern is too important to work around. Route groups are core App Router structure. Choosing a sitemap tool that doesn't handle them means choosing a tool that doesn't work with how modern Next.js is meant to be used.
Image sitemaps are often neglected but easy to add. If you have product images, recipe photos, or editorial images, <image:image> extensions directly impact Google Images traffic. It's two extra fields per URL.

If you want to try the approach above, the source for @power-seo/sitemap is at: Power SEO Repo

Discussion

Is your Next.js sitemap actually showing all your pages — or are you just assuming it is?

If you're on App Router and using next-sitemap, it's worth a quick check: run cat public/sitemap.xml | grep -c "<loc>" after your next build and compare that count to your actual routes. The numbers might surprise you.

Are you using App Router route groups like (marketing) or (shop)? Have you checked if those pages are in your sitemap?

Drop your findings in the comments. I'm especially curious whether anyone has found a working workaround for the next-sitemap route group bug — I looked and couldn't find one that didn't require manually maintaining a URL list anyway (which defeats the purpose of a crawler-based tool).

My JSON-LD schemas were silently broken — until I found @graph

Alamin — Sun, 12 Apr 2026 04:33:00 +0000

I spent 3 hours debugging why Google wasn't showing rich results for my blog. My JSON-LD validated fine. The structured data was in the HTML. Google Search Console just... ignored two of my three schemas entirely. The fix turned out to be a single structural change to how the JSON is written. But the real lesson was understanding why multiple <script type="application/ld+json"> tags silently break — and what @graph actually does differently.

The Problem Nobody Warned Me About

Here's what I had. A Next.js App Router blog, three schemas per post page — Article, BreadcrumbList, and Organization. Standard setup. I validated all three with Google's Rich Results Test and everything passed.

Here's the code, nothing unusual:

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

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{
          __html: JSON.stringify({
            "@context": "https://schema.org",
            "@type": "Article",
            headline: post.title,
            datePublished: post.publishedAt,
            author: { "@type": "Person", name: post.author.name },
          }),
        }}
      />
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{
          __html: JSON.stringify({
            "@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: post.title },
            ],
          }),
        }}
      />
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{
          __html: JSON.stringify({
            "@context": "https://schema.org",
            "@type": "Organization",
            name: "My Blog",
            url: "https://example.com",
          }),
        }}
      />
      <article>{/* content */}</article>
    </>
  );
}

Looks fine. Validates fine. Breaks silently in production.

My Article schema showed up in Search Console. My BreadcrumbList and Organization schemas never appeared at all.

Why This Is Worse Than It Sounds

Google usually parses multiple <script type="application/ld+json"> blocks on a page. But "usually" is doing a lot of work in that sentence.

Google's own structured data documentation says this directly:

"You can place structured data on the same page using multiple scripts, but we recommend placing all of them in a single @graph."

That word — recommend — is Google politely telling you the safer path. In practice, on pages with three or more separate JSON-LD blocks, Google picks up the first schema it finds and sometimes stops there. Crawl budget is finite. Complex pages with many script blocks don't always get fully parsed.

But there's a second problem that's arguably worse: there's no validation anywhere in this flow.

Look at this schema:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "My Post"
}

Spot what's missing? datePublished. image. Both are required fields for Google's Article rich result. This builds cleanly, ships to production, and quietly disqualifies every page that uses it. TypeScript doesn't catch it. Your linter doesn't catch it. You find out three weeks later when Search Console finally re-crawls your pages — if you're even checking.

There's no error, no warning, no 404. The schema just silently fails to qualify.

What `@graph` Actually Does

Instead of three separate <script> tags, @graph combines everything into a single JSON document:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "headline": "My Post",
      "datePublished": "2026-01-15",
      "author": { "@type": "Person", "name": "Jane Doe" }
    },
    {
      "@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 Post" }
      ]
    },
    {
      "@type": "Organization",
      "name": "My Blog",
      "url": "https://example.com"
    }
  ]
}

One <script> tag. Google parses it as a single connected document. The schemas can even cross-reference each other using @id — something impossible across separate script blocks.

After I switched to this format, all three schemas appeared in Search Console within two weeks.

How to Fix It in Next.js App Router

Option 1: Do it manually, no library needed

If you have a small number of page types, this is completely fine. Build the @graph object and render it in a Server Component:

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

  const graph = {
    "@context": "https://schema.org",
    "@graph": [
      {
        "@type": "Article",
        headline: post.title,
        datePublished: post.publishedAt,
        dateModified: post.updatedAt,
        author: { "@type": "Person", name: post.author.name },
        image: {
          "@type": "ImageObject",
          url: post.coverImage,
          width: 1200,
          height: 630,
        },
      },
      {
        "@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: post.title },
        ],
      },
      {
        "@type": "Organization",
        name: "My Blog",
        url: "https://example.com",
      },
    ],
  };

  // Split on "</" and rejoin with "<\/" to block XSS — this is not optional
  const safeJson = JSON.stringify(graph).split("</").join("<\\/");

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

The XSS escaping step matters. If a post title ever contains </script>, an unescaped string inside dangerouslySetInnerHTML lets the browser treat it as a real closing tag and break the page. Splitting on </ and rejoining with <\/ is the correct fix — it's also JSON-safe because \/ is a valid JSON escape for /.

Option 2: Use a typed schema builder

If you're managing schemas across many page types — articles, products, FAQs, events — writing this manually gets repetitive and hard to audit. The bigger risk is that TypeScript won't tell you when a required field is missing. You'll ship incomplete schemas and not know until Search Console catches it.

I landed on Power-SEO schema after trying a few options. It's a newer library — smaller community than next-seo — but it has built-in @graph support and a validateSchema() function that runs in plain Node.js with no React dependency. Here's the same page, rewritten:

npm install @power-seo/schema

// app/blog/[slug]/page.tsx
import {
  article,
  breadcrumbList,
  organization,
  schemaGraph,
  toJsonLdString,
  validateSchema,
} from "@power-seo/schema";

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await fetchPost(params.slug);

  const articleSchema = article({
    headline: post.title,
    datePublished: post.publishedAt,
    dateModified: post.updatedAt,
    author: { name: post.author.name, url: post.author.url },
    image: { url: post.coverImage, width: 1200, height: 630 },
  });

  // Catches missing required fields before the page renders
  const { valid, issues } = validateSchema(articleSchema);
  if (!valid) {
    console.warn("Schema issues:", issues.map((i) => i.message));
  }

  const graph = schemaGraph([
    articleSchema,
    breadcrumbList([
      { name: "Home", url: "https://example.com" },
      { name: "Blog", url: "https://example.com/blog" },
      { name: post.title },
    ]),
    organization({ name: "My Blog", url: "https://example.com" }),
  ]);

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: toJsonLdString(graph) }}
      />
      <article>{/* your content */}</article>
    </>
  );
}

toJsonLdString() handles the XSS escaping internally. TypeScript catches wrong field types at build time. validateSchema() catches missing required fields at runtime — before the page renders, not after Google has already crawled it.

The Part That Actually Changed My Workflow

Because @power-seo/schema is pure TypeScript with zero React dependency, validateSchema() runs in a plain Node.js script. No browser. No render tree. That means you can validate schemas in CI before every deploy:

// scripts/validate-schemas.ts
import { article, faqPage, validateSchema } from "@power-seo/schema";

const schemas = [
  article({
    headline: "How to Brew Coffee",
    datePublished: "2026-01-15",
    author: { name: "Jane Doe" },
  }),
  article({
    headline: "Coffee Grinder Guide",
    // datePublished intentionally missing — caught below
  }),
  faqPage([
    { question: "What grind size for espresso?", answer: "Fine grind." },
  ]),
];

let exitCode = 0;

for (const schema of schemas) {
  const { valid, issues } = validateSchema(schema);
  if (!valid) {
    issues
      .filter((i) => i.severity === "error")
      .forEach((e) => console.error(`✗ [${e.field}] ${e.message}`));
    exitCode = 1;
  }
}

process.exit(exitCode);
// Output: ✗ [datePublished] datePublished is required for Article

Broken schemas don't reach production. You don't find out about missing datePublished fields two weeks after deploy when Search Console finally gets around to re-crawling your pages.

If you're also weighing this against next-seo — bundle size, tree-shaking, App Router vs Pages Router differences — I wrote up a full Power-SEO Schema vs Next-SEO comparison after going through the migration myself.

What I Learned

Multiple <script type="application/ld+json"> tags work most of the time — @graph is what Google actually recommends for multi-schema pages. Don't build on "usually works" for something you can only verify in Search Console weeks later.

Passing Google's Rich Results Test is not the same as Google using your schema. The test validates JSON-LD structure. It has no idea whether Googlebot parsed all your script blocks during an actual crawl.

Missing required fields fail silently. No error, no warning, no build failure. The schema just doesn't qualify for rich results, and you have no idea until you check Search Console — if you're even checking. Validation at build time is the only reliable safety net.

You don't need a library for @graph. Writing it manually works perfectly well. A typed builder just removes the chance of shipping a missing datePublished on page 47 of your blog and never noticing.

If you want to explore the typed approach, the repo is here: Github Power-SEO

Have you ever validated your JSON-LD and had Google still ignore it? Are you using @graph already — or still separate script tags per page?

And the more uncomfortable question: how long did your broken schema sit in production before you caught it? Was it you, or did Google Search Console tell you first?

Your React App's SEO Is Broken and react-helmet Can't Fix It Anymore

Alamin — Tue, 07 Apr 2026 05:17:39 +0000

I spent 3 hours debugging why Google couldn't see my React app's meta tags. The fix was 4 lines of code. But the real lesson wasn't the fix, it was understanding why the library I'd trusted for years quietly stopped working with modern React. If you're still using react-helmet in a React 18 or 19 project, this is worth 10 minutes of your time.

The Problem Nobody Warned Me About

Here's what happened. I had a Vite + React 18 project. I installed react-helmet like I always do, wrote my tags, and deployed. Everything looked fine locally.

Then I ran npx lighthouse against the live URL. Missing meta description. Missing Open Graph image. Google Search Console confirmed it, Googlebot was crawling blank

tags.

The culprit? React-helmet was built before React 18's concurrent rendering model existed.

Its internal DOM manipulation layer races against React's reconciler in SSR and concurrent mode, causing hydration mismatches. The tags render on the client after the crawler has already read the page and moved on.
Here's the code I had — totally standard, nothing unusual:

import { Helmet } from 'react-helmet';

export function ProductPage({ product }) {
  return (
    <>
      <Helmet>
        <title>{product.name} | My Store</title>
        <meta name="description" content={product.summary} />
        <meta name="robots" content="index, follow, max-image-preview:large" />
        <meta property="og:image" content={product.image} />
      </Helmet>
      <main>...</main>
    </>
  );
}

Looks fine. Ships fine. Breaks silently in production.
The react-helmet repo hasn't had a meaningful commit since 2022. The maintainers moved on. React didn't wait.

Why This Is Worse Than It Sounds

The hydration issue is one problem. But there's a second one that's arguably more dangerous: react-helmet accepts raw strings for everything.
Look at this robots tag:

<meta name="robots" content="index, follow, max-image-preveiw:large" />

Spot the typo? preveiw instead of preview — two characters transposed. TypeScript doesn't catch it. Your linter doesn't catch it. It builds clean, ships to production, and quietly tanks your image preview rich results. I've seen this exact typo sitting in production codebases for months.
There's no autocomplete, no type checking, no enum, just a raw string that Google either understands or silently ignores.
And there's a third problem: no app-level defaults. Every page in your React app has to manage its full tag set from scratch. Forget one og:image on one route and you have an inconsistency that only shows up in a Search Console audit three months later.

What React 19 Actually Does to Head Management

React 19 changed something fundamental: <title>, <meta>, and <link> elements now hoist to <head> natively without any third-party DOM manipulation. This is a big deal.
React 19 docs on this:

React will now automatically hoist title, meta, and link tags to the document head when they're rendered anywhere in the tree.

React-helmet's whole value proposition was doing this manually via its own DOM layer. In React 19, that layer now conflicts with what React is doing natively, resulting in duplicate tags, race conditions, and unpredictable render order.
If you want to see this in action, spin up a React 19 + Vite project, install react-helmet, enable SSR, and watch the hydration warnings stack up in the console.

How I Fixed It (And What I Replaced It With)

After debugging, I tried a few options. next-seo is excellent, but it's locked to Next.js, and this was a Vite project. I needed something that:

Works with Vite and React 18/19
Has TypeScript-first APIs (no raw strings)
Supports structured data and Open Graph without boilerplate

I landed on Power-SEO React, a newer library from CyberCraft Bangladesh that's built around React 19's native head hoisting. Here's the same product page, rewritten:

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

export function ProductPage({ product }) {
  return (
    <>
      <SEO
        title={product.name}
        description={product.summary}
        canonical={`https://mystore.com/products/${product.slug}`}
        openGraph={{
          type: 'website',
          images: [{ url: product.image, width: 1200, height: 630, alt: product.name }],
        }}
        twitter={{ cardType: 'summary_large_image' }}
      />
      <Robots index={true} follow={true} maxImagePreview="large" maxSnippet={160} />
      <main>...</main>
    </>
  );
}

maxImagePreview is typed as 'none' | 'standard' | 'large'. TypeScript literally cannot compile a typo. That one change eliminates the entire category of silent robots-string bugs.
But the real power is at the app level. The app-level setup with DefaultSEO is where it gets genuinely useful:

// _app.tsx — set defaults once, all pages inherit them
import { DefaultSEO } from '@power-seo/react';

export function App({ children }) {
  return (
    <DefaultSEO
      titleTemplate="%s | My Store"
      defaultTitle="My Store"
      description="Premium products for modern teams."
      openGraph={{
        type: 'website',
        siteName: 'My Store',
        images: [{ url: 'https://mystore.com/og-default.jpg', width: 1200, height: 630 }],
      }}
      twitter={{ site: '@mystore', cardType: 'summary_large_image' }}
    >
      {children}
    </DefaultSEO>
  );
}

Now every page inherits the default OG image, site name, and Twitter card. Per-page components only override what's different. If you forget an image on a product page, it falls back to the default, no blank OG tags.
One more thing that saved me on a multi-language project: built-in hreflang support.

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

<Hreflang
  alternates={[
    { hrefLang: 'en', href: 'https://mystore.com/en/products/shoes' },
    { hrefLang: 'fr', href: 'https://mystore.com/fr/products/shoes' },
    { hrefLang: 'de', href: 'https://mystore.com/de/products/shoes' },
  ]}
  xDefault="https://mystore.com/en/products/shoes"
/>

With react-helmet, I was writing 4 raw tags per page per locale. Across 200 product pages × 3 locales, that's 600+ places for one URL typo to create an hreflang conflict Google silently ignores.

What I Learned

React-helmet is not broken by itself, it's broken by the ecosystem moving around it. React 18 concurrent mode and React 19 native head hoisting changed the rules. React-helmet wasn't updated to match.

Raw string props in SEO libraries are a liability, not a convenience. The typo you can't see is the bug you won't find until it's already costing you organic traffic.

App-level SEO defaults are underrated. The pattern of setting global defaults once and overriding per page scales massively better than every page managing its own complete tag set.

Library maintenance matters for infrastructure dependencies. SEO libraries touch every page of your app. A library that hasn't tracked React's major versions is technical debt waiting to surface.

If you want to explore this approach yourself, the source is here: GitHub Power-SEO Repo

For the full comparison — feature table, migration guide, and more real-world scenarios — read the complete article: Power-SEO React vs React-Helmet

Next.js SEO Library Comparison 2026: Power-SEO vs Next-SEO With Real Code

Alamin — Sun, 05 Apr 2026 11:34:35 +0000

We deployed a Next.js app last year. Everything looked great locally. Then we opened Google Search Console two weeks later and found that half our pages had no meta descriptions, the Open Graph image was missing on every product route, and one staging environment had somehow gotten indexed.

The culprit wasn't our code logic. It was a scattered SEO setup — no consistent pattern, no defaults, and a raw robot string with a typo that had been silently doing nothing for weeks.

In this article, I'll walk through a real Next.js SEO library comparison for 2026: what the options actually look like in code, where each one fits, and how to pick the right tool before your project scales past the point where switching becomes painful.

Note: Power-SEO is built by our team at CyberCraft Bangladesh. This comparison reflects our hands-on experience with both libraries.

The Two Main Players in 2026

If you're building a Next.js app and need SEO sorted, you'll quickly land on two names: Next-SEO and Power-SEO.
Next-SEO has been around for years. It's a React component library that wraps metadata and structured data into simple JSX. You add to a page, pass your props, and the tags appear in

. That's essentially the whole API.
Power-SEO is newer. It's a modular ecosystem of 17 TypeScript-first packages - you install only what you need. @power-seo/meta for metadata, @power-seo/schema for JSON-LD, @power-seo/redirects for redirect management, and so on.
The honest summary: Next-SEO is simpler. Power-SEO is more complete. Let's see what that looks like in actual code.

Setting Up Metadata: Both Approaches Side by Side

Suppose you're building a blog. Each post needs a title, description, canonical URL, Open Graph tags, and an Article JSON-LD schema.

With Next-SEO:

npm install next-seo


import { NextSeo, ArticleJsonLd } from "next-seo"

export default function BlogPost({ title, description, slug }) {
  const url = `https://example.com/blog/${slug}`

  return (
    <>
      <NextSeo
        title={title}
        description={description}
        canonical={url}
        openGraph={{
          url,
          title,
          description,
          type: "article",
          images: [{ url: "https://example.com/og.jpg", width: 1200, height: 630, alt: title }]
        }}
      />
      <ArticleJsonLd
        url={url}
        title={title}
        images={["https://example.com/og.jpg"]}
        datePublished="2026-01-10"
        authorName="Jane Developer"
        publisherName="My Blog"
      />
      <article>Content here</article>
    </>
  )
}

This works. It's readable. Any React developer can understand it in 30 seconds.

With Power-SEO (App Router pattern):

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

import { createMetadata } from "@power-seo/meta"
import { article, toJsonLdString } from "@power-seo/schema"

export function generateMetadata({ title, description, slug }) {
  return createMetadata({
    title,
    description,
    canonical: `https://example.com/blog/${slug}`,
    openGraph: {
      type: "article",
      images: [{ url: "https://example.com/og.jpg", width: 1200, height: 630 }]
    },
    robots: { index: true, follow: true }
  })
}

export default function BlogPost() {
  const schema = article({
    headline: "My Blog Post",
    datePublished: "2026-01-10",
    author: { name: "Jane Developer" }
  })

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: toJsonLdString(schema) }}
      />
      <article>Content here</article>
    </>
  )
}

The key difference: createMetadata() integrates directly with Next.js App Router's generateMetadata() export. The SEO logic runs on the server, not inside a client component. For App Router projects, this is the architecturally cleaner pattern.

For a deeper breakdown of every feature including real-world scenarios, the full comparison is on our blog: Power-SEO vs Next-SEO

What We Learned: Key Takeaways

For App Router projects, createMetadata() from @power-seo/meta fits the architecture better than JSX components - SEO logic belongs on the server side.
For simple sites, Next-SEO's component API is genuinely easier and faster. Don't over-engineer a five-page marketing site.
For content-heavy platforms, schemaGraph() keeps structured data organized as schema requirements grow across page types.
For large migrations, having a testable redirect engine in TypeScript is worth the extra dependency - one untested redirect pattern across thousands of URLs is a real SEO risk.

Both libraries are MIT licensed and actively maintained. Next-SEO has a larger community right now. Power-SEO has a broader feature set.

If you want to explore the modular approach, the packages are on npm: @power-seo/meta and @power-seo/schema.

Forem: Alamin

My Next.js Sitemap Was Missing Pages for Weeks. I Fixed It by Ditching next-sitemap

The Problem: next-sitemap and App Router Route Groups

Why next-sitemap Can't Easily Fix This

The Fix: App Router Route Handlers

Adding Dynamic URLs with a Sitemap Library

Handling Large Catalogs (50,000+ URLs)

robots.txt Without next-sitemap

What I Actually Learned From This

Discussion

My JSON-LD schemas were silently broken — until I found @graph

The Problem Nobody Warned Me About

Why This Is Worse Than It Sounds

What @graph Actually Does

How to Fix It in Next.js App Router

Option 1: Do it manually, no library needed

Option 2: Use a typed schema builder

The Part That Actually Changed My Workflow

What I Learned

Your React App's SEO Is Broken and react-helmet Can't Fix It Anymore

The Problem Nobody Warned Me About

Why This Is Worse Than It Sounds

What React 19 Actually Does to Head Management

How I Fixed It (And What I Replaced It With)

What I Learned

Next.js SEO Library Comparison 2026: Power-SEO vs Next-SEO With Real Code

The Two Main Players in 2026

Setting Up Metadata: Both Approaches Side by Side

With Next-SEO:

With Power-SEO (App Router pattern):

What We Learned: Key Takeaways

What `@graph` Actually Does