DEV Community: Alamin

Next SEO vs Power SEO Audit: A 2026 Guide for TypeScript Developers

Alamin — Mon, 20 Apr 2026 06:47:57 +0000

Last year I broke SEO on three product pages and didn't find out for four days.

I'd done a layout refactor on a Thursday — nothing dramatic, just cleaning up some shared components. The canonical prop got dropped somewhere in the diff. Meta descriptions were quietly truncating. Nobody caught it in review because, honestly, who checks SEO tags in a layout PR? The TypeScript compiler didn't complain. The build passed. The tests went green.

Monday morning, Search Console. Rankings sliding. I spent the next two hours figuring out what went wrong, and the whole time I kept thinking: why don't we have a check for this in CI?

That question led me down a rabbit hole comparing Next SEO vs Power SEO Audit — and I want to share what I found, because I think a lot of teams are in the same spot I was.

Next SEO writes your meta tags and JSON-LD. Power SEO Audit scores and validates them in CI so broken SEO never reaches Google. They solve different problems. Running both is the setup I now use on every project.

The Mental Model I Was Missing

For a long time, I thought of SEO tooling as one thing: you install a library, you configure your tags, done. Next SEO fit perfectly into that model. Drop in the component, pass your props, move on.

But after that Thursday incident, I started thinking about it differently. There are actually two completely separate jobs:

Writing the tags — putting the right meta tags, canonical links, and JSON-LD into the HTML
Verifying the tags are correct — checking that what you wrote actually follows SEO best practices before Google sees it

Next SEO is genuinely excellent at job one. It does nothing at all for job two. And I'd spent two years treating it like it covered both.

The analogy that clicked for me: Next SEO is like writing code. Power SEO Audit is like running tests on that code. Nobody ships without tests. But almost everybody ships without SEO validation.

How I Actually Use Next SEO (And Where It Gets You Stuck)

I've used Next SEO on probably a dozen projects at this point. Pages Router, mostly. The API just makes sense — you think in React components, and <NextSeo /> fits that mental model perfectly.

One thing worth knowing upfront: Next SEO is a React component, which means in the App Router it needs 'use client' or it won't work the way you expect. For App Router projects I now reach for generateMetadata() directly — but for Pages Router, Next SEO is still my first choice.

Here's the setup I use on a product page. Nothing fancy, just the pieces that actually matter:

// pages/products/[slug].tsx
import { NextSeo, ProductJsonLd } from 'next-seo';

type Props = {
  title: string;
  description: string;
  slug: string;
};

export default function ProductPage({ title, description, slug }: Props) {
  const url = `https://example.com/products/${slug}`;

  return (
    <>
      <NextSeo
        title={title}
        description={description}
        canonical={url}
        openGraph={{
          url,
          title,
          description,
          type: 'website',
          images: [
            {
              url: 'https://example.com/images/og.jpg',
              width: 1200,
              height: 630,
              alt: title,
            },
          ],
        }}
      />
      <ProductJsonLd
        productName={title}
        description={description}
        images={['https://example.com/images/og.jpg']}
        brand={{ name: 'Example Brand' }}
        offers={[
          {
            price: '79.99',
            priceCurrency: 'USD',
            availability: 'https://schema.org/InStock',
            url,
            seller: { name: 'Example Store' },
          },
        ]}
      />
      <main>{/* product content */}</main>
    </>
  );
}

This works. I like it. It's readable and it ships fast.

Here's the part that used to keep me up at night though: Next SEO renders exactly what you give it, no questions asked. Pass it an empty string for metaDescription? It renders an empty meta description. Forget the canonical prop entirely after a refactor? It quietly renders without one. No warning. No error. Nothing in the console.

That's not a bug in Next SEO — it's just how implementation-only tools work. But it means every SEO mistake you make is silent until Google's crawler finds it for you. And by then, you've already lost rankings.

The Tool That Fixed the Blind Spot: Power SEO Audit

After that Thursday incident, I started looking for something that could catch these issues in CI — before a PR merges, not after Google re-crawls.

I found @power-seo/audit. It's a TypeScript-first audit engine that takes structured page data, runs it through a rule set, and gives back a 0–100 score with every issue tagged by severity. No network calls, no crawler, fully synchronous. Runs anywhere Node.js runs.

Install it alongside tsx so you can run TypeScript scripts directly in CI:

npm i @power-seo/audit
npm i -D tsx

The first time I ran it on a page, I immediately understood what I'd been missing. Here's the basic usage:

// scripts/audit-page.ts
import { auditPage } from '@power-seo/audit';
import type { PageAuditInput, PageAuditResult } from '@power-seo/audit';

const input: PageAuditInput = {
  url: 'https://example.com/products/wireless-headphones',
  title: 'Best Wireless Headphones 2026 — Free Shipping | Example',
  metaDescription:
    'Shop noise-cancelling headphones with free shipping over $50. Trusted by 50,000+ customers.',
  canonical: 'https://example.com/products/wireless-headphones',
  robots: 'index, follow',
  openGraph: {
    title: 'Best Wireless Headphones 2026',
    description: 'Shop with free shipping and easy returns.',
    image: 'https://example.com/images/headphones-og.jpg',
  },
  content: '<h1>Best Wireless Headphones</h1><p>Our top-rated noise-cancelling headphones...</p>',
  headings: ['h1:Best Wireless Headphones', 'h2:Key Features', 'h2:Customer Reviews'],
  images: [
    { src: '/images/headphones.webp', alt: 'Wireless headphones product photo' },
    { src: '/images/headphones-side.jpg', alt: '' }, // intentionally missing — watch what happens
  ],
  focusKeyphrase: 'wireless headphones',
  wordCount: 820,
};

const result: PageAuditResult = auditPage(input);

console.log(`Score: ${result.score}/100`);
// Score: 76/100

console.log(result.categories);
// {
//   meta:        { score: 90, passed: 9, warnings: 1, errors: 0 },
//   content:     { score: 78, passed: 6, warnings: 2, errors: 0 },
//   structure:   { score: 65, passed: 5, warnings: 1, errors: 1 }, // ← alt text caught
//   performance: { score: 80, passed: 7, warnings: 1, errors: 0 },
// }

result.recommendations.forEach((rec) => console.log('→', rec));
// → Add alt text to all images (1 image missing)
// → Move focus keyphrase into the first paragraph

That missing alt text? Flagged immediately as an error. Not a quiet render, not a silent omission — an actual error, with a severity level and a human-readable recommendation.

That output made me realize how much I'd been flying blind.

The CI Gate That Actually Changed How My Team Ships

Okay, this is the part I'm most excited to share — because it's the thing that directly solved the Thursday problem.

auditSite() takes an array of page inputs and returns an aggregated score plus per-page results. I run this on every PR. If the site score drops below 75 or any page has a critical error, the deploy gets blocked. Full stop.

Here's the script:

// scripts/seo-gate.ts
import { auditSite } from '@power-seo/audit';
import type { PageAuditInput } from '@power-seo/audit';

// I pull this data from our CMS at build time — MDX frontmatter, Contentful, whatever you use
const pages: PageAuditInput[] = [
  {
    url: 'https://example.com/products/headphones',
    title: 'Best Wireless Headphones 2026 — Free Shipping | Example Store',
    metaDescription: 'Shop noise-cancelling headphones with free shipping over $50.',
    // canonical accidentally dropped during refactor — this gets caught now
    robots: 'index, follow',
    wordCount: 820,
  },
  {
    url: 'https://example.com/products/speakers',
    // 82-character title — over the 60-char guideline, fires a warning
    title: 'Bluetooth Speakers For Home Studio Use — Best Picks For Audio Engineers In 2026',
    metaDescription: 'Find the best Bluetooth speakers for studio and home use.',
    canonical: 'https://example.com/products/speakers',
    robots: 'index, follow',
    wordCount: 740,
  },
];

const report = auditSite({ pages });
const SCORE_THRESHOLD = 75;

const totalErrors = report.pageResults
  .flatMap((p) => p.rules.filter((r) => r.severity === 'error'))
  .length;

if (report.score < SCORE_THRESHOLD || totalErrors > 0) {
  console.error(`\n[FAIL] SEO audit failed — deploy blocked`);
  console.error(`   Site score : ${report.score}/100 (minimum: ${SCORE_THRESHOLD})`);
  console.error(`   Errors     : ${totalErrors}`);
  report.topIssues.forEach((i) =>
    console.error(`   → [${i.severity}] ${i.title}`)
  );
  process.exit(1);
}

console.log(`\n[PASS] SEO audit passed — score: ${report.score}/100`);

And the GitHub Actions workflow — make sure tsx is in your devDependencies so npm ci picks it up:

# .github/workflows/seo-check.yml
name: SEO Quality Gate
on: [pull_request]
jobs:
  seo-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npx tsx scripts/seo-gate.ts

The first time this ran on our repo and blocked a PR, a teammate messaged me: "Why is my PR failing?" I explained what it caught. His response was something like: "Oh. Yeah that would've been bad."

That's the moment I knew this was the right call.

So Which One Should You Use?

Honestly, this isn't really an either/or question — and I think framing it that way is where most comparisons go wrong.

If you're on the Pages Router and want metadata working in 15 minutes: Next SEO. It's mature, the community is enormous, and the component API just makes sense. I still use it.

If you're on the App Router: skip Next SEO and use generateMetadata(). It's the native approach, it's server-side by default, and it keeps SEO out of your client bundles.

If you want to stop discovering SEO regressions in Search Console: add @power-seo/audit to your CI pipeline regardless of which implementation approach you use. It takes maybe an hour to set up and catches the kind of silent mistakes that cost you rankings.

My personal setup right now: Next SEO for Pages Router projects, generateMetadata() for App Router, and @power-seo/audit running in GitHub Actions on both. One layer writes the tags. The other layer makes sure those tags are actually correct before anyone else sees them.

What I'd Tell Myself Before That Thursday

Implementation is not the same as validation. I spent two years thinking Next SEO covered both. It covers one, very well.
TypeScript won't save you here. Your types can be perfect and your SEO can still be silently broken. Types check shape. Audit tools check correctness.
Silent failures are the worst kind. A tool that renders what you pass without checking it feels convenient until it isn't. You want something in your pipeline that actually pushes back.
CI is the right place for this check. Not a manual audit every quarter. Not a Lighthouse run when you remember. A gate that runs on every PR and blocks mistakes before they ship.

I work on Next.js applications at CyberCraft Bangladesh. We've been burned by silent SEO regressions enough times that we built tooling to prevent them — the full open source is here if you want to dig in: Power SEO

Manual SEO review or automated CI gate — what's your team actually doing? I'm genuinely curious. Are you running Lighthouse? A third-party crawler? Something home-built? Or honestly just hoping nothing breaks? No judgment — that was me eight months ago. Drop it in the comments.

Power SEO Meta vs Next SEO: Which SEO Library is Better for Modern Next.js App Router?

Alamin — Thu, 16 Apr 2026 09:06:05 +0000

Disclosure: Power SEO Meta is built by our team at CyberCraft Bangladesh. This comparison reflects our hands-on experience with both libraries — we've tried to be fair, but you should know where we're coming from.

Three weeks after deploying a 60-page product catalog, a client's marketing team messaged me: "Why are our product images not showing when we share links on LinkedIn?"

I opened Google Search Console. Twenty-three out of sixty product pages had max-image-preview missing from their robots directives. Six draft pages were indexed when they should have been noindex. Zero build errors. Zero runtime warnings. Everything looked perfect in the code.

That was the moment I stopped trusting raw metadata strings and started thinking seriously about how App Router changed the SEO game — and which tools have actually caught up.

Why Next.js App Router broke the old metadata approach

Before Next.js 13's App Router, the standard move was <NextSeo> — drop it into your component, pass props, done. It works beautifully on the Pages Router. Genuinely great DX.

But <NextSeo> is a React component. And React components can't run inside React Server Components.

The only way to use it on App Router is to add 'use client' to your page — which ships unnecessary JavaScript to the browser for something that should be pure server logic. Or you skip it entirely and write raw Metadata objects by hand.

That's the architectural mismatch. App Router introduced generateMetadata() — a server function that returns a Metadata object at request time, with zero client JS. next-seo has no equivalent.

So if you're on App Router and typing import { NextSeo } from 'next-seo', you're either working around the framework or ignoring it entirely.

The metadata drift problem (and how to fix it)

Here's the scenario I see constantly: a product catalog with 50+ pages, each needing its own title, description, canonical URL, and Open Graph image. Without a shared utility, the robots logic drifts. One page has max-image-preview:large, another doesn't, a third has a missing canonical.

This is how I structure it now using @power-seo/meta:

// lib/seo/product-metadata.ts
import { createMetadata } from '@power-seo/meta';
import type { Metadata } from 'next';

interface Product {
  name: string;
  description: string;
  slug: string;
  imageUrl: string;
  inStock: boolean;
}

// One function = one source of truth for all 50 product pages.
// Change robots logic here → every page updates immediately.
export function buildProductMetadata(product: Product): Metadata {
  return createMetadata({
    title: `${product.name} | Shop`,
    description: product.description.slice(0, 160),
    canonical: `https://shop.example.com/products/${product.slug}`,
    openGraph: {
      type: 'website',
      title: `${product.name} | Shop`,
      description: product.description.slice(0, 160),
      images: [{ url: product.imageUrl, width: 1200, height: 630, alt: product.name }],
    },
    robots: {
      index: product.inStock,   // out-of-stock pages become noindex automatically
      follow: true,
      maxImagePreview: 'large', // typed union: 'none' | 'standard' | 'large'
    },
  });
}

// app/products/[slug]/page.tsx
import { createMetadata } from '@power-seo/meta';
import type { Metadata } from 'next';
import { getProduct } from '@/lib/products';
import { buildProductMetadata } from '@/lib/seo/product-metadata';

export async function generateMetadata(
  { params }: { params: Promise }
): Promise {
  const { slug } = await params;
  const product = await getProduct(slug);
  return buildProductMetadata(product); // 1 line per page file
}

export default function ProductPage() {
  return {/* product content */};
}

One shared utility. One line per page file. Updating robots logic across all 50 product pages means editing one function. I've shipped this pattern on three client projects and the metadata drift issues haven't come back.

Compare this to the next-seo equivalent on App Router — there isn't one. Each page writes its own Metadata object from scratch: 20+ repeated lines with openGraph.title, openGraph.description, and the full robots object rebuilt every time. That's where the drift comes from.

The silent robots directive bug TypeScript can catch

Here's the bug from the client situation I described above. This is a real robots string I found in production:

// next-seo approach on Pages Router
additionalMetaTags={[{
  name: 'robots',
  // TypeScript cannot validate this string.
  // A typo here is a silent SEO failure.
  content: 'index, follow, max-image-preveiw:large, max-snippet:160',
  //                              ^^^^^^^^ "preveiw" — two letters transposed
}]}

Spot it? preveiw instead of preview. The build passes. The page renders. Google silently ignores the directive. You find out three weeks later in Search Console.

There's a second issue too: next-seo's noindex prop emits <meta name="robots" content="noindex">. Then the additionalMetaTags robots entry emits another <meta name="robots"> tag. Google's behavior with duplicate robots tags is not guaranteed. I've seen this cause real indexing inconsistencies on two separate client projects.

Here's the typed approach:

// app/products/[slug]/page.tsx
import { createMetadata } from '@power-seo/meta';
import type { Metadata } from 'next';
import { getProduct } from '@/lib/products';

export async function generateMetadata(
  { params }: { params: Promise }
): Promise {
  const { slug } = await params;
  const product = await getProduct(slug);

  return createMetadata({
    title: product.title,
    description: product.description,
    canonical: `https://example.com/products/${slug}`,
    robots: {
      index: !product.isDraft,              // boolean, not a string
      follow: true,
      maxImagePreview: 'large',             // TypeScript error if you write 'Large'
      maxSnippet: 160,
      unavailableAfter: product.expiresAt,  // auto-serialised to unavailable_after
    },
  });
}

Two specific things worth calling out:

If you write maxImagePreview: 'Large' (capital L), TypeScript catches it at compile time. It never reaches production.

unavailableAfter is automatically serialised to the correct unavailable_after snake_case format. Build that string manually and a missing underscore silently makes Google ignore the directive entirely.

One gotcha that catches everyone during migration

If you're switching from next-seo to @power-seo/meta, there's one thing that will catch you:

Open Graph title and description do not auto-fallback.

In next-seo, openGraph inherits title and description from top-level props automatically. In @power-seo/meta, you must set openGraph.title and openGraph.description explicitly. Miss this and your OG tags will be empty. It's the most common mistake I've seen in migration.

// Wrong — OG tags will be empty
return createMetadata({
  title: post.title,
  description: post.excerpt,
  openGraph: { type: 'article' }, // missing title and description
});

// Correct — set them explicitly
return createMetadata({
  title: post.title,
  description: post.excerpt,
  openGraph: {
    type: 'article',
    title: post.title,          // required — no auto-fallback
    description: post.excerpt,  // required — no auto-fallback
  },
});

What I learned

App Router and client components are fundamentally mismatched for metadata. A server function returning a Metadata object works with the framework. A component that injects tags at runtime works around it.
Raw string props in SEO libraries are a liability. The typo you can't see is the bug you won't find until it's in Search Console three weeks later.
Metadata drift is a consistency problem that grows slowly and gets noticed late. Shared utility functions that return metadata are the fix — one place to update, zero pages to hunt down.
Community size matters. next-seo's 7,500+ stars and 800K weekly downloads mean your problem has probably been solved somewhere. @power-seo/meta doesn't have that yet. For Pages Router projects, that community advantage is real and worth respecting.

If you want to explore the typed approach, the Open source repo is here: Power SEO

FAQ

Can I use next-seo on Next.js App Router?
You can, but only by marking your page 'use client' — which ships JavaScript to the browser for something that should be pure server logic. For App Router, generateMetadata() with a typed utility is the correct approach.

What is generateMetadata() in Next.js?
It's a server function introduced in Next.js 13 App Router that returns a Metadata object at request time. It runs on the server only, adds zero client JavaScript, and is the recommended way to handle dynamic metadata in App Router projects.

Why do duplicate robots meta tags cause SEO problems?
When two <meta name="robots"> tags appear on the same page, Google's behavior is not guaranteed. It may honor one, the other, or neither. The noindex + additionalMetaTags pattern in next-seo can produce this conflict on Pages Router.

Is @power-seo/meta production-ready?
The library is small (~4.2 KB) and focused on a narrow problem. The GitHub star count (~180 as of April 2026) is low compared to next-seo, which means less community documentation. For Pages Router projects, next-seo remains the safer choice. For App Router projects, the architectural fit is better.

How do I handle JSON-LD schema with @power-seo/meta?
JSON-LD is handled by a separate package: @power-seo/schema. It's a deliberate split — metadata and schema are different concerns. next-seo bundles both together.

Still deciding?

The short version: if you're on Pages Router and have no migration planned, next-seo is still excellent — use it. If you're on App Router and writing 'use client' just to get meta tags working, that's the sign to reconsider.

What's your current setup? Are you on App Router using generateMetadata(), or still on Pages Router? And if you've hit the duplicate robots tag issue I described — curious whether you caught it before or after it showed up in Search Console. Drop a comment below.

Power SEO Sitemap vs Next Sitemap: Best Next.js Sitemap Generator Comparison (2026)

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

Disclosure: Power SEO Sitemap is built by our team at CyberCraft Bangladesh. This article reflects our hands-on experience — where next-sitemap is the better choice, I've said so directly.

I spent two weeks staring at "Discovered — currently not indexed" in Google Search Console. The pages were live. Lighthouse passed. The sitemap file existed and looked fine when I opened it in the browser.

Then I actually counted the URLs.

My app had 47 routes. The sitemap had 31. Sixteen pages had completely vanished — no error, no build warning, nothing. Just gone.

Every missing page was inside an App Router route group.

The bug: next-sitemap and App Router route groups

next-sitemap is the most downloaded Next.js sitemap package — around 416,000 weekly downloads. It's been the standard for years, and for Pages Router projects it still works well.

But its architecture is a postbuild script that crawls your built .next/ output and writes static XML files into public/. That model was designed before App Router existed.

GitHub issue #700, open since August 2023, documents the problem: 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 parentheses to organize layouts without affecting the actual URL.

The crawler sees the folder name with parentheses, strips them to construct the URL (correct behavior), but loses track of the file in the process. End result: those pages silently disappear from your sitemap.

Here's a quick check to see if you're affected:

# Count sitemap URLs vs your actual routes
cat public/sitemap.xml | grep -c ""

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

No error. No warning. You find out weeks later in Search Console.

Why it's hard to fix

The root issue is architectural. next-sitemap uses Node.js fs and path APIs to crawl your built output at build time. It doesn't use Next.js internals to resolve routes — it infers them from the filesystem. Route group resolution is tightly coupled to how Next.js handles it internally, and next-sitemap doesn't have access to that.

The last published version of next-sitemap is 4.2.3 from approximately 2022. App Router shipped as stable in Next.js 13. That gap explains the bug.

The fix: generate the sitemap in a Route Handler

The cleanest solution is to stop using a build-time crawler entirely. Instead, generate the sitemap dynamically via a Next.js Route Handler and build your URL list directly from your database or CMS.

Route group folder names become completely irrelevant because you're never inferring URLs from the filesystem. You're constructing them explicitly.

Here's a minimal version:

// app/sitemap.xml/route.ts
export async function GET() {
  const hostname = 'https://yoursite.com';

  const xml = `


    ${hostname}/
    daily
    1.0


    ${hostname}/about
    monthly
    0.8

`;

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

This works for small static sites. For larger projects — dynamic routes, product catalogs, image extensions — you'll want a library to handle XML escaping, URL validation, and type safety.

Adding dynamic URLs and image sitemaps

For a product catalog, I switched to @power-seo/sitemap. Zero Node.js-specific dependencies (so it runs on edge runtimes), TypeScript-first, and supports image, video, and news sitemap extensions.

// 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 }],
    })),
  ];

  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:

The image extensions matter. Adding <image:image> tags is how Google Images picks up your product photos alongside regular search results. next-sitemap doesn't support this in additionalPaths.

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

validateSitemapUrl() catches bad data before you serve it. One malformed URL can cause Google to reject the entire file.

Handling large catalogs

The sitemap spec caps a single file at 50,000 URLs. For larger sites, splitSitemap() handles chunking and index generation automatically:

import { splitSitemap } from '@power-seo/sitemap';
import { writeFileSync, mkdirSync } from 'fs';

async function main() {
  const allUrls = await fetchAllUrls(); // your full URL list

  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);
  });
}

main();

For memory-constrained environments, streamSitemap() yields XML chunks one <url> at a time instead of building the full string in memory. On a 50,000-URL catalog, memory stays around 8MB instead of peaking at ~45MB. (Tested on Node.js 20, M2 MacBook Pro.)

Replacing robots.txt

One thing next-sitemap does that @power-seo/sitemap intentionally doesn't: robots.txt generation. 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.

When to stick with next-sitemap

I want to be fair here. next-sitemap is still the right choice if:

You're on Pages Router with no App Router migration planned
The site is mostly static and content rarely changes
You want robots.txt handled automatically without any extra code
Your team needs the simplest possible onboarding

The 416,000 weekly downloads and years of Stack Overflow answers represent a real community safety net. That matters when you need answers fast.

The route group bug only affects App Router projects. If you're on Pages Router, it doesn't apply.

What I actually learned from this

Silent failures are the most dangerous kind. A build error stops you immediately. A missing warning doesn't. Always verify your sitemap URL count against your actual route count — not just that the file exists.

Build-time sitemap generation ages poorly for content that changes frequently. Products, blog posts, user profiles — these need a sitemap that reflects the current state, not the state at the last deployment.

Route groups are too central to modern Next.js to work around. If your sitemap tool can't handle them, it's not compatible with how App Router projects are structured.

The source for Power SEO Sitemap is at GitHub Power SEO Repo if you want to look at the implementation.

Is your sitemap actually showing all your pages? If you're on App Router with route groups, it's worth a quick check right now — run cat public/sitemap.xml | grep -c "<loc>" after your next build and compare to your actual route count. The numbers might surprise you.

Drop your findings in the comments. And if anyone's found a working workaround for the next-sitemap route group bug that doesn't require maintaining a URL list manually — I'd genuinely like to know.

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.

DEV Community: Alamin

Next SEO vs Power SEO Audit: A 2026 Guide for TypeScript Developers

The Mental Model I Was Missing

How I Actually Use Next SEO (And Where It Gets You Stuck)

The Tool That Fixed the Blind Spot: Power SEO Audit

The CI Gate That Actually Changed How My Team Ships

So Which One Should You Use?

What I'd Tell Myself Before That Thursday

Power SEO Meta vs Next SEO: Which SEO Library is Better for Modern Next.js App Router?

Why Next.js App Router broke the old metadata approach

The metadata drift problem (and how to fix it)

The silent robots directive bug TypeScript can catch

One gotcha that catches everyone during migration

What I learned

FAQ

Still deciding?

Power SEO Sitemap vs Next Sitemap: Best Next.js Sitemap Generator Comparison (2026)

The bug: next-sitemap and App Router route groups

Why it's hard to fix

The fix: generate the sitemap in a Route Handler

Adding dynamic URLs and image sitemaps

Handling large catalogs

Replacing robots.txt

When to stick with next-sitemap

What I actually learned from this

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