Forem: Mitu Das

JavaScript SEO Checklist to Fix Ranking & Rendering Issues

Mitu Das — Wed, 29 Apr 2026 05:07:17 +0000

I spent 5 hours debugging why Google couldn't see my React app. The fix was 4 lines of code.

Not a webpack config. Not a server migration. Four. Lines. That afternoon taught me more about JavaScript SEO than any blog post I'd read. If you're building modern frontends with React, understanding React SEO is no longer optional. If you're shipping SPAs, Next.js apps, or anything that leans on client-side rendering and you care about organic traffic, this checklist is for you. Let's go through the real issues and the actual fixes.

1. Understand How Googlebot Actually Renders Your JS

Here's the counterintuitive part most developers miss: Googlebot renders JavaScript, but not instantly.

Google uses a two-wave indexing model. The first wave crawls your raw HTML. The second wave which may come days or weeks later renders the JavaScript and indexes the dynamic content. If your critical content only exists after JS executes, you're invisible to Google's first pass.

Run this test right now:

# Fetch your page the way Googlebot sees it (raw HTML, no JS)
curl -A "Googlebot" https://your-site.com/your-page | grep -i "your key content"

If that grep returns nothing, you have a rendering problem. Your users see the page fine. Googlebot's first wave does not.

The fix: Move critical content headings, body text, product descriptions into the server-rendered HTML, not a useEffect that fires after mount.

// Bad: Content only exists after JS runs
function ProductPage() {
  const [product, setProduct] = React.useState(null);

  React.useEffect(() => {
    fetch('/api/product/123').then(r => r.json()).then(setProduct);
  }, []);

  return <h1>{product?.name ?? ''}</h1>; // Empty on first Googlebot wave
}

// Good: Content in the initial HTML payload (Next.js example)
export async function getServerSideProps() {
  const product = await fetchProduct(123);
  return { props: { product } };
}

export default function ProductPage({ product }) {
  return <h1>{product.name}</h1>; // Present in raw HTML
}

2. Fix Your Meta Tags They're Probably Broken in SPAs

Client-side routing is the silent killer of meta tags. When a user navigates from / to /about in a React SPA, the <title> and <meta name="description"> in your index.html don't update unless you explicitly tell them to.

Check this in DevTools: navigate between routes and watch the <title> tag in the Elements panel. If it's not changing, every page on your site is competing for the same keyword in Google's index.

The manual fix with react-helmet:

import { Helmet } from 'react-helmet-async';

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

This works, but it's manual. For every new page type you create, you need to remember to wire up all five or six meta tags correctly. Miss one and you've got a page with no Open Graph image and a generic description.

If you're looking to automate this at scale across dozens of page templates I've been using power-seo on a Next.js App Router project. It handles the tag generation from a config object so you're not copy-pasting Helmet blocks everywhere. Setup looks like this:

npm install power-seo

// app/blog/[slug]/page.jsx
import { generateMetadata as powerSeoMeta } from 'power-seo';

export async function generateMetadata({ params }) {
  const post = await getPost(params.slug);

  return powerSeoMeta({
    title: post.title,
    description: post.excerpt,
    canonical: `https://mysite.com/blog/${post.slug}`,
    openGraph: { image: post.coverImage },
  });
}

Four lines instead of fifteen, and you get consistent output every time. The full checklist approach is documented here if you want to see how this fits into a broader SEO pipeline.

3. Structured Data: The Checklist Item Nobody Does

Most developers get meta tags right eventually. Almost nobody adds structured data, and that's a real missed opportunity especially for blogs, e-commerce, and local businesses.

Structured data (JSON-LD) tells Google exactly what type of content it's looking at. It's what gets you rich results: star ratings, FAQ dropdowns, breadcrumbs in the SERP. Here's what a correct Article schema looks like:

// components/ArticleSchema.jsx
export function ArticleSchema({ post, authorName, siteUrl }) {
  const schema = {
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": post.title,
    "description": post.excerpt,
    "author": {
      "@type": "Person",
      "name": authorName,
    },
    "datePublished": post.publishedAt,
    "dateModified": post.updatedAt,
    "image": post.coverImage,
    "url": `${siteUrl}/blog/${post.slug}`,
  };

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

Drop this in your page component and validate it at Google's Rich Results Test. You should see it parsed correctly within seconds.

Common mistake: Putting JSON-LD in a useEffect and appending it to the DOM dynamically. Don't. Inject it server-side or via the <head> so it's present in the raw HTML on that critical first Googlebot wave.

4. Canonical Tags and Duplicate Content Are Silently Killing Your Rankings

This is the one developers argue about most. "We don't have duplicate content." You probably do.

Any of these create duplicate pages in Google's index:

https://mysite.com/page vs https://mysite.com/page/
http:// vs https://
www.mysite.com vs mysite.com
/products?sort=price vs /products?sort=rating (faceted navigation)
Paginated routes without proper canonicals

The fix is a canonical tag on every page, pointing to the definitive URL:

// In Next.js App Router (app/layout.jsx or per-page)
export const metadata = {
  alternates: {
    canonical: 'https://mysite.com/products', // Always the clean, definitive URL
  },
};

For paginated content, page 2 should NOT self-canonicalize. It should either point to page 1 or self-canonicalize and use rel="next" / rel="prev" (Google has deprecated these, but they still help some crawlers):

<!-- On /products?page=2 -->
<link rel="canonical" href="https://mysite.com/products?page=2" />
<!-- Don't point page 2's canonical back to page 1 that tells Google page 2 is duplicate -->

Run a crawl with Screaming Frog or a similar tool once a month. Filter for pages with missing or non-self-referencing canonicals. Fix them before Google deindexes them.

What I Learned / Key Takeaways

Crawl your own site like a bot. Use curl -A "Googlebot" and Google's URL Inspection tool regularly. Your browser always shows the JS-rendered version. Googlebot sometimes doesn't.
Server-side render critical content. If a heading, product name, or article body only exists after a useEffect, it's at risk of not being indexed on the first wave.
Meta tags are per-route, not per-app. Every unique URL needs a unique title and description. Build this into your page template once, correctly, and never think about it again.
Structured data is low-hanging fruit. An hour of JSON-LD setup can unlock rich results that boost CTR without any change in rankings.

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

Over to You

Have you tried a Next SEO alternative for App Router yet? The original next-seo package has some rough edges with the new app/ directory, and I'm curious what patterns the community has settled on.

Drop your setup in the comments especially if you've found a clean way to handle dynamic OG images at scale. That's the next problem on my list.

How to Optimize SEO for React Apps Fast

Mitu Das — Tue, 28 Apr 2026 04:38:40 +0000

I Spent 3 Hours Debugging Why Google Couldn't See My React App. The Fix Was 4 Lines of Code.

Here's the frustrating truth about SEO for React apps: Google's crawler doesn't wait around for JavaScript to execute. It hits your URL, gets a <div id="root"></div>, and moves on. Your beautifully crafted product page? Invisible. Your carefully researched meta descriptions? Never rendered. If you've ever shipped a React SPA and watched it flatline in search rankings, this one's for you. By the end of this article, you'll know exactly how to fix it, with working code.

Why React Breaks SEO (And What's Actually Happening)

Client-side rendering is the culprit. When Googlebot requests a typical React app, it receives an almost-empty HTML shell. The actual content lives inside JavaScript bundles that need to be downloaded, parsed, and executed before anything meaningful appears in the DOM.

Googlebot can render JavaScript, but it does so in a second wave, often days later, and with limited resources. You can't rely on it.

Here's what a typical React app's initial HTML response looks like:

<!DOCTYPE html>
<html>
  <head>
    <title>My App</title>
  </head>
  <body>
    <div id="root"></div>
    <script src="/static/js/main.chunk.js"></script>
  </body>
</html>

There's no content, no meaningful <title>, no <meta> tags per route, and nothing for a crawler to index. You need either Server-Side Rendering (SSR), Static Site Generation (SSG), or at minimum dynamic meta tag injection to fix this.

Fix #1: Dynamic Meta Tags Per Route (Zero Framework Switch)

If migrating to Next.js isn't on the table right now, you can still win significant SEO ground by injecting meta tags dynamically per route using React Helmet Async.

Install:

npm install react-helmet-async

Wrap your app:

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

root.render(
  <HelmetProvider>
    <App />
  </HelmetProvider>
);

Use it per page:

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

export default function ProductPage({ product }) {
  return (
    <>
      <Helmet>
        <title>{product.name} | MyStore</title>
        <meta name="description" content={product.description} />
        <meta property="og:title" content={product.name} />
        <meta property="og:image" content={product.imageUrl} />
        <link rel="canonical" href={`https://mystore.com/products/${product.slug}`} />
      </Helmet>
      <main>{/* your content */}</main>
    </>
  );
}

Result: Every route now has unique, meaningful metadata. Social sharing works. Crawlers get something to read even before JS executes.

Fix #2: Structured Data with JSON-LD (Google's Preferred Format)

Meta tags are table stakes. Structured data is where you pull ahead. Google uses JSON-LD schema to power rich results, including star ratings, breadcrumbs, and FAQ dropdowns, directly in the SERP.

Here's a reusable component for product schema:

// components/ProductSchema.jsx
export default function ProductSchema({ product }) {
  const schema = {
    "@context": "https://schema.org",
    "@type": "Product",
    name: product.name,
    description: product.description,
    image: product.imageUrl,
    offers: {
      "@type": "Offer",
      price: product.price,
      priceCurrency: "USD",
      availability: product.inStock
        ? "https://schema.org/InStock"
        : "https://schema.org/OutOfStock",
    },
  };

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

Drop it into any page:

<ProductSchema product={product} />

Result: Eligible for rich results in Google Search. Takes 10 minutes to implement. Most React devs skip this entirely, which means you won't.

Fix #3: Automating This With `power-seo`

Implementing helmet + structured data + canonical URLs + Open Graph tags across every route manually gets tedious fast, especially in large codebases. This is where a utility like power-seo earns its place, not as a magic solution, but as a structured way to keep your SEO config consistent and co-located with your components.

npm install power-seo

// pages/BlogPost.jsx
import { PowerSEO } from 'power-seo';

export default function BlogPost({ post }) {
  return (
    <>
      <PowerSEO
        title={post.title}
        description={post.excerpt}
        canonical={`https://myblog.com/posts/${post.slug}`}
        openGraph={{
          type: 'article',
          image: post.coverImage,
          publishedTime: post.publishedAt,
        }}
        structuredData={{
          type: 'Article',
          author: post.author,
          datePublished: post.publishedAt,
        }}
      />
      <article>{/* post content */}</article>
    </>
  );
}

The value here is in the API surface: instead of remembering to add OG tags, canonical links, and schema separately across every page, you declare it once per route in a single component. It uses react-helmet-async under the hood, so it's compatible with SSR setups.

I wrote a deeper breakdown of the full approach, including prerendering strategies and Core Web Vitals impact, over at ccbd.dev/blog/how-to-improve-seo-for-react-apps if you want the extended version.

Fix #4: Prerendering for SPAs That Can't Do SSR

If you're stuck with a pure SPA but need better crawlability now, prerendering is your friend. Tools like vite-plugin-ssr or react-snap generate static HTML snapshots at build time.

npm install --save-dev react-snap

// package.json
"scripts": {
  "postbuild": "react-snap"
},
"reactSnap": {
  "source": "build",
  "minifyHtml": { "collapseWhitespace": false }
}

Run npm run build and react-snap headlessly crawls your app and outputs static HTML files for each route. Crawlers get real content. Users still get the full SPA experience.

Caveat: This breaks down with highly dynamic, auth-gated, or user-specific content. For those cases, SSR (Next.js, Remix) is the right long-term answer.

What I Learned

Crawlers don't wait. Client-side rendering is the default React behavior and the default SEO killer. Always treat the initial HTML response as your first impression for bots.
Meta tags per route are non-negotiable. A single <title>My App</title> for every page is leaving ranking potential on the table.
JSON-LD is low-effort, high-reward. Most developers skip it. Rich results are available to anyone who adds 15 lines of JSON.
Automation pays off at scale. Whether you use power-seo, a custom hook, or a shared component, keeping SEO config co-located with your page components prevents metadata from drifting out of sync as the app evolves.

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

Let's Talk About It

Have you tried a next-seo alternative for App Router yet? The App Router's native generateMetadata API changes the game for Next.js apps, but for everyone still on plain React SPAs, the options feel fragmented.

What's your current setup for handling SEO in React? Helmet, a custom hook, something else entirely? Drop it in the comments, I'm genuinely curious what the community has landed on in 2026.

SEO Analysis for Developers: Why Your JavaScript App Is Invisible to Google

Mitu Das — Mon, 27 Apr 2026 08:12:08 +0000

My React app had a 94 Lighthouse score, a sub-2s load time, and zero organic traffic after three months.

Not "low traffic." Zero. Not a single impression for any keyword I had written content for.

I'd completely skipped SEO analysis. Not because I didn't care, because I assumed a good Lighthouse score meant I was fine. It doesn't.

This is a practical guide to SEO analysis for developers, the part that actually matters, the part nobody teaches in your frontend course, and the part that will determine whether your app gets discovered or stays invisible forever.

What SEO Analysis Actually Means for a Developer

Most SEO guides are written for marketers. They talk about "content strategy" and "keyword clusters" and almost never show you a terminal command or a line of code.

SEO analysis for a developer means something different:

Inspecting raw HTML, not the browser-rendered DOM
Auditing metadata completeness programmatically
Validating structured data against Google's spec
Catching rendering gaps between what your React/Vue/Svelte app shows a user vs. what Googlebot actually sees

The distinction matters because your browser is lying to you. DevTools shows you a fully hydrated, beautifully rendered app. Googlebot, on its first crawl, may see an empty shell.

Step 1: Stop Trusting DevTools, Use `curl` Instead

Before you write a single line of SEO fix code, run this:

curl -s https://your-app.com | grep -E "<title>|<meta name|<link rel=\"canonical\"|<h1|ld\+json"

If your output looks like this:

<title></title>
<meta name="description" content="">

…you have a critical SEO analysis failure. Your metadata exists, but only after JavaScript hydrates the page. Googlebot crawls on a budget. If your JS takes too long, the crawler logs your page with empty metadata. No title signal. No description. No ranking chance.

This is the most common developer SEO mistake in 2026: shipping metadata inside useEffect instead of the initial HTML payload.

//  This runs AFTER hydration, invisible to crawlers on first byte
useEffect(() => {
  document.title = "My Product | Brand Name";
  document.querySelector('meta[name="description"]').content = "...";
}, []);

That code works for users. It fails for search engines.

Step 2: Build a Programmatic SEO Audit Script

Once you know the problem exists, you need a repeatable way to catch it, not just for this page, but for every page, on every deploy.

Here's a complete Node.js SEO analysis script you can drop into any project:

// scripts/seo-audit.js
// Run: node scripts/seo-audit.js
// Requires: npm install jsdom node-fetch

import fetch from "node-fetch";
import { JSDOM } from "jsdom";

const PAGES_TO_AUDIT = [
  "https://your-app.com/",
  "https://your-app.com/about",
  "https://your-app.com/blog",
  "https://your-app.com/products",
];

async function auditPage(url) {
  const res = await fetch(url, {
    headers: {
      // Simulate Googlebot user agent
      "User-Agent":
        "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)",
    },
  });

  const html = await res.text();
  const dom = new JSDOM(html);
  const doc = dom.window.document;

  // Extract all critical SEO signals
  const title = doc.querySelector("title")?.textContent?.trim();
  const description = doc
    .querySelector('meta[name="description"]')
    ?.getAttribute("content")
    ?.trim();
  const canonical = doc
    .querySelector('link[rel="canonical"]')
    ?.getAttribute("href")
    ?.trim();
  const h1Elements = doc.querySelectorAll("h1");
  const ogTitle = doc
    .querySelector('meta[property="og:title"]')
    ?.getAttribute("content");
  const ogDescription = doc
    .querySelector('meta[property="og:description"]')
    ?.getAttribute("content");
  const robots = doc
    .querySelector('meta[name="robots"]')
    ?.getAttribute("content");
  const jsonLdScripts = doc.querySelectorAll(
    'script[type="application/ld+json"]'
  );

  // Evaluate issues
  const issues = [];
  if (!title || title.length < 10) issues.push("[FAIL] Missing or too-short title");
  if (title && title.length > 60) issues.push("[WARN] Title exceeds 60 chars");
  if (!description) issues.push("[FAIL] Missing meta description");
  if (description && description.length > 160)
    issues.push("[WARN] Description exceeds 160 chars");
  if (!canonical) issues.push("[WARN] No canonical tag");
  if (h1Elements.length === 0) issues.push("[FAIL] No <h1> found");
  if (h1Elements.length > 1)
    issues.push(`[WARN] Multiple <h1> tags (${h1Elements.length})`);
  if (!ogTitle) issues.push("[WARN] Missing og:title");
  if (!ogDescription) issues.push("[WARN] Missing og:description");
  if (jsonLdScripts.length === 0)
    issues.push("[INFO] No structured data (JSON-LD) found");

  // Print results
  const status = issues.filter((i) => i.startsWith("[FAIL]")).length > 0 ? "[FAIL]" : "[PASS]";
  console.log(`\n${status} ${url}`);
  console.log(`   Title: ${title || "MISSING"} (${(title || "").length} chars)`);
  console.log(
    `   Description: ${(description || "MISSING").substring(0, 60)}... (${(description || "").length} chars)`
  );
  console.log(`   Canonical: ${canonical || "MISSING"}`);
  console.log(`   H1 count: ${h1Elements.length}`);
  console.log(`   JSON-LD blocks: ${jsonLdScripts.length}`);

  if (issues.length > 0) {
    console.log("\n   Issues:");
    issues.forEach((issue) => console.log(`   ${issue}`));
    process.exitCode = 1;
  }
}

(async () => {
  console.log("Running SEO Analysis...\n");
  for (const url of PAGES_TO_AUDIT) {
    await auditPage(url);
  }
  console.log("\nSEO audit complete.");
})();

Add it to package.json:

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

Result: Running this as-is on my app surfaced four pages with empty titles and two pages missing canonical tags entirely, issues that had been silently killing my rankings for months. The Googlebot user-agent simulation also revealed that one route was returning a noindex directive in staging that had leaked to production.

Step 3: Fix Metadata at the Server Layer, Not the Client

Now that your audit script tells you what's broken, here's how to fix it correctly per framework:

Next.js (App Router), The Right Way

// app/blog/[slug]/page.js
export async function generateMetadata({ params }) {
  const post = await getPost(params.slug);

  return {
    title: `${post.title} | Your Blog Name`,
    description: post.excerpt,
    alternates: {
      canonical: `https://your-app.com/blog/${post.slug}`,
    },
    openGraph: {
      title: post.title,
      description: post.excerpt,
      url: `https://your-app.com/blog/${post.slug}`,
      type: "article",
      publishedTime: post.publishedAt,
      authors: [post.author.name],
    },
    twitter: {
      card: "summary_large_image",
      title: post.title,
      description: post.excerpt,
    },
  };
}

export default async function BlogPostPage({ params }) {
  const post = await getPost(params.slug);
  return <article>{/* content */}</article>;
}

Remix, Route-Level Metadata

// app/routes/blog.$slug.jsx
export const meta = ({ data }) => {
  if (!data?.post) return [{ title: "Post Not Found" }];

  return [
    { title: `${data.post.title} | Your Blog` },
    { name: "description", content: data.post.excerpt },
    {
      tagName: "link",
      rel: "canonical",
      href: `https://your-app.com/blog/${data.post.slug}`,
    },
    { property: "og:title", content: data.post.title },
    { property: "og:type", content: "article" },
  ];
};

export const loader = async ({ params }) => {
  const post = await getPost(params.slug);
  return json({ post });
};

Plain Node.js / Express SSR

// server.js, render metadata into the HTML template directly
app.get("/blog/:slug", async (req, res) => {
  const post = await getPost(req.params.slug);

  const html = `<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>${escapeHtml(post.title)} | Your Blog</title>
    <meta name="description" content="${escapeHtml(post.excerpt)}" />
    <link rel="canonical" href="https://your-app.com/blog/${post.slug}" />
    <meta property="og:title" content="${escapeHtml(post.title)}" />
    <meta property="og:description" content="${escapeHtml(post.excerpt)}" />
    <meta property="og:type" content="article" />
  </head>
  <body>
    <div id="root">${renderToString(<App post={post} />)}</div>
  </body>
</html>`;

  res.send(html);
});

Result: After migrating from useEffect-based title injection to Next.js generateMetadata, my curl output went from showing empty tags to showing fully populated metadata on the first byte. Google Search Console confirmed proper crawling within 48 hours.

Step 4: Add Structured Data, The Layer That Unlocks Rich Results

This is where most developer SEO guides end, and where most developer sites stop short. Structured data (JSON-LD / Schema.org) is the layer that transforms a normal search listing into a rich result with star ratings, FAQ dropdowns, breadcrumbs, or article metadata.

Here's a production-ready component that handles Article schema:

// components/structured-data/ArticleSchema.jsx
export function ArticleSchema({
  title,
  description,
  datePublished,
  dateModified,
  authorName,
  authorUrl,
  imageUrl,
  url,
}) {
  const schema = {
    "@context": "https://schema.org",
    "@type": "TechArticle",
    headline: title,
    description: description,
    datePublished: datePublished,
    dateModified: dateModified || datePublished,
    url: url,
    image: imageUrl
      ? {
          "@type": "ImageObject",
          url: imageUrl,
          width: 1200,
          height: 630,
        }
      : undefined,
    author: {
      "@type": "Person",
      name: authorName,
      url: authorUrl,
    },
    publisher: {
      "@type": "Organization",
      name: "Your Site Name",
      url: "https://your-app.com",
      logo: {
        "@type": "ImageObject",
        url: "https://your-app.com/logo-schema.png",
        width: 600,
        height: 60,
      },
    },
    mainEntityOfPage: {
      "@type": "WebPage",
      "@id": url,
    },
  };

  // Remove undefined keys before serializing
  const clean = JSON.parse(JSON.stringify(schema));

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(clean, null, 2) }}
    />
  );
}

And a FAQ schema component (FAQ rich results are especially valuable for developer documentation and tutorial pages):

// components/structured-data/FAQSchema.jsx
export function FAQSchema({ faqs }) {
  const schema = {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    mainEntity: faqs.map(({ question, answer }) => ({
      "@type": "Question",
      name: question,
      acceptedAnswer: {
        "@type": "Answer",
        text: answer,
      },
    })),
  };

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

// Usage:
// <FAQSchema faqs={[
//   { question: "What is SEO analysis?", answer: "SEO analysis is the process of..." },
//   { question: "How do I audit metadata?", answer: "Run curl against your raw HTML..." }
// ]} />

Validate everything at Google's Rich Results Test before deploying.

Result: I added TechArticle schema to my blog posts and FAQPage schema to three documentation pages. Within six weeks, two of those doc pages appeared with FAQ dropdowns in search results. Same content, same ranking position, but visibly richer listings with noticeably higher click-through rate.

Step 5: Automate SEO Analysis in Your CI Pipeline

Manual audits don't scale. One refactor, one CMS API change, one package update, and your canonical tags could silently break across hundreds of pages. The only sustainable approach is automated SEO analysis on every deploy.

Here's a minimal GitHub Actions workflow:

# .github/workflows/seo-audit.yml
name: SEO Audit

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  seo-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"

      - name: Install dependencies
        run: npm ci

      - name: Run SEO audit
        run: npm run seo:audit
        env:
          SITE_URL: ${{ secrets.SITE_URL }}

For more advanced needs, like detecting metadata regressions across dynamic routes, auditing structured data completeness, or running diff comparisons between deployments, I used @power-seo during a project audit. It's a lightweight Node.js package purpose-built for programmatic SEO analysis in JavaScript apps: inspecting rendered vs. raw HTML differences, catching missing structured data, and scoring metadata across route patterns.

A deeper technical breakdown of this approach, covering how JavaScript rendering affects SEO, how to audit at scale, and how to benchmark ranking signals in modern web apps, is documented here: SEO Analysis for JavaScript: Auditing and Ranking Modern Web Apps.

Step 6: Understand What Google Actually Sees, The Rendering Gap

The most underrated part of SEO analysis for developers is understanding the rendering gap: the difference between what users see and what Googlebot indexes.

Here's a quick diagnostic utility that fetches your page twice, once raw, once rendered, and diffs the SEO-critical fields:

// scripts/rendering-gap-check.js
// Requires: npm install puppeteer node-fetch jsdom

import fetch from "node-fetch";
import puppeteer from "puppeteer";
import { JSDOM } from "jsdom";

async function extractSEOFields(html) {
  const doc = new JSDOM(html).window.document;
  return {
    title: doc.querySelector("title")?.textContent?.trim() || "",
    description:
      doc
        .querySelector('meta[name="description"]')
        ?.getAttribute("content") || "",
    h1: doc.querySelector("h1")?.textContent?.trim() || "",
    canonical:
      doc.querySelector('link[rel="canonical"]')?.getAttribute("href") || "",
  };
}

async function checkRenderingGap(url) {
  // Raw HTML (what crawler sees on first byte)
  const rawRes = await fetch(url);
  const rawHtml = await rawRes.text();
  const rawFields = await extractSEOFields(rawHtml);

  // Rendered HTML (what browser + JS produces)
  const browser = await puppeteer.launch({ headless: "new" });
  const page = await browser.newPage();
  await page.goto(url, { waitUntil: "networkidle0" });
  const renderedHtml = await page.content();
  await browser.close();
  const renderedFields = await extractSEOFields(renderedHtml);

  // Detect gaps
  console.log(`\nRendering Gap Analysis: ${url}`);
  for (const key of Object.keys(rawFields)) {
    const match = rawFields[key] === renderedFields[key];
    console.log(
      `${match ? "[MATCH]" : "[DIFF]"} ${key}:\n   Raw:      "${rawFields[key]}"\n   Rendered: "${renderedFields[key]}"`
    );
  }
}

await checkRenderingGap("https://your-app.com/blog/my-post");

Result: This script revealed that three of my pages had a rendering gap on the <h1>, the raw HTML had a generic fallback, while the rendered version showed the correct dynamic title. Google was indexing the fallback.

What I Learned

curl is your most honest SEO tool. DevTools shows you the illusion. curl shows you the truth that Googlebot sees.
useEffect is not an SEO strategy. If your metadata only exists after JavaScript runs, it doesn't reliably exist for crawlers. Use SSR or a proper metadata API.
Structured data is the highest-leverage SEO move most developers never make. Adding JSON-LD to existing content often boosts CTR without changing ranking position at all.
Automate SEO analysis in CI. A one-time audit fixes today's problems. Automated checks prevent regressions from shipping silently on every deploy.
The rendering gap is real and measurable. Don't assume your app looks the same to Googlebot as it does to a user. Diff them. Fix the gaps.

If you want to explore the tooling and workflow in depth:
https://github.com/CyberCraftBD/power-seo

Let's Talk About Your SEO Workflow

What's your current approach to SEO analysis on JavaScript projects? Are you running any automated checks, or still doing it manually before launch?

Have you ever discovered a rendering gap that had been killing your rankings silently? Drop it in the comments, I'd genuinely like to know how different teams handle this.

How to Build a Custom ERP System : The Complete Developer's Guide

Mitu Das — Sun, 26 Apr 2026 11:17:21 +0000

I've been through the grind of ERP builds, from scoping sessions that ran way too long, to deploys that finally clicked everything into place for a business. In this guide, I'm going to walk you through exactly how to build a custom ERP system: what to plan, how to architect it, which modules to prioritize, and how to avoid the expensive mistakes most teams make.

01. Why Build a Custom ERP System?

Direct Answer: A custom ERP system is enterprise resource planning software built entirely around your specific business workflows, not the other way around. Unlike SAP or Oracle, you own every line of logic.

Here's the honest truth: off-the-shelf ERP systems like SAP, Microsoft Dynamics, or NetSuite work great, for businesses that fit neatly into a standard mold. But if you're reading this, chances are your operations have grown past what out-of-the-box software can handle without a mess of workarounds, expensive licenses, and consultants patching gaps every quarter.

I've talked to operations managers who were paying $180,000/year in SAP licensing fees for 40 users, and still running a parallel Excel sheet because the system couldn't handle their procurement logic. That's the real problem a custom ERP solves.

Custom vs. Off-the-Shelf: The Real Trade-off

Factor	Custom ERP	Off-the-Shelf ERP
Upfront Cost	Higher ($50K to $500K+)	Lower (subscription-based)
Fit to Business	Perfect, built for you	Requires process adaptation
Ongoing Licensing	None (you own it)	$1,500 to $10,000+/user/year
Scalability	Full control	Vendor-dependent
Time to Deploy	6 to 24 months	3 to 12 months
Data Ownership	Complete	Shared infrastructure
Long-term ROI	High (3 to 5 year horizon)	Moderate

The decision to go custom comes down to this: if your business is running unique processes that generate real competitive advantage, you should own the software that runs them. If you're doing vanilla accounting and HR, buy something off the shelf.

02. Planning Your Custom ERP: Start Here

I can't stress this enough, the planning phase is where custom ERP projects succeed or fail. Most teams rush into development because they're excited to see something built. Don't. Every hour you spend in planning saves you three hours of rework later.

Step 1: Map Your Current Business Processes

Before you write a single line of code or hire a development team, sit down with every department head and document exactly how work flows through your organization today. Not how it's supposed to work, how it actually works. Use process flow diagrams, shadow your team for a day, run workshops. You need ground truth.

The deliverable here is a Business Process Document (BPD) that maps every major workflow: order to cash, procure to pay, hire to retire, etc. This becomes your requirements bible for the entire custom ERP software development process.

Step 2: Define Your Non-Negotiables

Every project has features that must work on day one, and features that would be nice eventually. Be ruthless about this distinction. I typically use a MoSCoW framework, Must Have, Should Have, Could Have, Won't Have (for now). Your Must Haves are your MVP scope.

Pro Tip: Limit your MVP to 3 to 4 core modules. A focused ERP that does inventory and finance perfectly will deliver more value than a sprawling system that does 10 things poorly.

Step 3: Identify All Integration Points

Your ERP will not live in isolation. Catalogue every external system it needs to talk to: your e-commerce platform, payment gateways, shipping APIs, CRM, BI tools, government tax portals. Integration complexity is the single biggest source of ERP project cost overruns I've seen.

03. ERP System Design and Architecture

This is where the technical foundation is set. A poor architecture decision here will haunt you for years. Let me walk you through the core decisions in ERP system design that you need to make early.

Monolith vs. Microservices

For most mid-sized businesses, I recommend starting with a modular monolith, a single deployable application organized into well-defined internal modules. This gives you the simplicity of a monolith with the organizational structure you'll need later if you migrate to microservices.

Pure microservices architecture is powerful but introduces significant operational overhead: service discovery, distributed tracing, inter-service communication latency, complex deployments. Unless you already have DevOps expertise on the team, the complexity cost usually isn't worth it at the start.

Database Design Principles for ERP

The database is the heart of any custom ERP. Here's what I prioritize in ERP system design:

-- Core ERP schema principles

-- 1. Never hard-delete records, use soft delete with status flags
ALTER TABLE orders ADD COLUMN deleted_at TIMESTAMP NULL DEFAULT NULL;

-- 2. Audit trail on every business-critical table
CREATE TABLE audit_log (
  id         BIGSERIAL PRIMARY KEY,
  table_name VARCHAR(100) NOT NULL,
  record_id  BIGINT NOT NULL,
  action     VARCHAR(20) NOT NULL,
  changed_by BIGINT REFERENCES users(id),
  changed_at TIMESTAMPTZ DEFAULT now(),
  old_data   JSONB,
  new_data   JSONB
);

-- 3. Multi-company support from day one
ALTER TABLE products ADD COLUMN company_id BIGINT REFERENCES companies(id);

Role-Based Access Control (RBAC) Architecture

Your ERP system design must include a robust permissions model before you build anything else. I model this with three layers: Roles (Warehouse Manager, Accountant, Admin), Permissions (READ_INVENTORY, APPROVE_PURCHASE_ORDER), and Resource Scopes (company-level, location-level, department-level). Getting this right early means you won't be retro-fitting security into 40 tables later.

Watch Out: Never build your access control logic inside individual features. Centralize it in a permission middleware layer that every module calls. This is the most common ERP architecture mistake I see.

04. Core Modules Every Custom ERP Needs

A well-designed custom ERP is built as a collection of interconnected modules. Here are the ones I consider essential, and what each actually does for the business:

Inventory Management
Real-time stock tracking, multi-warehouse support, reorder alerts, and SKU management.

Finance and Accounting
General ledger, accounts payable/receivable, tax calculation, and financial reporting.

Procurement
Purchase orders, vendor management, approval workflows, and goods receipt.

Manufacturing / Production
Bill of materials, work orders, production scheduling, and quality control checkpoints.

HR and Payroll
Employee records, attendance tracking, leave management, and salary processing.

Reporting and Analytics
Cross-module dashboards, KPI tracking, export to Excel/PDF, and scheduled reports.

Sales and CRM
Quotations, sales orders, customer accounts, and commission tracking.

Notifications and Workflow
Approval chains, automated alerts (email/SMS), and audit-ready activity logs.

For your first release, I'd recommend focusing on Inventory + Finance + Procurement as your MVP trio. These three modules share the most data dependencies and deliver immediate operational value. Layer in Manufacturing or HR in phase two.

05. Choosing the Right Tech Stack for ERP App Development

There's no single correct tech stack for ERP app development, but there are definitely better and worse choices depending on your team's strengths and your performance requirements. Here's what I've seen work well in production:

Layer	Recommended Options	Best For
Frontend	React + TypeScript, Vue 3, Angular	Complex UIs, data-heavy dashboards
Backend API	Node.js (NestJS), Python (Django/FastAPI), Java (Spring Boot)	Enterprise reliability and scalability
Database	PostgreSQL (primary), Redis (cache)	ACID compliance, complex queries
File Storage	AWS S3, Google Cloud Storage, MinIO (self-hosted)	Documents, invoices, attachments
Background Jobs	Celery (Python), BullMQ (Node), Sidekiq (Ruby)	Reports, payroll, batch processing
Search	Elasticsearch, Meilisearch	Product/order/customer lookup
Deployment	Docker + Kubernetes, or AWS ECS	Reliable, scalable infrastructure
Monitoring	Grafana + Prometheus, Sentry, Datadog	Production visibility, error tracking

One Stack Decision I Always Recommend

Build your API as a proper REST (or GraphQL) layer from day one, even if you only have one frontend client right now. I've seen too many ERP projects where the backend was tightly coupled to the web UI. Two years later, they need a mobile app or a third-party integration and the entire backend has to be refactored. Decouple early. You'll thank yourself later.

Pro Tip: For ERP app development targeting both web and mobile, React + React Native shares component logic and state management patterns, cutting frontend dev time significantly on the mobile layer.

06. The Custom ERP Software Development Process

Now let's get into the actual build. Here's the step-by-step process I follow for customized ERP development projects:

Step 1: Discovery and Requirements Documentation
2 to 4 weeks of stakeholder interviews, process mapping, and requirements sign-off. Output: a Business Process Document and a prioritized feature backlog in your project management tool.

Step 2: ERP System Design and Architecture Blueprint
Define the database schema, module boundaries, API contracts, and infrastructure plan. This document is reviewed by all senior developers before development begins. No exceptions.

Step 3: UI/UX Design for ERP Interfaces
ERP UI is notoriously bad. Invest here. Design wireframes, high-fidelity mockups, interactive prototype. Test with actual end-users, not just management. The warehouse manager who uses inventory 8 hours a day has better UX feedback than the CEO.

Step 4: Agile Sprint Development
2-week sprints, module by module. Build the data layer first, then API, then UI. Every sprint ends with a working, testable increment. No big-bang releases.

Step 5: Integration Development
Connect external systems. Build integration adapters with proper error handling, retry logic, and dead-letter queues. Never let a failed third-party API call silently corrupt your ERP data.

Step 6: Data Migration
Write migration scripts, run them against a production copy of old data, validate results with business stakeholders. Plan for at least two full dry runs before the real cutover.

Step 7: User Acceptance Testing (UAT) and Training
Real users test real workflows against real data. Train department leads who then train their teams. Build in-app help guides and short video walkthroughs. Support tickets will drop dramatically.

Step 8: Go-Live and Hypercare
Go live on a Friday with the full team available. Run a parallel period (both old and new system simultaneously) for 2 to 4 weeks if data integrity is critical. Assign dedicated support for the first month.

07. Cost and Timeline: What to Realistically Expect

Direct Answer: Custom ERP development typically costs $50,000 to $500,000+ and takes 6 to 36 months, depending on scope, team size, and integration complexity.

Let me break this down honestly, because vague ranges aren't helpful when you're budgeting a real project.

Project Size	Scope	Timeline	Estimated Cost
Small ERP	2 to 3 modules, less than 20 users	6 to 9 months	$50,000 to $120,000
Mid-Size ERP	4 to 6 modules, 20 to 100 users	10 to 18 months	$120,000 to $280,000
Enterprise ERP	8+ modules, 100+ users, multi-location	18 to 36 months	$280,000 to $500,000+

The Biggest Hidden Cost Drivers

In my experience, three things consistently blow ERP budgets: scope creep (stakeholders adding features mid-build without adjusting timeline), integration complexity (that old legacy system nobody told you about until month 4), and data migration surprises (dirty, inconsistent historical data that takes weeks to clean).

Budget a 20% contingency on top of your base estimate. Every single ERP project I've seen that skipped this contingency ended up needing it.

Build In-House vs. Hire a Custom ERP Software Development Services Partner

If you have a strong internal engineering team with ERP experience, building in-house gives you maximum control. But ERP systems have specific domain knowledge requirements, accounting logic, inventory cost methods, tax compliance, that generalist developers often underestimate. Partnering with a team that specializes in customized ERP development often gets you to production faster with fewer costly architectural mistakes.

A hybrid approach often works best: hire a specialized ERP development firm to set the architecture and lead module development, while embedding your internal developers to absorb knowledge and own post-launch maintenance.

Building a Custom ERP Is a Long Game Worth Playing

I've watched businesses transform after deploying the right custom ERP system. The inventory team stops firefighting stockouts. Finance closes the books in two days instead of two weeks. The CEO sees live operational data without waiting for someone to compile a report. That's the payoff, and it's real.

But it requires discipline: thorough planning, clear module prioritization, an architecture you're not embarrassed by in year three, and a team that understands both software engineering and business domain logic.

Start small. Build your MVP around 2 to 3 core modules. Get your team using it, gather feedback, and expand from a foundation that actually works. The businesses that try to build everything at once almost always end up with a system that nobody fully trusts, and they end up back where they started, with spreadsheets running in parallel.

If you're at the stage of evaluating whether to invest in custom ERP software development services, the most valuable thing you can do right now is spend two weeks properly documenting how your business actually operates today. That document alone, before you spend a dollar on development, will save you from the most expensive mistakes in the process.

Website Audit Tools Free of Cost That Developers Actually Use

Mitu Das — Sun, 26 Apr 2026 06:57:50 +0000

I spent an entire afternoon wondering why my client's Next.js portfolio wasn't showing up on Google. Clean code, fast load times, good content. Turned out the meta tags were rendering after the crawler gave up. One audit. That's all it took to find it. If you're shipping sites without running a structured audit first, you're guessing. This article walks through how to audit a website properly using free tools, including how to build a lightweight audit script yourself, so you stop guessing and start shipping with confidence.

Why Most Developers Skip Audits (And Pay for It Later)

Auditing feels like QA work: unglamorous, easy to defer. But consider: Google's crawler doesn't execute JavaScript the same way your browser does. Lighthouse scores don't catch missing canonical tags. And broken internal links are practically invisible until a real user hits a dead end.

The good news is that website audit tools free of cost are genuinely powerful now, and you don't have to leave your terminal to use them.

Here's what a minimal but effective audit should check:

Meta tags (title, description, og:image, canonical)
Robots.txt and sitemap validity
Broken links (internal + external)
Core Web Vitals baseline
Structured data / JSON-LD presence

Let's build this layer by layer.

Step 1: Scrape and Validate Meta Tags with Node.js

The fastest free audit you can run is checking whether your pages are even telling Google what they're about.

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

const url = 'https://your-site.com';

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

  const results = {
    title: $('title').text() || '❌ Missing',
    description: $('meta[name="description"]').attr('content') || '❌ Missing',
    canonical: $('link[rel="canonical"]').attr('href') || '❌ Missing',
    ogTitle: $('meta[property="og:title"]').attr('content') || '❌ Missing',
    ogImage: $('meta[property="og:image"]').attr('content') || '❌ Missing',
  };

  console.table(results);

  const missing = Object.entries(results)
    .filter(([_, v]) => v.startsWith('❌'))
    .map(([k]) => k);

  if (missing.length) {
    console.warn(`\n⚠️  Missing fields: ${missing.join(', ')}`);
  } else {
    console.log('\n✅ All meta tags present.');
  }
}

auditMeta(url);

Run it:

npm install cheerio node-fetch
node audit-meta.js

Result: A clean table printed in your terminal showing exactly what's missing. No browser extensions, no paid dashboards. If canonical is missing on a site with query parameters, that alone could be causing indexing issues.

Step 2: Validate Robots.txt and Sitemap Programmatically

A misconfigured robots.txt can silently block your entire site from being indexed. This happens more often than you'd think after a deployment pipeline misconfiguration.

// audit-crawlability.js
import fetch from 'node-fetch';

const BASE = 'https://your-site.com';

async function checkFile(path) {
  const url = `${BASE}${path}`;
  try {
    const res = await fetch(url);
    if (!res.ok) return `❌ ${url} returned ${res.status}`;
    const text = await res.text();
    if (path === '/robots.txt' && text.includes('Disallow: /')) {
      return `⚠️  robots.txt may be blocking everything:\n${text.slice(0, 200)}`;
    }
    return `✅ ${url} is accessible (${text.length} bytes)`;
  } catch (e) {
    return `❌ ${url} unreachable: ${e.message}`;
  }
}

(async () => {
  console.log(await checkFile('/robots.txt'));
  console.log(await checkFile('/sitemap.xml'));
})();

Result: You'll immediately see if your sitemap is returning a 404 (common after CMS migrations) or if robots.txt contains a blanket Disallow: /, a mistake that's devastatingly easy to make and hard to notice.

Step 3: Crawl for Broken Internal Links

Broken internal links hurt both UX and crawl budget. Here's a lightweight crawler that stays within your own domain:

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

const BASE = 'https://your-site.com';
const visited = new Set();
const broken = [];

async function crawl(url) {
  if (visited.has(url)) return;
  visited.add(url);

  try {
    const res = await fetch(url);
    if (!res.ok) {
      broken.push({ url, status: res.status });
      return;
    }

    const html = await res.text();
    const $ = cheerio.load(html);

    const links = [];
    $('a[href]').each((_, el) => {
      const href = $(el).attr('href');
      if (href.startsWith('/')) links.push(BASE + href);
      else if (href.startsWith(BASE)) links.push(href);
    });

    for (const link of links) {
      await crawl(link);
    }
  } catch (e) {
    broken.push({ url, status: 'NETWORK_ERROR' });
  }
}

(async () => {
  await crawl(BASE);
  if (broken.length === 0) {
    console.log('✅ No broken links found.');
  } else {
    console.log('❌ Broken links:');
    console.table(broken);
  }
})();

Cap this with a depth limit or visited.size < 50 guard for large sites. For production-scale crawling, this is where a dedicated tool helps.

Step 4: Where power-seo Fits In

Once you've validated your meta tags, crawlability, and link health manually, you might want to automate this into a CI check or run it across multiple URLs at once. The power-seo npm package bundles many of these checks into a single CLI call, useful when you're auditing client sites regularly or want a structured JSON report you can diff between deployments.

npx power-seo audit https://your-site.com --output report.json

It won't replace understanding what you're looking for (which the steps above give you), but it's a solid time-saver once you know your audit checklist. The CyberCraft team also wrote a deeper dive on free JavaScript SEO audit approaches worth reading alongside this.

What I Learned

Audit before you launch, not after you notice a traffic drop. Most SEO issues are invisible until they've already cost you weeks of ranking.
Robots.txt and canonical tags cause more invisible damage than any other two things combined. Check them first, every time.
You don't need a $99/month SaaS to do a solid audit. Node.js, cheerio, and 100 lines of code will catch 80% of real-world issues.
Automate it. A pre-deploy audit script in your CI pipeline pays for itself the first time it catches a misconfiguration before it goes live.

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

What's Your Audit Workflow?

Do you run any automated checks before deploying? Have you been burned by a meta tag issue or a blocked robots.txt? Drop your war story in the comments, and if you found the scripts above useful, a ❤️ helps other developers find this. What would you add to this audit checklist?

I Built a JavaScript SEO Content Analyzer in an Afternoon. Here's Everything I Learned

Mitu Das — Sat, 25 Apr 2026 10:57:05 +0000

I Spent 3 Hours Debugging Why Google Couldn't See My React App

The Lighthouse score was 98. The site felt fast. Users loved it. But Google Search Console was returning crawl errors, and organic traffic was flatlining. Turns out, my beautifully rendered React app was serving a nearly empty

to bots: no meta description, no canonical, broken Open Graph tags. The content existed, just not when crawlers looked and that’s exactly where an ai SEO tool would have caught the issue early by simulating how search engines actually render and index your pages.

This article walks you through building a JavaScript SEO content analyzer that audits your pages programmatically so you catch these issues before Google does.

Why JavaScript Apps Break SEO (And Why Linters Won't Save You)

Most SEO problems in JS-heavy apps aren't syntax errors. They're runtime timing issues. Your <title> tag gets injected after the initial HTML is served. A crawler with a short render timeout sees nothing.

The classic mistakes:

Meta tags set inside useEffect or lifecycle hooks (too late for some crawlers)
Dynamic Open Graph tags that depend on API responses
Missing rel="canonical" on paginated or filtered routes
robots meta tags accidentally blocking indexing in staging configs that leaked to production

A manual audit catches maybe 30% of these. Automated analysis catches the rest, consistently, on every build.

Step 1: Fetch and Parse Page Metadata Programmatically

Start simple. Here's a Node.js script that fetches a URL and extracts SEO-critical tags:

import * as cheerio from 'cheerio';

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

  return {
    title: $('title').text() || null,
    description: $('meta[name="description"]').attr('content') || null,
    canonical: $('link[rel="canonical"]').attr('href') || null,
    robots: $('meta[name="robots"]').attr('content') || null,
    ogTitle: $('meta[property="og:title"]').attr('content') || null,
    ogImage: $('meta[property="og:image"]').attr('content') || null,
    h1Count: $('h1').length,
    h1Text: $('h1').first().text() || null,
  };
}

// Usage
const result = await analyzeSEO('https://yoursite.com/blog/my-post');
console.log(result);

Install cheerio: npm install cheerio

Result: You now have a structured object representing the SEO state of any page. Run this across your sitemap and you've got a full audit.

Step 2: Score and Flag Issues Automatically

Raw data is useful. Scored data is actionable. Add a simple scoring layer:

function scoreResult(data) {
  const issues = [];
  let score = 100;

  if (!data.title) {
    issues.push({ severity: 'critical', message: 'Missing <title> tag' });
    score -= 30;
  } else if (data.title.length < 30 || data.title.length > 60) {
    issues.push({ severity: 'warning', message: `Title length (${data.title.length} chars) — optimal is 30–60` });
    score -= 10;
  }

  if (!data.description) {
    issues.push({ severity: 'critical', message: 'Missing meta description' });
    score -= 20;
  } else if (data.description.length > 160) {
    issues.push({ severity: 'warning', message: 'Meta description exceeds 160 chars, may be truncated' });
    score -= 5;
  }

  if (!data.canonical) {
    issues.push({ severity: 'warning', message: 'No canonical URL specified' });
    score -= 10;
  }

  if (data.robots && data.robots.includes('noindex')) {
    issues.push({ severity: 'critical', message: 'Page is set to noindex, will not be crawled!' });
    score -= 40;
  }

  if (data.h1Count === 0) {
    issues.push({ severity: 'warning', message: 'No H1 found on page' });
    score -= 10;
  } else if (data.h1Count > 1) {
    issues.push({ severity: 'info', message: `Multiple H1s found (${data.h1Count}), consider consolidating` });
    score -= 5;
  }

  return { score: Math.max(0, score), issues };
}

Combine both functions and you have a working CLI analyzer. Pipe it into your CI pipeline and fail builds when critical issues are found.

Step 3: Scale It Across Your Entire Sitemap

Single-page analysis is fine for debugging. For real coverage, parse your sitemap and batch-analyze every URL:

import { XMLParser } from 'fast-xml-parser';

async function analyzeSitemap(sitemapUrl) {
  const res = await fetch(sitemapUrl);
  const xml = await res.text();
  const parser = new XMLParser();
  const parsed = parser.parse(xml);

  const urls = parsed.urlset.url.map(u => u.loc);

  const results = await Promise.allSettled(
    urls.map(async (url) => {
      const data = await analyzeSEO(url);
      const scored = scoreResult(data);
      return { url, ...scored, ...data };
    })
  );

  return results
    .filter(r => r.status === 'fulfilled')
    .map(r => r.value)
    .sort((a, b) => a.score - b.score); // worst first
}

// Usage
const report = await analyzeSitemap('https://yoursite.com/sitemap.xml');
console.table(report.map(r => ({ url: r.url, score: r.score, issues: r.issues.length })));

Install: npm install fast-xml-parser

Running this on a 200-page site takes about 15-20 seconds and gives you a prioritized list of pages that need attention, sorted by SEO health score, worst first.

Step 4: Where a Library Like power-seo Fits In

Once you've built this yourself, you understand what a good SEO analysis library needs to do. I've been experimenting with @power-seo as a drop-in that handles a lot of this boilerplate, including structured data validation, heading hierarchy analysis, and image alt-text checks that the script above doesn't cover.

Here's the same audit using it:

import { analyzePage } from '@power-seo/core';

const report = await analyzePage('https://yoursite.com/blog/my-post');

console.log(report.score);       // 0-100
console.log(report.issues);      // categorized by severity
console.log(report.structured);  // JSON-LD / schema.org validation

It's worth trying if you want to skip the boilerplate. There's also a deeper write-up on auditing modern JS apps over at ccbd.dev/blog/seo-analysis-for-javascript-auditing-and-ranking-modern-web-apps if you want to go further.

What I Learned

Lighthouse scores and SEO health are not the same thing. A perfect performance score can coexist with completely broken meta tags.
The noindex bug is more common than you think. Staging configs get merged. Always add a CI check for it.
Batch sitemap auditing finds the long tail. Your homepage is probably fine. It's page 47 of your blog archive that's broken.
Build the tool first, then evaluate libraries. Understanding what cheerio-based parsing actually does makes you a better consumer of any abstraction on top of it.

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

What's Your SEO Debugging Story?

Have you been burned by a JS rendering issue that killed your search rankings? Drop it in the comments. I'm curious how common the noindex leak is out in the wild. And if you extend this analyzer with keyword density checks or structured data validation, share what you built. 🔍

SEO Mistakes I Keep Seeing Developers Make (And How to Fix Them With Code)

Mitu Das — Sat, 25 Apr 2026 06:10:53 +0000

Let me be honest with you: I’ve audited a lot of sites. Technically solid ones, beautifully designed ones, sites with great content. And yet they weren’t ranking. Or they were ranking for the wrong things entirely. Or pages were just disappearing from Google’s index with no obvious reason, classic SEO mistakes that most people don’t even realize they’re making.

Here's what I've figured out after going through this enough times: most SEO problems don't come from one catastrophic error. They come from a cluster of smaller, interconnected issues that compound over time. A missing sitemap here. An orphan page there. Short descriptions with no keywords. Content that doesn't match what users actually want. Each one costs you a few positions. Together, they sink you. And the good news is every single one of these mistakes is fully programmable, so let me walk you through them. I'll also show you where AI SEO tools fit into this workflow, because they've genuinely changed how I handle certain parts of the audit process.

1. Fix crawlability before anything else to avoid SEO mistakes

The first thing I tell anyone who asks where to start is this: if Googlebot can't find your pages, they don't rank, full stop. A malformed or missing XML sitemap is one of the most common silent killers of organic traffic I run into, and you won't notice it until you go deliberately looking for it, which is exactly why sites suffer from this for months. This is also where SEO for single page applications gets uniquely painful, because SPAs often render content client-side and leave crawlers with an empty shell if the sitemap and server-side rendering aren't set up correctly.

Generate a Standards-Compliant Sitemap Automatically

You can fix it with @power-seo/sitemap and stop worrying about it entirely.

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

const xml = generateSitemap({
  hostname: 'https://example.com',
  urls: [
    { loc: '/', lastmod: '2026-01-01', changefreq: 'daily', priority: 1.0 },
    { loc: '/blog/react-seo-guide', lastmod: '2026-01-15', priority: 0.8 },
    { loc: '/products/widget', changefreq: 'weekly', priority: 0.7 },
  ],
});

For large catalogs that go over the 50,000-URL spec limit, splitSitemap() handles chunking and generates a sitemap index automatically.

2. Redirect Chains Are Bleeding Your Link Equity

I see this every time a team defines redirects in multiple places: next.config.js, a CMS, a CDN config. The inconsistencies are almost impossible to audit manually, and they bleed link equity in ways that get really painful during migrations.

Define Rules Once, Apply Them Everywhere

The fix is a single source of truth that exports to every framework.

import { createRedirectEngine } from '@power-seo/redirects';

const engine = createRedirectEngine({
  rules: [
    { source: '/old-about', destination: '/about', statusCode: 301 },
    { source: '/blog/:slug', destination: '/articles/:slug', statusCode: 301 },
  ],
});

const match = engine.match('/old-about');
// { resolvedDestination: '/about', statusCode: 301 }

The same rule array exports to Next.js, Remix, and Express. One source of truth, no divergence across environments.

3. Meta Tags Are Not Optional

Meta tags are where I see developers consistently underestimate the cost of neglect. A page with no meta description, a title that gets cut off in search results, or an Open Graph image with wrong dimensions will underperform even when it ranks. Google generates its own snippet when a description is absent, and in my experience it rarely picks the right one. For SEO for single page applications specifically, this is even more critical because meta tags injected purely on the client side often never get read by crawlers at all. You need them rendered in the initial HTML response.

Write Meta Config Once, Get Correct Output for Every Framework

import { createMetadata } from '@power-seo/meta';

export const metadata = createMetadata({
  title: 'React SEO Best Practices - 2026 Guide',
  description: 'Learn the most common SEO mistakes in React apps and how to fix them with structured data, meta tags, and Core Web Vitals improvements.',
  canonical: 'https://example.com/blog/react-seo',
  robots: { index: true, follow: true, maxSnippet: 150, maxImagePreview: 'large' },
  openGraph: {
    type: 'article',
    images: [{ url: 'https://example.com/og/react-seo.jpg', width: 1200, height: 630 }],
  },
});

Validate Title Width Before It Gets Truncated in SERPs

Character count alone is unreliable because different characters have different widths. I run pixel-accurate truncation checks in CI to block deployments where auto-generated titles are too long.

import { generateSerpPreview } from '@power-seo/preview';

const serp = generateSerpPreview({
  title: 'How to Fix Every Major SEO Mistake in 2026',
  description: 'A practical guide to auditing and correcting the most damaging SEO errors.',
  url: 'https://example.com/blog/seo-mistakes',
  siteTitle: '[Power SEO](https://www.npmjs.com/org/power-seo)',
});

console.log(serp.titleTruncated); // false - safe to publish

4. Publishing Is Not the Finish Line

Something I see people forget constantly is that a page that ranked well a year ago can drop significantly if the content hasn't been refreshed, especially in fast-moving industries. Thin content is easy to publish quickly and easy to forget about afterward. Stale content signals the opposite of E-E-A-T. This is one area where AI SEO tools have genuinely changed my workflow. When I'm managing hundreds of programmatic pages, I use LLM-generated meta description suggestions reviewed before publishing to solve this at scale, so identical or near-identical descriptions never go out across hundreds of URLs.

Run a Programmatic Content Audit Before Every Publish

This runs 13 checks: keyphrase density, heading structure, word count, alt text, and link presence. Gate content publication on this in CI and you'll never ship a thin page again.

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

const output = analyzeContent({
  title: 'SEO Mistakes Every Developer Should Fix',
  metaDescription: 'A developer-focused guide to the most common SEO errors and how to fix them with code.',
  focusKeyphrase: 'seo mistakes',
  content: pageHtml,
});

console.log(output.score);    // e.g. 42
console.log(output.maxScore); // e.g. 55

const failures = output.results.filter((r) => r.status === 'poor');
failures.forEach((r) => console.error(`X ${r.description}`));

5. Duplicate Content Is Quietly Splitting Your Rankings

Same content appearing at multiple URLs, with and without trailing slashes, HTTP vs HTTPS, www vs non-www, splits ranking signals instead of consolidating them. I find this on nearly every site I audit, and it's usually been silently hurting the site for a long time. It's a particularly tricky problem for SEO for single page applications, where client-side routing can produce the same rendered content under multiple URL patterns without the developer realizing it.

Normalize Every URL Variation to One Canonical

import { resolveCanonical, validateTitle, validateMetaDescription } from '@power-seo/core';

const canonical = resolveCanonical('https://example.com', '/blog/seo-guide');
// 'https://example.com/blog/seo-guide'

const titleCheck = validateTitle('SEO Mistakes: Fixed Using the Power SEO Toolkit');
console.log(titleCheck.pixelWidth); // ~382px - well under 580px limit

const metaCheck = validateMetaDescription('Discover the most damaging SEO mistakes and how to fix them with real code examples.');
console.log(metaCheck.severity); // 'info' - passes all checks

6. Images Are Killing Your Core Web Vitals

Images are consistently among the top contributors to poor Core Web Vitals scores, and fixing them is where I usually see the most immediate performance improvement on any site. Lazy-loading a hero image delays LCP. Missing alt text hurts both accessibility and keyword relevance. Using JPEG when WebP is available inflates page weight.

Audit Alt Text, Lazy Loading, and Format in One Pass

The lazy loading audit below is CWV-aware, meaning it knows the difference between an above-fold image that should load eagerly and a below-fold one that should be lazy, which generic linters miss entirely.

import { analyzeAltText, auditLazyLoading, analyzeImageFormats } from '@power-seo/images';

const images = [
  { src: '/hero.jpg', alt: '', loading: 'lazy', isAboveFold: true, width: 1200, height: 630 },
  { src: '/product.png', alt: 'IMG_4821', loading: undefined, isAboveFold: false },
  { src: '/logo.webp', alt: 'Power SEO logo', loading: 'eager', isAboveFold: true },
];

const altResult = analyzeAltText(images, 'seo tools');
altResult.issues.forEach((i) => console.log(`[${i.severity}] ${i.message}`));

const lazyResult = auditLazyLoading(images);
// [error] /hero.jpg: Above-fold image has loading="lazy" - delays LCP

const formatResult = analyzeImageFormats(images);
console.log(`Legacy formats: ${formatResult.legacyFormatCount}/${formatResult.totalImages}`);

7. Orphan Pages Have Been Sitting There for Years

I've found orphan pages on sites that had been live for years. Pages with zero inbound links accumulate no link equity no matter how good the content is, because crawlers never reach them from the homepage. I run a link graph analysis after every content publish to make sure no new page goes live without at least one inbound internal link.

Build a Full Link Graph and Surface Orphans Automatically

import { buildLinkGraph, findOrphanPages, suggestLinks, analyzeLinkEquity } from '@power-seo/links';

const graph = buildLinkGraph([
  { url: 'https://example.com/', links: ['/blog', '/about', '/products'] },
  { url: 'https://example.com/blog', links: ['/', '/blog/post-1'] },
  { url: 'https://example.com/blog/post-1', links: ['/blog'] },
  { url: 'https://example.com/hidden-guide', links: [] }, // orphan
]);

const orphans = findOrphanPages(graph);
// [{ url: 'https://example.com/hidden-guide', outboundCount: 0 }]

const suggestions = suggestLinks(sitePages, { minRelevance: 0.2 });
suggestions.forEach(({ from, to, anchorText }) => {
  console.log(`Link from ${from} to ${to} using "${anchorText}"`);
});

8. No Structured Data Means You're Playing on Hard Mode

Missing structured data means you're competing for basic blue links only. Pages with JSON-LD unlock FAQ accordions, product star ratings, article carousels, and more. This is another spot where AI SEO tools earn their place: when you're generating schema at scale across thousands of programmatic pages, having type-safe builders with built-in validation means you're not manually reviewing every output for correctness. I validate schema in CI so invalid markup never reaches production and creates a new problem to untangle later.

Type-Safe Schema Builders With Built-In Validation

import { article, faqPage, breadcrumbList, schemaGraph, validateSchema, toJsonLdString } from '@power-seo/schema';

const graph = schemaGraph([
  article({
    headline: 'SEO Mistakes: Fixed Using the Power SEO Toolkit',
    datePublished: '2026-04-21',
    author: { name: 'Power SEO Team', url: 'https://example.com/about' },
    image: { url: 'https://example.com/og/seo-mistakes.jpg', width: 1200, height: 630 },
  }),
  faqPage([
    { question: 'What is the biggest SEO mistake?', answer: 'Ignoring technical foundations like sitemaps, canonical tags, and structured data.' },
    { question: 'How do I fix orphan pages?', answer: 'Use a link graph tool to detect pages with zero inbound links and add contextual internal links.' },
  ]),
  breadcrumbList([
    { name: 'Home', url: 'https://example.com' },
    { name: 'Blog', url: 'https://example.com/blog' },
    { name: 'SEO Mistakes' },
  ]),
]);

const validation = validateSchema(graph);
if (!validation.valid) {
  validation.issues.filter(i => i.severity === 'error').forEach(i =>
    console.error(`X [${i.field}] ${i.message}`)
  );
  process.exit(1);
}

const jsonLd = toJsonLdString(graph);

9. You're Fixing Things Without Knowing If They Work

Running audits in isolation from actual traffic data is itself a serious mistake. A page can have a perfect audit score and still get zero clicks because it ranks for keywords nobody searches. You need to correlate your audit results with real Google Search Console data to know whether any of this is actually moving the needle. This is the question every SEO practitioner asks but most AI SEO tools still can't answer well: does fixing these specific issues actually increase traffic on your specific site? The correlation step below is what closes that loop.

Correlate Audit Scores Directly With Real Traffic

import { mergeGscWithAudit, correlateScoreAndTraffic, buildDashboardData } from '@power-seo/analytics';

const dashboard = buildDashboardData({
  gscPages: [
    { url: '/blog/seo-mistakes', clicks: 1240, impressions: 18500, ctr: 0.067, position: 4.2 },
    { url: '/blog/meta-tags', clicks: 380, impressions: 9200, ctr: 0.041, position: 8.7 },
  ],
  auditResults: [
    { url: '/blog/seo-mistakes', score: 88, issues: [] },
    { url: '/blog/meta-tags', score: 44, issues: [] },
  ],
});

const insights = mergeGscWithAudit(dashboard.gscPages, dashboard.auditResults);
const correlation = correlateScoreAndTraffic(insights);
console.log(`Correlation: ${correlation.correlation.toFixed(3)}`); // e.g. 0.741

Start Here

SEO mistakes accumulate quietly. The compounding effect is real, and by the time you notice it it's hard to undo. Whether you're dealing with SEO for single page applications, a large content site, or a headless CMS setup, the fixes are the same: checks you write once, run in CI, and enforce automatically going forward. Start with @[power-seo/audit] for a baseline, fix meta tags, add structured data, resolve orphan pages, optimize images, handle duplicate content, then measure. Build the safety net and let it run.

npm install @power-seo/audit @power-seo/schema @power-seo/links @power-seo/images

How I Stopped Paying for AI SEO Tools and Built My Own LLM Workflow

Mitu Das — Sat, 25 Apr 2026 05:22:38 +0000

AI SEO tools are everywhere right now. But for most developers, they’re actually unnecessary overhead.

I spent months paying for tools that claimed to automate SEO. In reality, they were just clean dashboards wrapped around the same LLM APIs I already had access to.

Paste content. Generate meta description. Hit a paywall.

At some point, it stopped making sense.

So instead of paying for another SaaS, I built my own AI SEO workflow where I control the prompts, the models, and the output.

This guide walks through exactly how that works.

The Real Problem With Most AI SEO Tools

Most AI SEO platforms don’t solve a deep technical problem. They solve a UX problem.

Under the hood, they rely on standard LLM APIs. The “AI” is usually just structured prompts that generate:

Meta descriptions
SEO titles
Basic content suggestions

That abstraction creates a hidden issue.

When you rely on a dashboard, you stop validating outputs.

That’s how common SEO mistakes happen:

Meta descriptions too long or too short
Titles that get truncated in SERPs
Missing or invalid structured data
No validation for rich result eligibility

As developers, we don’t need another UI layer.

We need reusable, testable logic.

The Shift: Bring Your Own LLM

Instead of using a closed platform, the better approach is simple:

Use your own LLM (OpenAI, Claude, Gemini, local models)
Control prompt structure
Parse responses into structured data
Integrate directly into your pipeline

This gives you:

Full control
Lower cost
Deterministic workflows
Easy experimentation across models

Example: Generating Meta Descriptions Programmatically

Here’s a simplified version of how this works in practice:

import { buildMetaDescriptionPrompt, parseMetaDescriptionResponse } from '@power-seo/ai';

const prompt = buildMetaDescriptionPrompt({
  title: 'Best Coffee Shops in New York City',
  content: 'Explore the top coffee spots in NYC...',
  focusKeyphrase: 'coffee shops nyc',
});

const raw = await yourLLM.complete(prompt.system, prompt.user, prompt.maxTokens);

const result = parseMetaDescriptionResponse(raw);

console.log(result.description);
console.log(result.charCount);
console.log(result.pixelWidth);
console.log(result.isValid);

Instead of guessing SEO quality, you now have:

Character validation
Pixel width estimation
Structured output

That’s something most SaaS tools don’t expose.

What Your Workflow Should Handle

A solid AI SEO pipeline should cover four core areas:

1. Meta Description Optimization

Generate descriptions within the 120–158 character range with keyphrase alignment.

2. SEO Title Variations

Create multiple title options with length validation for better CTR testing.

3. Content Improvement Suggestions

Structured recommendations instead of vague advice:

Heading improvements
Keyword placement
Internal linking gaps

4. SERP Feature Readiness

This is where most tools fall short.

The Missing Piece: Deterministic SEO Checks

Most AI SEO tools use LLMs to “predict” rich results.

That approach is:

Slow
Costly
Non-deterministic

A better approach is rule-based validation.

Example:

import { analyzeSerpEligibility } from '@power-seo/ai';

const result = analyzeSerpEligibility({
  title: 'How to Install Node.js on Ubuntu',
  content: '<h2>Step 1</h2><p>...</p>',
  schema: ['HowTo'],
});

This lets you validate:

FAQ eligibility
HowTo structure
Article schema quality

Because it’s deterministic, you can:

Run it in CI
Fail builds on SEO issues
Prevent regressions

That’s a completely different level of control.

Why This Approach Scales Better

When you own the pipeline:

You’re not locked into a platform
You can test multiple LLMs easily
You can optimize prompts over time
You reduce long-term cost significantly

For programmatic SEO or large content systems, this matters a lot.

SPA SEO Use Case (Important)

Single Page Applications often struggle with SEO because:

Content is rendered client-side
Crawlers may miss important data
Metadata is often incomplete

With a custom AI SEO workflow, you can:

Generate metadata at build time
Inject structured data server-side
Validate SEO before deployment

This ensures your content is ready before it reaches search engines.

When You Still Need SEO Tools

To be clear, not everything should be replaced.

You still need tools for:

Keyword research
Backlink analysis
Site crawling

But for AI content generation?

You don’t need to pay for a wrapper.

Final Thoughts

Most AI SEO tools sell convenience, not capability.

As a developer, you already have access to the most powerful part: the LLM.

Once you take control of the prompts and outputs, you can build a workflow that is:

free
More flexible
More reliable

And most importantly, fully yours.

React Developer Tools for SEO: Stack That Actually Gets Indexed

Mitu Das — Thu, 23 Apr 2026 11:31:53 +0000

You launched a beautiful React app. Smooth transitions, snappy UX, buttery animations. Then Google Search Console showed up and handed you a reality check impressions tanking, pages missing from the index, rankings nowhere in sight.

Welcome to the most under-discussed problem in frontend development: building for users, but forgetting about crawlers.

Everything looks perfect in your browser. Your components hydrate flawlessly, state flows like poetry, and your performance scores are solid. You even double-checked things with react developer tools, making sure props and renders behave exactly as expected.

But search engines? They’re not impressed.

Because while you're thinking in components, hooks, and client-side rendering, search bots are struggling to see anything at all.*

Welcome to the most under-discussed problem in frontend development.

The Uncomfortable Truth About React and Search Engines

Here is what nobody tells you when you pick up React for your next content-heavy project:

React ships an empty box.

When Googlebot visits your shiny SPA, it sees something like this:

<div id="root"></div>
<script src="/static/js/main.chunk.js"></script>

That's it. Your carefully crafted blog posts, product pages, and landing copy? They live inside that JavaScript bundle and Googlebot has to execute it, render the DOM, then read your content. Sometimes it does. Often, it doesn't. And when your crawl budget runs out, the pages that don't get rendered don't get indexed.

This is not a React bug. It is an architectural mismatch between how React works and what search engines expect. And the fix is not a single library it is a systematic, layered stack of React developer tools for SEO that closes each gap deliberately.

Let me walk you through exactly that stack.

What You Are Actually Dealing With (Layer by Layer)

Before jumping to code, understand the three layers where SEO breaks in React:

Layer 1 The Meta Layer
Missing or identical <title>, <meta description>, <canonical>, and Open Graph tags across routes. This is what kills your click-through rate and confuses Googlebot about page identity.

Layer 2 The Schema Layer
No JSON-LD structured data means you are never eligible for FAQ rich results, breadcrumbs, article markup, or product snippets. You are leaving SERP real estate on the table.

Layer 3 The Technical Layer
No XML sitemap. No internal link graph audit. No automated performance tracking. Pages get added to your CMS and never discovered because no crawler can find them.

Each layer needs its own tool. Let's go through them.

Layer 1: Meta Tags The Foundation

For Next.js (App Router)

Next.js gives you the generateMetadata API, and pairing it with @power-seo/meta gives you type-safe, server-rendered head tags that Googlebot reads in the first HTTP response no JavaScript execution required.

// app/blog/[slug]/page.tsx
import { createMetadata } from '@power-seo/meta';

export async function generateMetadata({ params }) {
  const post = await getPost(params.slug);
  return createMetadata({
    title: post.title,
    description: post.excerpt,
    canonical: `https://example.com/blog/${params.slug}`,
    robots: { index: true, follow: true, maxSnippet: 160, maxImagePreview: 'large' },
  });
}

This outputs real HTML in your initial response. Not hydrated after mount. Not deferred. Actually there when the crawler arrives.

For React + Vite (No Next.js)

Set site-wide defaults once at the app root:

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

function App({ children }) {
  return (
    <DefaultSEO
      titleTemplate="%s | Your Brand"
      defaultTitle="Your Brand"
      description="Your default site description here."
      openGraph={{
        type: 'website',
        siteName: 'Your Brand',
        images: [{ url: 'https://example.com/og-default.jpg', width: 1200, height: 630 }],
      }}
      twitter={{ site: '@yourbrand', cardType: 'summary_large_image' }}
      robots={{ index: true, follow: true }}
    >
      {children}
    </DefaultSEO>
  );
}

Then override per-route. Every route component declares its own head. No exceptions.

The most common SEO mistake in React apps: All pages share one <title> tag. Googlebot sees every page as the same document. Entire site gets de-prioritized.

Layer 2: Structured Data The Rich Result Unlock

This is where most React developers stop they get meta tags working and call it done. But structured data is one of the highest-ROI moves you can make, and almost nobody does it in React apps.

JSON-LD schema markup qualifies your pages for:

FAQ accordion rich results
Breadcrumb trails in SERPs
Article enhanced display
Product rich results with prices and ratings

Here is how to implement it correctly using @power-seo/schema:

import { FAQJsonLd, BreadcrumbJsonLd } from '@power-seo/schema/react';

function BlogPost({ post }) {
  return (
    <>
      <BreadcrumbJsonLd
        items={[
          { name: 'Home', url: 'https://example.com' },
          { name: 'Blog', url: 'https://example.com/blog' },
          { name: post.title },
        ]}
      />
      {post.faqItems && <FAQJsonLd questions={post.faqItems} />}
      <article>{/* content */}</article>
    </>
  );
}

And for article pages specifically:

import { article, toJsonLdString } from '@power-seo/schema';

export default function BlogPost({ post }) {
  const schema = article({
    headline: post.title,
    description: post.excerpt,
    datePublished: post.publishedAt,
    dateModified: post.updatedAt,
    author: { name: post.author.name, url: post.author.url },
    image: { url: post.coverImage, width: 1200, height: 630 },
  });

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

Note: toJsonLdString() handles XSS escaping automatically. You don't need to sanitize separately.

Layer 3: Technical SEO Sitemaps and Link Graphs

Dynamic Sitemaps for SPAs

Your React Router links are JavaScript. Crawlers that follow HTML links will miss them. You need an XML sitemap served as a real HTTP endpoint.

// app/sitemap.xml/route.ts (Next.js App Router)
import { generateSitemap } from '@power-seo/sitemap';

export async function GET() {
  const urls = await fetchAllPagesFromCMS();
  const xml = generateSitemap({
    hostname: 'https://example.com',
    urls,
  });
  return new Response(xml, {
    headers: { 'Content-Type': 'application/xml' },
  });
}

For sites exceeding 50,000 URLs, splitSitemap() auto-chunks into an index file. Google's limit is 50,000 URLs per sitemap file this handles that automatically.

Finding Orphan Pages Before Google Does

New pages get added to your CMS. Nobody links to them. They never get indexed. This silent failure is brutally common in content-heavy React apps.

import { buildLinkGraph, findOrphanPages } from '@power-seo/links';

const graph = buildLinkGraph(sitePages);
const orphans = findOrphanPages(graph);
// Returns pages with zero inbound internal links

Run this in CI. Alert when orphan count exceeds a threshold. Use suggestLinks() to get keyword-overlap-based recommendations for which existing pages should link to the orphaned content.

The CI Gate: Making SEO Regression-Proof

This is the step that separates teams that maintain good SEO from teams that fix it, then watch it degrade over three months.

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

const report = auditSite({ pages: testPages });

if (report.score < 75 || report.pageResults.flatMap(p => p.rules.filter(r => r.severity === 'error')).length > 0) {
  console.error(`SEO audit FAILED: score ${report.score}`);
  process.exit(1);
}

console.log(`SEO audit PASSED: score ${report.score}/100`);

Add this to your GitHub Actions or CI pipeline. Every PR either passes or fails SEO checks. No more "we'll fix it later" later never comes.

Image Auditing for Core Web Vitals

Poor Core Web Vitals drag down rankings even when your content and meta tags are perfect. Images are usually the culprit.

import { analyzeAltText, auditLazyLoading, analyzeImageFormats } from '@power-seo/images';

const lazyResult = auditLazyLoading(images);
// Flags: hero images with loading="lazy" (LCP risk)
// Flags: below-fold images missing loading="lazy" (bandwidth waste)
// Flags: images without width/height (CLS risk)

Common offenders this catches:

Hero images with loading="lazy" delays Largest Contentful Paint
Images without explicit width and height causes Cumulative Layout Shift
No alt text accessibility and indexing signal loss

What Timeline to Expect (Honestly)

Weeks 2–4: After adding server-side meta tags and canonical URLs, previously missing pages start appearing in Google Search Console as indexed. The crawl starts finding content.

Weeks 4–8: After adding JSON-LD structured data, eligible pages start showing breadcrumbs and FAQ accordions in search results. Click-through rate improves without a change in position.

Content audit cycles: Flagging thin content and poor heading structures with @power-seo/content-analysis produces ranking movement that correlates with audit score improvements.

The @power-seo/analytics package computes a Pearson correlation between your audit score trends and Google Search Console click data. Actual data. Not gut feelings.

Quick Reference: Problem → Tool

Problem	Tool
Pages not indexed	`@power-seo/meta` + Next.js `generateMetadata`
Duplicate or missing canonicals	`Canonical` component from `@power-seo/react`
No rich results	`@power-seo/schema` (FAQJsonLd, BreadcrumbJsonLd, article)
Poor Core Web Vitals	`@power-seo/images` audit in CI
No XML sitemap	`@power-seo/sitemap` with `generateSitemap()`
Orphan pages	`@power-seo/links` with `findOrphanPages()`
SEO regressions in production	`@power-seo/audit` as a CI gate

The Minimum Viable Setup (Start Here)

If your React app has zero SEO infrastructure right now, do these three things in order:

Install and configure a meta layer @power-seo/meta or react-helmet-async. Every route needs its own title, description, and canonical.
Generate and submit an XML sitemap Use @power-seo/sitemap, submit to Google Search Console. Do this before anything else because Google needs to find your pages before it can rank them.
Add at least one JSON-LD schema Article, FAQ, or Breadcrumb. Pick whichever matches your content type. This unlocks rich result eligibility that competitors without schema markup don't have.

Everything else image audits, link graphs, CI gates, analytics correlation adds to this foundation.

Final Thought

React's rendering model creates real SEO friction. That friction is not a deal-breaker it is an engineering problem with engineering solutions. The teams that win in organic search with React apps aren't doing anything magical. They are being systematic: server-render the metadata, mark up the schema, maintain the sitemap, and catch regressions before they ship.

Big SEO Mistakes Developers Make

Mitu Das — Wed, 22 Apr 2026 09:22:33 +0000

I spent 3 hours debugging why Google couldn’t index my Next.js app. Lighthouse was green. The site was fast. The content was solid. Yet the problem came down to a series of hidden SEO mistakes that silently blocked my visibility.

Turns out my sitemap was malformed, my canonical tags were inconsistent across environments, and half my pages were orphaned with no internal links pointing to them at all. Three separate problems, each invisible without the right tooling, and together they made my entire site essentially invisible to search engines.

These are the kinds of big SEO mistakes that don’t show up in performance scores or UI checks but have a massive impact on rankings and indexing. This article shows you exactly how to find and fix these issues with real, copy-paste-ready code so your site doesn’t suffer the same fate.

Mistake #1: Your Sitemap Is Either Missing or Lying to Google

A missing or malformed XML sitemap is the silent killer of organic traffic. Googlebot literally can't find what you don't tell it about. But the subtler version of this problem is a sitemap that exists but is stale, missing pages, or over the 50,000-URL limit with no index file.

Here's the manual approach most developers take, and why it breaks:

// ❌ The typical DIY approach
const xml = `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  ${pages.map(p => `<url><loc>${p.url}</loc></url>`).join('')}
</urlset>`;

This works until you have 50,001 URLs, forget to encode special characters, or need to split into a sitemap index. Then it quietly breaks.

The fix is to generate it programmatically from a single source of truth:

import { generateSitemap, splitSitemap } from '@power-seo/sitemap';

const xml = generateSitemap({
  hostname: 'https://yoursite.com',
  urls: [
    { loc: '/', lastmod: '2026-01-01', changefreq: 'daily', priority: 1.0 },
    { loc: '/blog/react-seo', lastmod: '2026-04-01', priority: 0.8 },
    { loc: '/products/widget', changefreq: 'weekly', priority: 0.7 },
  ],
});

// For large sites: auto-chunks at 50k URLs, generates sitemap index
const { index, sitemaps } = splitSitemap(allUrls, 'https://yoursite.com');

The result: a spec-compliant sitemap that handles edge cases automatically, including chunking, encoding, and index file generation. Run this in CI on every deploy.

Mistake #2: Redirect Chains Are Bleeding Your Link Equity

Every time you migrate a site and add redirects in three different places (your framework config, your CDN, and a CMS plugin), you create chains. A chain like /old → /interim → /final passes less link equity than a direct 301 and is harder to audit. This compounds during every site migration.

The real problem: there's no single source of truth for your redirect rules.

import { createRedirectEngine } from '@power-seo/redirects';

const engine = createRedirectEngine({
  rules: [
    { source: '/old-about', destination: '/about', statusCode: 301 },
    { source: '/blog/:slug', destination: '/articles/:slug', statusCode: 301 },
  ],
});

// Test this in CI before any deploy
const match = engine.match('/blog/my-post');
// → { resolvedDestination: '/articles/my-post', statusCode: 301 }

// Export to whatever framework you're using
const nextRedirects = engine.toNextRedirects();      // next.config.js
const remixHandler = engine.createRemixHandler();    // Remix
const expressMiddleware = engine.createExpressMiddleware(); // Express

Define once, deploy everywhere. No more "I added it to Cloudflare but forgot to update next.config.js."

Mistake #3: Orphan Pages, Content That Google Can Never Discover

This one caught me off guard the first time I encountered it at scale. An orphan page is a page with no internal links pointing to it. It exists in your database, it might even have a URL in your sitemap, but because no other page on your site links to it, crawlers never encounter it organically.

The fix requires building a proper link graph:

import { buildLinkGraph, findOrphanPages, suggestLinks } from '@power-seo/links';

const graph = buildLinkGraph([
  { url: 'https://yoursite.com/', links: ['/blog', '/about', '/products'] },
  { url: 'https://yoursite.com/blog', links: ['/', '/blog/post-1'] },
  { url: 'https://yoursite.com/blog/post-1', links: ['/blog'] },
  { url: 'https://yoursite.com/hidden-guide', links: [] }, // 👻 orphan
]);

const orphans = findOrphanPages(graph);
// [{ url: 'https://yoursite.com/hidden-guide', outboundCount: 0 }]

// Get keyword-overlap-based suggestions for where to add internal links
const suggestions = suggestLinks(sitePages, { minRelevance: 0.2 });
suggestions.forEach(({ from, to, anchorText }) =>
  console.log(`Add link from ${from} → ${to} with anchor: "${anchorText}"`)
);

I now run this after every content publish in our headless CMS pipeline. If a new page goes live without at least one inbound internal link, the CI check fails.

Mistake #4: Your Content Scores Are Invisible Until Someone Complains

The most insidious SEO mistakes are the ones you can't see without deliberately looking: meta descriptions missing keywords, titles that truncate in SERPs, images with no alt text, heading structures that skip from H1 to H4. WordPress developers have Yoast. Developers building custom stacks have... nothing, unless they build it.

Here's a CI-ready content audit you can plug into any pipeline:

import { analyzeContent } from '@power-seo/content-analysis';
import { analyzeAltText, auditLazyLoading } from '@power-seo/images';
import { generateSerpPreview } from '@power-seo/preview';

// Content quality check: 13 automated rules
const audit = analyzeContent({
  title: 'React SEO Best Practices: 2026 Guide',
  metaDescription: 'Learn common SEO mistakes in React apps and how to fix them.',
  focusKeyphrase: 'react seo',
  content: pageHtml,
});

console.log(`Score: ${audit.score}/${audit.maxScore}`);
audit.results
  .filter(r => r.status === 'poor')
  .forEach(r => console.error(`✗ ${r.description}`));

// SERP title truncation check (pixel-accurate, not character count)
const serp = generateSerpPreview({
  title: 'How to Fix Every Major SEO Mistake in 2026',
  description: 'A practical guide to auditing and correcting common SEO errors.',
  url: 'https://yoursite.com/blog/seo-mistakes',
});
console.log(`Title truncated: ${serp.titleTruncated}`); // false = safe to publish

// Image SEO audit
const altResult = analyzeAltText(images, 'react seo');
const lazyResult = auditLazyLoading(images);
// Flags hero images incorrectly marked loading="lazy" - LCP regression risk

The SERP preview check is particularly useful for programmatically generated pages where titles are assembled from templates. It uses pixel-width measurement, not character count, because "WWW" is wider than "iii" even at the same length.

What I Learned

Technical SEO is infrastructure. Fixing content before your crawlability is sorted is like painting a house with a broken foundation. Start with sitemaps and redirects.
Orphan pages are invisible by definition. You have to build the link graph explicitly to see them; manual spot-checking doesn't scale.
CI checks prevent regressions. The biggest win isn't fixing these mistakes once; it's making it impossible to re-introduce them on every deploy.
Pixel-accurate SERP validation matters more than character limits. Title truncation based on character count is wrong. Build around display width.

These aren't abstract best practices. Every single check above is something I've run in a production pipeline. The underlying approach works regardless of what tooling you use; the patterns (link graph analysis, content scoring, SERP preview validation) are what matter.

If you want to explore the specific implementation used in these examples, the full toolkit is open source: https://github.com/CyberCraftBD/power-seo.
The original deep-dive article with all 10 mistake categories is also up on ccbd.dev if you want the full treatment.

What's your biggest SEO headache?

Drop it in the comments. I'm curious whether the issues developers actually run into match what I've documented here. If you've got a creative solution to any of these problems that doesn't involve yet another npm package, I genuinely want to hear it. And if you've been burned by a specific SEO mistake that took you embarrassingly long to diagnose, you're in good company.

How I Used JavaScript to Automate SEO Tasks

Mitu Das — Tue, 21 Apr 2026 10:22:03 +0000

I will be honest with you. For the longest time, meta descriptions were the last thing I wrote before publishing. Sometimes I skipped them entirely. Not because I didn’t care about SEO, but because writing 150 characters of optimized copy for every single page felt like a tax on shipping and honestly, one of those common SEO mistakes that quietly adds up when you’re focused on moving fast.

Then I started thinking about it differently. The rules for a good meta description do not change. Include the focus keyphrase. Stay under 158 characters. End with something that makes someone want to click. That is a spec, not creative writing. And if something has a spec, you can automate it.

So I did. Here is exactly how I used JavaScript to automate SEO across my content pipeline, what I learned, and the specific library that made it provider-agnostic from day one.

Why I Wanted to Automate This in JavaScript Specifically

I considered Python. Most SEO tooling lives there. But my content pipeline was already Node.js. My CMS hooks were JavaScript. My CI scripts were JavaScript. Adding a Python subprocess just to generate a meta description felt like the wrong tradeoff.

What I actually needed was a library that would let me build prompts for any LLM I wanted to use, parse the responses into structured data, and drop the whole thing into my existing Node.js workflow without pulling in a new runtime or a heavyweight SDK.

That is what led me to @[power-seo/ai]. It does exactly one thing: gives you prompt builders that return plain objects and response parsers that accept raw strings. No bundled SDK. No opinions about which model you use. Just JavaScript functions.

The First Thing I Automated: Meta Descriptions

I started here because the pain was most obvious. My site had hundreds of pages with either missing or weak meta descriptions. Fixing them manually would have taken weeks.

Here is the code I wrote:

import { buildMetaDescriptionPrompt, parseMetaDescriptionResponse } from '@power-seo/ai';
import Anthropic from '@anthropic-ai/sdk';

const anthropic = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY });

async function generateMetaDescription(title: string, content: string, keyphrase: string) {
  const prompt = buildMetaDescriptionPrompt({
    title,
    content,
    focusKeyphrase: keyphrase,
  });

  const response = await anthropic.messages.create({
    model: 'claude-opus-4-6',
    system: prompt.system,
    messages: [{ role: 'user', content: prompt.user }],
    max_tokens: prompt.maxTokens,
  });

  const raw = response.content[0].type === 'text' ? response.content[0].text : '';
  return parseMetaDescriptionResponse(raw);
}

const result = await generateMetaDescription(
  'How to Choose a Standing Desk',
  'Full article content here...',
  'standing desk buying guide'
);

console.log(result.description);   // the generated text
console.log(result.charCount);     // e.g. 146
console.log(result.pixelWidth);    // e.g. 874
console.log(result.isValid);       // true

Two things surprised me when I first saw the output. First, the charCount field. I expected that. Second, the pixelWidth field. I had not thought about pixel width before, but it matters more than character count for predicting SERP truncation. Google cuts off at roughly 920px on desktop, not at a fixed character count. An "i" and a "W" are not the same width. The parser estimates rendered width so you can catch truncation before it happens.

I ran this across 200 pages in a weekend. Would have taken me two weeks manually.

Then I Tackled Title Tags

My title tags were inconsistent. Some were too long. Some were missing the keyphrase. Some were just the page name with nothing else.

buildTitlePrompt fixed this by generating five variants per page, each targeting a different angle:

import { buildTitlePrompt, parseTitleResponse } from '@power-seo/ai';

const prompt = buildTitlePrompt({
  content: 'Article about the best noise-cancelling headphones under $100...',
  focusKeyphrase: 'noise cancelling headphones under 100',
  tone: 'informative',
});

const raw = await yourLLMClient.complete(prompt.system, prompt.user, prompt.maxTokens);
const titles = parseTitleResponse(raw);

titles.forEach(({ title, charCount, pixelWidth }) => {
  const status = charCount <= 60 ? 'OK' : 'TOO LONG';
  console.log(`[${status}] "${title}" — ${charCount} chars`);
});

Getting five variants back instead of one changed my workflow. I stopped thinking of the AI as a replacement for my judgment and started treating it as a first draft machine. I pick the best variant, sometimes edit it slightly, and move on. The whole process takes ten seconds per page instead of five minutes. This is basically how an AI SEO tool shifts content work from writing to selection and refinement.

The Part I Did Not Expect to Use: Content Suggestions

I added buildContentSuggestionsPrompt almost as an afterthought. I thought it would give me vague advice I already knew.

It did not. It gave me typed, prioritized recommendations across four specific categories: heading structure, paragraph content, keyword placement, and internal linking. Each one came with a priority score.

import { buildContentSuggestionsPrompt, parseContentSuggestionsResponse } from '@power-seo/ai';

const prompt = buildContentSuggestionsPrompt({
  title: 'How to Build a Morning Routine',
  content: pageContent,
  focusKeyphrase: 'morning routine tips',
  analysisResults: 'Current SEO score: 54/100. Thin content on mobile section.',
});

const raw = await yourLLMClient.complete(prompt.system, prompt.user, prompt.maxTokens);
const suggestions = parseContentSuggestionsResponse(raw);

suggestions
  .sort((a, b) => b.priority - a.priority)
  .forEach(({ type, suggestion, priority }) => {
    console.log(`[Priority ${priority}] ${type}: ${suggestion}`);
  });

What I do now is run this against every page that drops in organic traffic. The output becomes a ticket in my content queue. The writer who picks it up knows exactly what to fix and in what order. No editorial meeting needed to figure out why a page is underperforming.

The CI Check That Saved Me Twice

This is the feature I recommend most strongly to other developers. analyzeSerpEligibility is completely deterministic. No LLM. No API call. No cost. It just inspects your schema markup and heading structure and tells you whether your page qualifies for FAQ, HowTo, Product, and Article rich results.

I added it to my deploy pipeline:

import { analyzeSerpEligibility } from '@power-seo/ai';

function checkSerpEligibility(page: { title: string; content: string; schema: string[] }) {
  const results = analyzeSerpEligibility(page);

  const failed = results.filter(r => r.likelihood < 0.5);

  if (failed.length > 0) {
    console.error('SERP eligibility check failed:');
    failed.forEach(({ feature, requirements, met }) => {
      const missing = requirements.filter(r => !met.includes(r));
      console.error(`  ${feature}: missing ${missing.join(', ')}`);
    });
    process.exit(1);
  }
}

It has caught two real regressions. Once when a CMS template change stripped the HowTo schema from a category of pages. Once when a developer refactored the FAQ component and the structured data stopped rendering. Both would have quietly dropped rich results for high-traffic pages. Neither made it to production.

Switching From Claude to OpenAI for One Project

One thing I want to be specific about because I think it matters: when a client asked me to use OpenAI instead of Claude for their pipeline, I changed exactly three lines of code. The prompt builders and parsers stayed identical.

// Before: Anthropic Claude
const response = await anthropic.messages.create({
  model: 'claude-opus-4-6',
  system: prompt.system,
  messages: [{ role: 'user', content: prompt.user }],
  max_tokens: prompt.maxTokens,
});
const raw = response.content[0].type === 'text' ? response.content[0].text : '';

// After: OpenAI
const response = await openai.chat.completions.create({
  model: 'gpt-4o',
  messages: [
    { role: 'system', content: prompt.system },
    { role: 'user', content: prompt.user },
  ],
  max_tokens: prompt.maxTokens,
});
const raw = response.choices[0].message.content ?? '';

// parseMetaDescriptionResponse(raw) — unchanged in both cases

That is the whole migration. If you have ever switched LLM providers and had to rewrite your prompt templates from scratch, you will understand why this matters.

What I Would Do Differently

If I were starting this over, I would add analyzeSerpEligibility to CI on day one instead of week four. The LLM-powered features are valuable but they are async and cost money to run at scale. The deterministic eligibility check is free and instant and belongs in every deploy pipeline.

I would also run buildTitlePrompt before publishing instead of after. Fixing title tags retroactively across hundreds of pages is much less pleasant than getting five good options before you hit publish.

Installation

npm install @power-seo/ai

Zero runtime dependencies. Works in Node.js, Next.js, Remix, Vite, Cloudflare Workers, and Vercel Edge. Dual ESM and CJS so it drops into any project without bundler configuration.

Final Thought

Using JavaScript to automate SEO is not about removing human judgment from content. It is about removing the mechanical parts so human judgment can focus on what actually matters. Picking the right angle for a title. Deciding what a piece of content is really about. Building something worth linking to.

The spec work, the character counting, the schema validation, the gap analysis, that is what @power-seo/ai handles. The rest is still yours.

SEO Optimization Checklist: Complete Guide For Developer

Mitu Das — Mon, 13 Apr 2026 05:51:20 +0000

If you’ve ever built a fast, modern React application only to realize it gets almost no organic traffic, you’re not alone. In 2026, this is still one of the most common frustrations among developers.

You ship a beautiful UI, optimized performance, smooth animations… but search engines see something very different: incomplete metadata, weak structure, and JavaScript-heavy pages that are not fully understood at crawl time.

That’s exactly why a structured SEO optimization checklist is no longer optional—it’s a core part of modern web development.

This guide breaks down a practical, production-ready SEO optimization checklist specifically designed for modern JavaScript apps (React, Next.js-style SPAs, and hybrid apps). You’ll also see real code patterns you can implement immediately.

Why You Need an SEO Optimization Checklist in 2026

Search engines have improved significantly, but they still don’t treat JavaScript apps the same as static HTML pages.

Even though modern crawlers can render JavaScript, there are still delays in:

Indexing dynamic routes
Reading client-rendered metadata
Understanding deeply nested components
Processing content that loads after hydration

This leads to a simple reality:

If your SEO is not explicitly structured, your content is not guaranteed to be indexed correctly.

A proper SEO optimization checklist ensures:

Every route is discoverable
Every page has unique metadata
Content is machine-readable
Structured data is present
Images and performance signals are optimized

Full SEO Optimization Checklist (2026 Edition)

Let’s break down the checklist into 5 essential pillars, using a power SEO free tool to improve structure, clarity, optimization, and overall content performance effectively for better rankings and visibility.

1. Metadata Optimization (Titles, Descriptions, Canonicals)

Metadata is the first thing search engines evaluate. If it’s missing or duplicated, your rankings suffer immediately.

SEO Optimization Checklist Rules:

Every route must have a unique title
Every page must have a meta description
Canonical URLs must be defined
Open Graph tags must exist
Twitter cards must be configured

React Implementation Example

Instead of manually editing document.title or using scattered useEffect logic, use a structured metadata generator.

import { createMetadata } from '@power-seo/meta';

export const metadata = createMetadata({
  title: 'SEO Optimization Checklist for Developers',
  description: 'A complete guide to technical SEO optimization for modern web apps.',
  canonical: 'https://example.com/seo-checklist',
  robots: {
    index: true,
    follow: true,
    maxSnippet: 160,
  },
  openGraph: {
    type: 'article',
    images: [
      {
        url: 'https://example.com/seo-cover.jpg',
      },
    ],
  },
});

Why this matters:

Prevents duplicate content issues
Ensures correct SERP display
Improves social sharing previews

2. Structured Data (JSON-LD Schema)

If metadata is the “front door” of SEO, structured data is the “translator.”

It tells search engines exactly what your content means.

SEO Optimization Checklist for Schema:

Add Article schema for blogs
Add Product schema for ecommerce
Add FAQ schema for Q&A content
Include author and publishing details
Ensure JSON-LD is valid and consistent

Code Example: Article Schema

import { article, toJsonLdString } from '@power-seo/schema';

const schema = article({
  headline: 'SEO Optimization Checklist Guide',
  description: 'Learn how to optimize modern web apps for search engines.',
  datePublished: '2026-04-01',
  dateModified: '2026-04-10',
  author: {
    name: 'Content Team',
    url: 'https://example.com/authors/team',
  },
  image: {
    url: 'https://example.com/seo-cover.jpg',
    width: 1200,
    height: 630,
  },
});

const jsonLd = toJsonLdString(schema);

Then inject it:

<script type="application/ld+json">
  {/* jsonLd output */}
</script>

3. Content Quality & On-Page Analysis

Even perfect metadata won’t save weak content. That’s why your SEO optimization checklist must include content auditing.

Checklist for Content SEO:

Clear H1 structure
Proper heading hierarchy (H1 → H2 → H3)
Keyword naturally included
No thin or duplicate content
Readability above average
Internal linking included

Automated Content Audit Example

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

const result = analyzeContent({
  title: 'SEO Optimization Checklist Guide',
  metaDescription: 'Learn SEO optimization for modern apps',
  focusKeyphrase: 'SEO optimization checklist',
  content: `
    <h1>SEO Optimization Checklist</h1>
    <p>This guide explains modern SEO practices...</p>
  `,
});

console.log(result.score);
console.log(result.results);

What this helps with:

Real-time SEO scoring
Detecting missing keywords
Fixing heading structure issues
Improving publish quality gates

4. Sitemap & Crawl Discovery

Even perfect SEO content is useless if search engines cannot discover it.

Your SEO optimization checklist must ensure every page is reachable.

Checklist:

Generate XML sitemap dynamically
Include all important routes
Update lastmod timestamps
Prioritize high-value pages
Exclude private or admin routes

Sitemap Generation Example

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

const sitemap = generateSitemap({
  hostname: 'https://example.com',
  urls: [
    { loc: '/', priority: 1.0, changefreq: 'daily' },
    { loc: '/blog', priority: 0.8, changefreq: 'weekly' },
    { loc: '/blog/seo-guide', priority: 0.7 },
  ],
});

Why this matters:

Helps crawlers find new pages faster
Prevents orphan pages
Improves indexing consistency

5. Image SEO & Performance Optimization

Images are often the biggest performance bottleneck in modern web apps.

They also represent a major SEO opportunity (especially Google Images).

SEO Optimization Checklist for Images:

Always include alt text
Avoid missing or generic filenames as alt
Use modern formats (WebP, AVIF)
Lazy-load below-the-fold images
Avoid oversized images above fold

Image Audit Example

import {
  analyzeAltText,
  auditLazyLoading,
  analyzeImageFormats,
} from '@power-seo/images';

const images = [
  {
    src: '/hero.jpg',
    alt: '',
    loading: 'lazy',
    isAboveFold: true,
    width: 1200,
    height: 630,
  },
];

const altIssues = analyzeAltText(images, 'SEO checklist');
const lazyIssues = auditLazyLoading(images);
const formatIssues = analyzeImageFormats(images);

console.log(altIssues, lazyIssues, formatIssues);

6. Unified SEO Architecture for React Apps

One of the biggest problems in modern SPAs is scattered SEO logic.

Different developers:

Set meta tags manually
Forget canonical URLs
Duplicate schema logic
Miss image optimization rules

A unified system fixes this.

Example: Core SEO Engine Wrapper

import {
  buildMetaTags,
  buildLinkTags,
  resolveCanonical,
  validateTitle,
} from '@power-seo/core';

const meta = buildMetaTags({
  description: 'Complete SEO optimization checklist guide',
  openGraph: {
    title: 'SEO Checklist',
    type: 'article',
  },
  twitter: {
    cardType: 'summary_large_image',
  },
});

const links = buildLinkTags({
  canonical: resolveCanonical('https://example.com', '/seo-checklist'),
});

const check = validateTitle('SEO Optimization Checklist Guide');

Common SEO Mistakes Developers Still Make

Even experienced developers repeat these issues:

1. Client-side only metadata

If metadata is injected after hydration, crawlers may miss it.

2. Missing canonical tags

This leads to duplicate content confusion.

3. Broken Open Graph images

Relative URLs break social previews.

4. Keyword stuffing

Overusing keywords hurts rankings instead of helping.

5. No structured sitemap

Pages become invisible to crawlers.

Advanced SEO Optimization Checklist Strategy

If you want to go beyond basics, focus on:

Core Web Vitals

LCP optimization
CLS reduction
FID improvements

Semantic SEO

Context-based content
Topic clusters
Internal linking strategy

Crawl efficiency

Reduce unnecessary pages
Improve load performance
Avoid duplicate routes

Quarterly SEO Optimization Checklist Review

SEO is not a one-time task. You should regularly review:

Metadata consistency
Index coverage in Search Console
Sitemap freshness
Content updates
Image optimization status

A good rule:

Review your SEO optimization checklist every 3 months.

Final Thoughts

A modern web app is not SEO-ready by default. Without a structured system, search engines may never fully understand your content.

That’s why a strong SEO optimization checklist is essential:

It ensures discoverability
It improves ranking consistency
It fixes technical blind spots
It aligns developers with SEO best practices

If you implement even 70% of this checklist, you’ll already outperform most JavaScript-heavy websites, naturally adding better visibility and stronger organic growth when you use power SEO tool.

Forem: Mitu Das

JavaScript SEO Checklist to Fix Ranking & Rendering Issues

1. Understand How Googlebot Actually Renders Your JS

2. Fix Your Meta Tags They're Probably Broken in SPAs

3. Structured Data: The Checklist Item Nobody Does

4. Canonical Tags and Duplicate Content Are Silently Killing Your Rankings

What I Learned / Key Takeaways

Over to You

How to Optimize SEO for React Apps Fast

I Spent 3 Hours Debugging Why Google Couldn't See My React App. The Fix Was 4 Lines of Code.

Why React Breaks SEO (And What's Actually Happening)

Fix #1: Dynamic Meta Tags Per Route (Zero Framework Switch)

Fix #2: Structured Data with JSON-LD (Google's Preferred Format)

Fix #3: Automating This With power-seo

Fix #4: Prerendering for SPAs That Can't Do SSR

What I Learned

Let's Talk About It

SEO Analysis for Developers: Why Your JavaScript App Is Invisible to Google

What SEO Analysis Actually Means for a Developer

Step 1: Stop Trusting DevTools, Use curl Instead

Step 2: Build a Programmatic SEO Audit Script

Step 3: Fix Metadata at the Server Layer, Not the Client

Next.js (App Router), The Right Way

Remix, Route-Level Metadata

Plain Node.js / Express SSR

Step 4: Add Structured Data, The Layer That Unlocks Rich Results

Step 5: Automate SEO Analysis in Your CI Pipeline

Step 6: Understand What Google Actually Sees, The Rendering Gap

What I Learned

Let's Talk About Your SEO Workflow

How to Build a Custom ERP System : The Complete Developer's Guide

01. Why Build a Custom ERP System?

Custom vs. Off-the-Shelf: The Real Trade-off

02. Planning Your Custom ERP: Start Here

Step 1: Map Your Current Business Processes

Step 2: Define Your Non-Negotiables

Step 3: Identify All Integration Points

03. ERP System Design and Architecture

Monolith vs. Microservices

Database Design Principles for ERP

Role-Based Access Control (RBAC) Architecture

04. Core Modules Every Custom ERP Needs

05. Choosing the Right Tech Stack for ERP App Development

One Stack Decision I Always Recommend

06. The Custom ERP Software Development Process

07. Cost and Timeline: What to Realistically Expect

The Biggest Hidden Cost Drivers

Build In-House vs. Hire a Custom ERP Software Development Services Partner

Building a Custom ERP Is a Long Game Worth Playing

Website Audit Tools Free of Cost That Developers Actually Use

Why Most Developers Skip Audits (And Pay for It Later)

Step 1: Scrape and Validate Meta Tags with Node.js

Step 2: Validate Robots.txt and Sitemap Programmatically

Step 3: Crawl for Broken Internal Links

Step 4: Where power-seo Fits In

What I Learned

What's Your Audit Workflow?

I Built a JavaScript SEO Content Analyzer in an Afternoon. Here's Everything I Learned

I Spent 3 Hours Debugging Why Google Couldn't See My React App

Why JavaScript Apps Break SEO (And Why Linters Won't Save You)

Step 1: Fetch and Parse Page Metadata Programmatically

Step 2: Score and Flag Issues Automatically

Step 3: Scale It Across Your Entire Sitemap

Step 4: Where a Library Like power-seo Fits In

What I Learned

What's Your SEO Debugging Story?

SEO Mistakes I Keep Seeing Developers Make (And How to Fix Them With Code)

1. Fix crawlability before anything else to avoid SEO mistakes

Generate a Standards-Compliant Sitemap Automatically

2. Redirect Chains Are Bleeding Your Link Equity

Define Rules Once, Apply Them Everywhere

3. Meta Tags Are Not Optional

Write Meta Config Once, Get Correct Output for Every Framework

Validate Title Width Before It Gets Truncated in SERPs

4. Publishing Is Not the Finish Line

Run a Programmatic Content Audit Before Every Publish

5. Duplicate Content Is Quietly Splitting Your Rankings

Normalize Every URL Variation to One Canonical

6. Images Are Killing Your Core Web Vitals

Audit Alt Text, Lazy Loading, and Format in One Pass

Fix #3: Automating This With `power-seo`

Step 1: Stop Trusting DevTools, Use `curl` Instead