Forem: Mitu Das

SEO Mistakes That Are Silently Killing Your Dev Projects

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

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

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

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

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

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

Here's what a proper meta setup looks like:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mistake #3: You Have No Structured Data

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What I Actually Learned

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

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

What's Your Biggest SEO Headache?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Auditing Structured Data and Open Graph Tags Programmatically

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

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

npm install cheerio node-fetch

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

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

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

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

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

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

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

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

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

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

Automating Multi-Page Audits with a Crawl Script

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

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

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

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

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

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

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

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

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

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

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

Going Deeper: When You Need More Than a Script

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

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

You install it globally and point it at a URL:

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

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

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

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

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

What's your biggest JavaScript SEO headache?

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

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

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

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

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

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

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

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

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

The three layers that matter for e-commerce SEO:

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

Let's fix all three.

1. Add Product Structured Data (JSON-LD)

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

Create a reusable component:

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

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

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

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

Use it in your product page:

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

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

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

2. Dynamic Meta Tags Per Product Page

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

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

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

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

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

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

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

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

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

3. Canonical URLs and Faceted Navigation

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

Fix it with canonical tags:

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

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

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

  return canonical.toString();
}

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

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

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

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

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

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

4. Automating This Across a Large Catalog

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

npm install @power-seo

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

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

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

What I Learned

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

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

What's Your Biggest E-commerce SEO Headache?

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

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

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

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

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

No image. No title. No description.

Just a sad naked URL.

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

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

The React SEO Problem Nobody Notices Until Production

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

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

Then somewhere inside React:

import { Helmet } from "react-helmet";

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

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

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

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

Looks correct, right?

But many crawlers fetch the initial HTML before React hydrates.

That means they only see:

<title>My React App</title>

…and completely miss your dynamic Open Graph tags.

Result:

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

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

The Fastest Fix Is Injecting OG Tags Server Side

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

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

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

Step 1: Create an Express server

Install Express:

npm install express

Create server.js:

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

const app = express();

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

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

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

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

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

  res.send(html);
});

app.listen(3000);

Step 2: Add placeholders to `index.html`

<head>
  <title>__TITLE__</title>

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

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

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

Now crawlers receive the correct tags immediately.

No hydration required.

Result

When someone shares:

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

Twitter, Discord, LinkedIn, and Facebook now render:

Correct title
Correct description
Preview image

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

Dynamic OG Images Improve CTR More Than Most Developers Expect

Most developers stop after adding titles and descriptions.

But preview images dramatically improve click-through rates.

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

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

Install dependencies:

npm install satori sharp

Create og.js:

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

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

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

Add route:

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

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

Now your OG tag becomes:

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

Result

Every shared article automatically gets a branded preview image.

That alone can significantly improve engagement on:

Dev.to
Twitter/X
Reddit
LinkedIn
Discord

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

A Cleaner Approach Using @power-seo

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

Especially:

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

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

Example:

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

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

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

Then mount middleware:

app.use(seo.middleware());

That’s it.

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

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

The package simply removes repetitive plumbing.

I wrote a deeper breakdown here:

Open Graph React SEO guide

How to Verify Your Open Graph Tags Actually Work

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

That’s not enough.

You need to test what crawlers actually see.

Twitter Card Validator

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

LinkedIn Post Inspector

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

Facebook Sharing Debugger

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

Paste your URL and verify:

Title
Description
Image
Canonical URL

If something looks wrong, the usual causes are:

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

Common Open Graph React SEO Mistakes

1. Using React Helmet Alone

react-helmet is useful for browsers.

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

2. Forgetting Absolute URLs

This breaks frequently:

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

Use:

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

3. Wrong Image Size

Recommended dimensions:

1200 × 630

Smaller images often render poorly or fail entirely.

4. Not Caching OG Images

Dynamic generation can become expensive quickly.

Cache aggressively:

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

What I Learned

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

What’s your current React SEO setup?

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

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

React SEO Guide: Making Google Actually See Your React App

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

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

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

Why React Apps Are Invisible to Search Engines

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

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

Here is a minimal React app:

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

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

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

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

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

The result:

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

The real issue:

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

Step 1: Add Proper Meta Tags (Baseline Fix)

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

Install it:

npm install react-helmet

Now update your component:

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

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

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

What changed?

Now your app provides:

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

Result:

When crawlers execute JavaScript, they finally see meaningful metadata.

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

Step 2: Server Side Rendering or Pre rendering

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

You need HTML that already contains content before JavaScript runs.

Option A: SSR with Node and Express

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

const app = express();

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

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

  res.send(html);
});

app.listen(3000);

What this fixes:

Google sees full HTML immediately
Faster indexing
Better performance signals

Option B: Static pre rendering

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

This is ideal for:

Portfolio sites
Landing pages
Blogs

Step 3: Automating SEO Without Manual Meta Work

In real projects, SEO gets repetitive fast.

You do not want to manually manage:

Page titles
Descriptions
Open Graph tags

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

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

npm install @power-seo

Then integrate it:

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

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

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

Why this helps in real projects:

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

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

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

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

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

Result:

Fewer missing SEO tags
Consistent metadata
Less manual repetition across pages

Step 4: Invisible SEO Factors Developers Miss

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

1. Semantic HTML

Bad:

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

Better:

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

Search engines understand semantic elements better.

2. Clean URL structure

Bad:

/page?id=123

Better:

/blog/react-seo-guide

Clean URLs improve indexing and readability.

3. Sitemap generation

Basic sitemap example:

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

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

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

What I Learned (Key Takeaways)

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

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

React vs WordPress: Why I Stopped Fighting the SEO Battle and Started Automating It

Mitu Das — Sun, 10 May 2026 06:41:47 +0000

I spent five hours debugging why Google couldn't crawl a single page of a React app I'd built. No meta tags. No Open Graph data. A Lighthouse SEO score of 43. The client had left WordPress specifically because they wanted "modern tech", and I'd handed them an invisible website. If you're a React developer who's ever had a client ask "why aren't we ranking?", this one's for you.

The Real Reason WordPress Still Wins on SEO (It's Not Magic)

Let's be honest about why agencies keep defaulting to WordPress: it just works, out of the box, for SEO. Install Yoast, write some content, Google finds you. Done.

But the reason isn't that WordPress is better software. It's that WordPress renders HTML on the server, which means every page Googlebot visits already has its title, description, canonical URL, and Open Graph tags baked into the response. There's no JavaScript to execute. No async hydration to wait for.

React apps, by default, ship a nearly empty index.html and build the DOM client-side. Googlebot can execute JavaScript, but it often won't wait long enough, and crawl budget is finite. The result: orphaned pages, missing meta, and rankings that flatline.

The fix isn't to abandon React. It's to give your React app the same server-side head tag discipline that WordPress enforces by default.

Step 1: Stop Relying on `document.title`. Use a Proper Head Manager

The first thing most React devs reach for is document.title = "My Page" inside a useEffect. This is wrong for two reasons: it fires after render (too late for crawlers), and it leaves your <meta> tags completely untouched.

Use react-helmet-async instead. It renders head content during SSR and stays reactive client-side:

npm install react-helmet-async

Wrap your app:

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

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

Then on any page component:

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

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

Result: Every route now has unique, crawlable meta. This alone typically moves a Lighthouse SEO score from the 40s to the 80s.

Step 2: Generate Your Sitemap Automatically (Not Manually)

WordPress auto-generates a sitemap. Your React app doesn't, unless you build it. Most developers either forget this entirely or maintain a hand-written sitemap.xml that's always three sprints out of date.

The right move: generate it at build time from your actual routes or CMS data.

// scripts/generate-sitemap.js
import { writeFileSync } from 'fs';
import { routes } from '../src/routes.js'; // your route config

const BASE_URL = 'https://yourdomain.com';
const today = new Date().toISOString().split('T')[0];

const sitemap = `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
${routes
  .filter(r => !r.private)
  .map(r => `  <url>
    <loc>${BASE_URL}${r.path}</loc>
    <lastmod>${today}</lastmod>
    <changefreq>${r.changefreq || 'weekly'}</changefreq>
    <priority>${r.priority || '0.7'}</priority>
  </url>`)
  .join('\n')}
</urlset>`;

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

Wire it into your build:

// package.json
{
  "scripts": {
    "build": "node scripts/generate-sitemap.js && vite build"
  }
}

Result: A fresh, accurate sitemap on every deploy. No manual updates. No forgotten pages.

Step 3: Automate Meta Generation for Content-Heavy Apps

Here's where things get interesting. If your React app pulls content from a headless CMS, an API, or a database, writing <Helmet> blocks by hand for every content type doesn't scale. You end up with inconsistent descriptions, missing OG images, and titles that don't match page content.

This is the exact problem the @power-seo package was built for. It's a lightweight utility that generates structured meta tags from a content object, useful when you're pulling dynamic data and don't want to hand-wire every field.

npm install @power-seo

// hooks/useSEO.js
import { generateMeta } from '@power-seo';
import { Helmet } from 'react-helmet-async';

export function SEOHead({ content }) {
  const meta = generateMeta({
    title: content.title,
    description: content.description,
    image: content.thumbnail,
    url: content.canonicalUrl,
    type: content.type || 'article',
  });

  return (
    <Helmet>
      {meta.map(tag =>
        tag.property
          ? <meta key={tag.property} property={tag.property} content={tag.content} />
          : <meta key={tag.name} name={tag.name} content={tag.content} />
      )}
      <title>{meta.title}</title>
      <link rel="canonical" href={content.canonicalUrl} />
    </Helmet>
  );
}

Now every content type (blog posts, product pages, profile pages) gets consistent, correctly structured meta without you writing the same boilerplate seventeen times.

A deeper breakdown of this pattern, including how it was applied on a real headless CMS project, is documented at ccbd.dev/blog/react-vs-wordpress.

Step 4: Validate Before You Ship

None of this matters if you don't verify it's working. Add this to your CI pipeline or run it locally before every deploy:

# Install once
npm install -g lighthouse

# Run against your local build
npx serve dist &
lighthouse http://localhost:3000 --only-categories=seo --output=json | \
  node -e "const d=require('/dev/stdin');console.log('SEO Score:', d.categories.seo.score * 100)"

You want 90+. Anything below 80 means something is missing: usually canonical URLs, meta descriptions, or mobile viewport config.

Also paste your URLs into search.google.com/test/rich-results before launch. It shows you exactly what Googlebot sees, which is the only opinion that matters.

What I Learned

WordPress doesn't win on SEO because it's better; it wins because it enforces discipline by default. React gives you full control, which means you're also fully responsible.
Client-side document.title is not SEO. Use react-helmet-async from day one, not as a retrofit.
Sitemaps should be generated, not written. Automate this in your build script or you will forget to update it.
Dynamic content needs a systematic meta strategy. Hand-written <Helmet> blocks don't scale past a dozen content types. Abstract it into a hook or utility.
Measure it. Lighthouse SEO scores are blunt but honest. Run them in CI so regressions don't slip into production.

Your Turn

Have you migrated a project from WordPress to React and had to rebuild the SEO layer from scratch? What did you wish you'd known going in?

Drop your war stories in the comments, especially if you found a crawlability issue that turned out to be something completely unexpected. These threads are always more useful than the article itself.

SEO Checklist for JavaScript Apps: Fix Your Rankings Before Your Next Deploy

Mitu Das — Sat, 09 May 2026 05:43:58 +0000

I spent four months building a React app. Polished UI, fast load times, clean code. Then I checked Google Search Console and nearly threw my laptop out the window. Zero indexed pages. Zero. Turns out I had been shipping a beautifully crafted ghost town, and every JavaScript developer I've talked to has hit this wall at least once.

If you're building with React, Next.js, Vue, or any JS-heavy stack, the SEO checklist for JavaScript apps is different from what most tutorials teach. The WordPress-era advice will quietly mislead you. Let me share the exact checklist I now run through on every project before it ships.

SEO Checklist Step 1: Solve the JavaScript Rendering Problem First

The first item on any SEO checklist for JavaScript developers is rendering. Googlebot can execute JavaScript, but it does not always wait for it. By the time it crawls your page, your useEffect() has not fired, your API call has not returned, and your <title> tag is still an empty string.

Run this quick audit to check what Googlebot actually sees:

# Simulate Googlebot's initial HTML fetch (no JS execution)
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://yoursite.com | grep -E "<title>|<meta name=\"description\"|<h1>"

If that command returns empty tags or nothing at all, you have a rendering problem. The fix depends on your stack, but the three paths forward are:

SSR (Server-Side Rendering): render HTML on the server per request (Next.js, Nuxt, SvelteKit)
SSG (Static Site Generation): pre-render at build time for content that does not change per user
Dynamic rendering: serve pre-rendered HTML to bots, client-rendered pages to users

For most content-driven JavaScript apps, SSG is the sweet spot. Here is the Next.js pattern:

// pages/blog/[slug].js
export async function getStaticProps({ params }) {
  const post = await fetchPost(params.slug);

  return {
    props: {
      title: post.title,
      description: post.excerpt,
      content: post.body,
    },
    revalidate: 60, // ISR: regenerate every 60 seconds
  };
}

export async function getStaticPaths() {
  const posts = await fetchAllSlugs();
  return {
    paths: posts.map((p) => ({ params: { slug: p.slug } })),
    fallback: "blocking",
  };
}

Result: Googlebot fetches fully-formed HTML. Title, description, and H1 are all present before a single line of client JavaScript runs. Rendering is always step one on the SEO checklist for JavaScript projects.

SEO Checklist Step 2: Meta Tags on Every Route, Not Just the Homepage

Every page in your JavaScript app needs a minimum viable set of meta tags. Not just the homepage, every dynamic route. This is one of the most commonly skipped items on any JavaScript SEO checklist.

Here is a copy-paste template for Next.js using the App Router:

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

  return {
    title: `${post.title} | My Site`,
    description: post.excerpt.slice(0, 155), // Google truncates at ~155 chars
    openGraph: {
      title: post.title,
      description: post.excerpt,
      url: `https://mysite.com/blog/${params.slug}`,
      type: "article",
      publishedTime: post.createdAt,
      images: [
        {
          url: post.ogImage || "https://mysite.com/default-og.png",
          width: 1200,
          height: 630,
        },
      ],
    },
    twitter: {
      card: "summary_large_image",
      title: post.title,
      description: post.excerpt,
    },
    alternates: {
      canonical: `https://mysite.com/blog/${params.slug}`,
    },
  };
}

What each field does for your JavaScript SEO:

title: shows in SERPs and browser tabs; keep under 60 characters
description: your pitch in search results; Google may rewrite it, but write it anyway
canonical: prevents duplicate content penalties when your content appears at multiple URLs
openGraph: controls how your link looks when shared on Slack, LinkedIn, and Discord

Quick validation check: paste your URL into [opengraph.xyz] to see what social platforms will render before you go live.

SEO Checklist Step 3: Structured Data, the Signal Most JavaScript Devs Skip

Schema markup is JSON-LD you embed in your page that tells Google exactly what type of content it is looking at. Blog post? Product? Recipe? FAQ? Google uses structured data to generate rich results like star ratings, article dates, and breadcrumbs that push your JavaScript app's listing above plain blue links.

This is consistently the most skipped item on the SEO checklist for JavaScript projects, and it has one of the highest return-on-effort ratios.

Here is a reusable helper for article schema:

// lib/schema.js
export function generateArticleSchema({
  title,
  description,
  datePublished,
  dateModified,
  author,
  url,
  imageUrl,
}) {
  return {
    "@context": "https://schema.org",
    "@type": "Article",
    headline: title,
    description: description,
    datePublished: datePublished,
    dateModified: dateModified || datePublished,
    author: {
      "@type": "Person",
      name: author,
    },
    publisher: {
      "@type": "Organization",
      name: "My Site",
      logo: {
        "@type": "ImageObject",
        url: "https://mysite.com/logo.png",
      },
    },
    mainEntityOfPage: {
      "@type": "WebPage",
      "@id": url,
    },
    image: imageUrl,
  };
}

// Usage in your page component
export default function BlogPost({ post }) {
  const schema = generateArticleSchema({
    title: post.title,
    description: post.excerpt,
    datePublished: post.createdAt,
    author: post.authorName,
    url: `https://mysite.com/blog/${post.slug}`,
    imageUrl: post.ogImage,
  });

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

Validate it at [Google's Rich Results Test]. It shows you exactly what Google sees and flags any schema errors before they hurt your rankings.

SEO Checklist Step 4: Automate the Audit So Nothing Gets Skipped

The real problem with any SEO checklist for JavaScript apps is not knowing what to check — it is remembering to check it before every single deploy. I started automating my SEO audit as part of my CI pipeline, and I have not shipped a missing meta tag since.

I came across power-seo while looking for a Node.js-compatible audit tool I could run headlessly in CI. It checks meta completeness, structured data validity, canonical tags, and more from a single CLI call, which made it easy to drop into a pre-deploy script:

npm install -D @power-seo/core

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

const urls = [
  "https://staging.mysite.com/",
  "https://staging.mysite.com/blog/my-first-post",
  "https://staging.mysite.com/about",
];

async function runAudit() {
  for (const url of urls) {
    const result = await audit(url);
    if (result.score < 80) {
      console.error(`SEO score too low for ${url}: ${result.score}`);
      process.exit(1); // Fail the CI step
    }
    console.log(`SEO OK: ${url} scored ${result.score}`);
  }
}

runAudit();

Add it to your package.json:

{
  "scripts": {
    "seo:audit": "node scripts/seo-audit.js",
    "predeploy": "npm run seo:audit"
  }
}

Now every npm run deploy runs the SEO checklist for your JavaScript app automatically. If any page scores below your threshold, the deploy stops. No more invisible pages slipping through.

Key Takeaways

Rendering is the foundation. No amount of perfect meta tags saves you if Googlebot sees an empty <div id="root"></div>. Solve SSR or SSG before anything else on the checklist.
Every route needs its own meta tags. Dynamic JavaScript pages (blog posts, product pages, user profiles) need programmatic meta generation, not hardcoded titles.
Structured data is low-effort, high-reward. Article schema takes 20 minutes to implement and can earn rich results that significantly improve your click-through rate.
Automate the checklist. Human checklists get skipped under deadline pressure. A CI check that fails the build does not get skipped.

If you want to try the automated SEO checklist approach for your JavaScript app, here's the repo: [https://github.com/CyberCraftBD/power-seo]

Your Turn

What is the sneakiest SEO bug you have shipped to production in a JavaScript app? Mine was a noindex meta tag left over from a staging environment that made it all the way to launch, three weeks before I noticed.

Drop your war story in the comments. I am genuinely curious: does the rendering issue or the missing meta tags cause more grief for JavaScript developers in practice? And if you are on Nuxt, SvelteKit, or Remix, did these patterns translate cleanly for you, or did you have to solve it a different way?

Next.js SEO in 2026: The Stuff That Actually Moved My Rankings

Mitu Das — Thu, 07 May 2026 04:47:12 +0000

I used to think good SEO in Next.js meant adding a <title> tag, writing a meta description, and shipping the app.

Then one of my projects got outranked by a slower website with worse UI and older content.

That made me realize modern SEO for React apps is less about “adding meta tags” and more about rendering strategy, structured data, metadata consistency, and performance. Especially now that search engines are heavily evaluating user experience and AI-generated summaries.

Over the last few months, I rebuilt my SEO workflow for App Router projects, and honestly, most tutorials online still repeat outdated advice. This article is the practical version of what actually improved indexing, social previews, and ranking consistency in my Next.js apps.

Why Most Next.js Apps Still Have SEO Problems

A lot of developers assume Next.js automatically handles SEO because pages are server-rendered.

It helps, but it does not solve:

duplicate metadata,
broken canonical URLs,
inconsistent OpenGraph tags,
missing structured data,
slow hydration,
or poor crawlability.

I learned this after shipping a content-heavy project where half the pages were indexed with the wrong titles.

The issue was not React itself. The issue was inconsistent SEO architecture.

The first thing I changed was centralizing metadata generation instead of manually writing metadata on every page.

1. Centralize Metadata Instead of Repeating It Everywhere

My old setup looked like this:

export const metadata = {
  title: "My Blog",
  description: "Welcome to my blog",
}

Then I copied this across dozens of pages.

Eventually:

some titles became outdated,
social previews broke,
and canonical URLs became inconsistent.

So I created a reusable SEO helper.

Reusable SEO Utility

// lib/seo.ts

type SEOProps = {
  title: string
  description: string
  path?: string
  image?: string
}

export function generateSEO({
  title,
  description,
  path = "",
  image = "/og.png",
}: SEOProps) {
  const url = `https://example.com${path}`

  return {
    title,
    description,
    alternates: {
      canonical: url,
    },
    openGraph: {
      title,
      description,
      url,
      images: [image],
      type: "website",
    },
    twitter: {
      card: "summary_large_image",
      title,
      description,
      images: [image],
    },
  }
}

Now every page became much cleaner:

import { generateSEO } from "@/lib/seo"

export const metadata = generateSEO({
  title: "Next.js SEO Guide",
  description: "Complete SEO setup for Next.js apps",
  path: "/blog/nextjs-seo",
})

Result

This solved several problems immediately:

duplicate metadata,
inconsistent canonical URLs,
and missing social cards.

It also made SEO updates significantly easier because I only had one place to manage metadata behavior.

One small architectural decision removed dozens of repetitive mistakes.

2. Dynamic Metadata

This was the biggest App Router mistake I kept seeing in production apps.

Developers fetch content dynamically inside the page component, but metadata stays static.

That creates a mismatch between:

what users see,
and what crawlers index.

I had pages indexed with generic homepage titles because metadata was never connected to the actual article data.

The fix was using generateMetadata() properly.

Correct Dynamic Metadata Setup

// app/blog/[slug]/page.tsx

import { Metadata } from "next"

async function getPost(slug: string) {
  const res = await fetch(
    `https://api.example.com/posts/${slug}`,
    {
      next: { revalidate: 3600 },
    }
  )

  return res.json()
}

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

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

  return {
    title: post.title,
    description: post.excerpt,
    openGraph: {
      title: post.title,
      description: post.excerpt,
      images: [post.image],
    },
  }
}

export default async function Page({ params }: Props) {
  const post = await getPost(params.slug)

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

Result

Google started indexing article titles correctly instead of showing fallback site metadata.

Social previews also became dramatically better because OpenGraph tags now reflected real content dynamically.

One important lesson here:

Metadata should come from the same data source as your page content.

If they are disconnected, SEO inconsistencies become inevitable.

3. Structured Data Is Still Criminally Underrated

I ignored structured data for a long time because it felt annoying to maintain.

Big mistake.

Structured data became one of the highest-impact SEO improvements I made, especially for blog content and documentation pages.

Search engines rely heavily on schema markup to understand:

content type,
publication dates,
authors,
FAQs,
and article relationships.

I started adding JSON-LD manually first.

Simple JSON-LD Component

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

Usage:

<JsonLd
  data={{
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    headline: post.title,
    description: post.excerpt,
    image: post.image,
    author: {
      "@type": "Person",
      name: "CyberCraft",
    },
    datePublished: post.createdAt,
  }}
/>

Result

Some pages started showing:

enhanced search snippets,
visible publication dates,
and noticeably higher click-through rates.

It does not guarantee rich results instantly, but it gives search engines much stronger context about your content.

And honestly, most developers still skip this entirely.

That makes it one of the easiest competitive advantages in technical SEO right now.

4. Automating SEO Reduced Development Mistakes

After repeating the same SEO setup across multiple projects, I started looking for a cleaner way to automate metadata handling.

That is where I began experimenting with @power-seo.

I did not use it because I expected “instant rankings.”

I used it because maintaining:

canonical URLs,
OpenGraph data,
Twitter cards,
structured metadata,
and consistent titles

across large apps became repetitive very quickly.

Installation

npm install @power-seo/core

Basic Setup

// lib/power-seo.ts

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

export const seo = createSEO({
  siteName: "My App",
  defaultTitle: "My App",
  description: "Modern Next.js application",
  baseURL: "https://example.com",
  twitter: "@example",
})

Usage:

import { seo } from "@/lib/power-seo"

export const metadata = seo.generate({
  title: "Dashboard",
  path: "/dashboard",
})

Result

The biggest improvement was consistency.

Every page automatically included:

normalized titles,
canonical URLs,
OpenGraph support,
Twitter metadata,
and structured SEO defaults.

That reduced development mistakes significantly, especially in larger projects with many dynamic routes.

I still believe understanding SEO fundamentals matters first.

But once your app grows, automation becomes extremely valuable.

If you want a deeper technical breakdown of App Router rendering and metadata architecture, I wrote a more detailed guide here:

ccbd.dev Next.js SEO Guide

And the npm package is available here:

@power-seo on npm

Performance Still Impacts SEO More Than People Admit

This part gets ignored constantly in frontend discussions.

A technically optimized page can still rank poorly if:

hydration is too heavy,
JavaScript bundles are massive,
or layout shifts hurt usability.

Some of the biggest improvements I made were performance-related, not metadata-related.

Use Server Components Aggressively

async function Products() {
  const data = await getProducts()

  return <ProductList products={data} />
}

Less client JavaScript means:

faster rendering,
lower hydration cost,
and better crawl consistency.

Optimize Images Properly

import Image from "next/image"

<Image
  src="/hero.jpg"
  alt="SEO dashboard"
  width={1200}
  height={630}
  priority
/>

Image optimization alone improved Lighthouse scores noticeably on several projects.

Avoid Turning Everything Into Client Components

This became a hidden SEO problem in one of my apps.

If every component uses "use client", the app becomes heavier and slower to hydrate.

Now I only use client components where interactivity is actually necessary.

Everything else stays server-rendered by default.

That single change improved both performance and crawl stability.

What I Learned / Key Takeaways

Modern Next.js SEO is more about architecture than meta tags.
Dynamic metadata should always come from the same source as page content.
Structured data is still massively underused and creates an easy SEO advantage.
Centralized metadata utilities reduce repetitive mistakes across large apps.
App Router provides excellent SEO capabilities when used correctly.
Performance optimization still impacts rankings more than many developers expect.
Automated SEO tooling becomes valuable once projects scale beyond a few pages.

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

Final Thoughts

A year ago I thought SEO was mostly a marketing problem.

Now I see it as part of frontend architecture.

Rendering strategy, metadata generation, structured data, performance, and crawlability all work together in modern Next.js applications.

What has been your biggest SEO challenge with Next.js recently? Are you still managing metadata manually, or have you started automating parts of your workflow?

Server Side Rendering (SSR) in React: Why Your App Is Invisible to Google (And How to Fix It)

Mitu Das — Wed, 06 May 2026 10:19:25 +0000

You spent three weeks building a beautiful React SPA. You deployed it. You Googled it. Google returns nothing. Or worse, it crawls your page and indexes <div id="root"></div>.

This isn't a bug. It's the fundamental tension between how React works and how search engines crawl the web. Client-side rendering hands the browser a blank HTML shell and says "figure it out." Googlebot sometimes does. Bing mostly doesn't. And "sometimes" is not an SEO strategy.

Server Side Rendering (SSR) in React solves this at the source, but the implementation details trip up a lot of developers. Let's fix that.

What Actually Happens During CSR vs. Server Side Rendering in React

Before writing a single line of code, it's worth being precise about the difference.

With Client-Side Rendering (CSR), the server sends this:

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

The browser downloads the JS bundle, executes React, and then renders your content. For a user on a fast connection, this feels fine. For a crawler with a 5-second timeout or a user on 3G, it's a blank page.

With Server Side Rendering (SSR) in React, the server runs your components and sends fully rendered HTML:

<!DOCTYPE html>
<html>
  <head>
    <title>My Product Page</title>
    <meta name="description" content="Buy the best widget online" />
  </head>
  <body>
    <div id="root">
      <h1>Best Widget</h1>
      <p>Buy the best widget online...</p>
    </div>
    <script src="/bundle.js"></script>
  </body>
</html>

Crawlers get real content immediately. Then React "hydrates" the page on the client, attaching event listeners to the already-rendered HTML so it becomes interactive. This also directly improves your Core Web Vitals SEO scores, particularly LCP (Largest Contentful Paint), because meaningful content hits the browser much earlier.

How to Implement Server Side Rendering (SSR) in React With Express

You don't always need Next.js. Understanding raw SSR in React makes you a better developer regardless of what framework you ultimately use.

Step 1: Install dependencies

npm install react react-dom express
npm install --save-dev @babel/core @babel/preset-env @babel/preset-react babel-register

Step 2: Your React component (src/App.jsx):

import React from 'react';

export default function App({ title, description }) {
  return (
    <div>
      <h1>{title}</h1>
      <p>{description}</p>
    </div>
  );
}

Step 3: The SSR Express server (server.js):

require('@babel/register')({
  presets: ['@babel/preset-env', '@babel/preset-react'],
});

const express = require('express');
const React = require('react');
const { renderToString } = require('react-dom/server');
const App = require('./src/App').default;

const app = express();

app.get('/', (req, res) => {
  const props = {
    title: 'Best Widget on the Market',
    description: 'Buy the best widget online, fast shipping, great price.',
  };

  // Core of SSR in React: render component to HTML string on the server
  const html = renderToString(React.createElement(App, props));

  res.send(`
    <!DOCTYPE html>
    <html lang="en">
      <head>
        <meta charset="UTF-8" />
        <meta name="description" content="${props.description}" />
        <title>${props.title}</title>
      </head>
      <body>
        <div id="root">${html}</div>
        <script src="/bundle.js"></script>
      </body>
    </html>
  `);
});

app.listen(3000, () => console.log('SSR React server running on port 3000'));

Run it: node server.js. View source in your browser. You'll see fully rendered HTML, not a blank <div>.

Result: Crawlers index real content instantly. Time to First Contentful Paint drops. And you didn't install Next.js.

The Meta Tag Problem SSR in React Doesn't Automatically Solve

Here's the part most Server Side Rendering React tutorials skip: rendering HTML to the DOM isn't enough. Search engines also parse your <head>, including title, description, Open Graph tags, canonical URLs, and structured data. If those are hardcoded or missing, you're still leaving SEO ranking on the table.

Dynamically injecting per-route meta tags in SSR requires deliberate plumbing:

// Route-based meta config
const metaConfig = {
  '/': {
    title: 'Home | My Store',
    description: 'The best widgets online.',
    canonical: 'https://mystore.com/',
  },
  '/products': {
    title: 'Products | My Store',
    description: 'Browse our full product catalog.',
    canonical: 'https://mystore.com/products',
  },
};

app.get('*', (req, res) => {
  const meta = metaConfig[req.path] || {
    title: 'My Store',
    description: 'Default description.',
    canonical: `https://mystore.com${req.path}`,
  };

  const html = renderToString(React.createElement(App, {}));

  res.send(`
    <!DOCTYPE html>
    <html lang="en">
      <head>
        <title>${meta.title}</title>
        <meta name="description" content="${meta.description}" />
        <link rel="canonical" href="${meta.canonical}" />
        <meta property="og:title" content="${meta.title}" />
        <meta property="og:description" content="${meta.description}" />
      </head>
      <body>
        <div id="root">${html}</div>
        <script src="/bundle.js"></script>
      </body>
    </html>
  `);
});

This works, but it grows unwieldy fast across dozens of routes. This is where a dedicated SEO layer becomes valuable.

The power-seo npm package handles this cleanly. It generates structured, route-aware SEO tags as a middleware step that slots directly into your existing SSR React server. Define your SEO config once and it handles the injection. I've been using it on a project at ccbd.dev where managing meta tags per route was getting messy at scale. Worth evaluating if your route count is growing.

Hydration: The Final Piece of SSR in React

SSR in React gets your HTML to the client fast. But without hydration, your event handlers won't work. The browser displays the server-rendered HTML and just sits there.

Client entry point (src/index.jsx):

import React from 'react';
import { hydrateRoot } from 'react-dom/client';
import App from './App';

// Props must match exactly what the server rendered
const props = window.__INITIAL_PROPS__;

hydrateRoot(document.getElementById('root'), <App {...props} />);

Pass initial props from the SSR server to the client:

// Inside your server.js template string
res.send(`
  ...
  <script>
    window.__INITIAL_PROPS__ = ${JSON.stringify(props)};
  </script>
  <script src="/bundle.js"></script>
  ...
`);

hydrateRoot (React 18+) attaches event listeners to the existing server-rendered DOM without re-rendering it. The result: near-instant First Contentful Paint from SSR, plus full interactivity once the bundle loads. That's the complete Server Side Rendering in React pipeline. Server renders, client hydrates, user wins.

Key Takeaways

SSR in React is just Node.js running your components before the HTTP response is sent. Once that clicks, everything else follows naturally.
Meta tags are a separate concern from rendering. Server Side Rendering (SSR) in React gets content into the DOM, but dynamic <head> injection per route requires its own solution.
Core Web Vitals SEO is a real ranking factor. SSR's improvement to LCP and FID isn't just a performance win; it directly affects where you land in search results. Google has confirmed this.
Hydration mismatches will cost you hours. Server and client must render identically. Guard against Date.now(), Math.random(), and browser-only APIs (window, document) running during server render.
Next.js is SSR in React with training wheels. Genuinely useful training wheels, but you'll debug it faster once you understand the raw mechanics underneath.

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

Over to You

Are you using Server Side Rendering in React in production and what's the biggest pain point you've hit: hydration mismatches, meta tag management, or something else entirely?

Drop your setup in the comments. I'm especially curious whether teams are hand-rolling SSR or defaulting straight to Next.js, and whether the trade-offs were worth it for your use case.

Core Web Vitals SEO: Why Your React App Is Invisible to Google (and the Fix)

Mitu Das — Tue, 05 May 2026 04:50:51 +0000

I spent long hours debugging why Google couldn't index my React app. Lighthouse showed green scores. The app felt fast. But Search Console kept flagging LCP failures and CLS shifts I couldn't reproduce locally. The fix? Four lines of metadata and one misunderstood render strategy. If you've ever shipped a "fast" SPA and watched it flatline in search rankings, this Core Web Vitals SEO guide is for you.

By the end of this article you'll understand why Core Web Vitals directly affect your Google search rankings (not just your UX scores), how to diagnose the most common performance culprits in JavaScript-heavy apps, and how to wire up automated Core Web Vitals auditing so regressions never sneak past you again.

Why Core Web Vitals SEO Is a Rankings Problem, Not Just a Performance Problem

Google officially rolled Core Web Vitals into its Page Experience ranking signals in 2021. But most developers still treat them as a "make Lighthouse happy" checkbox rather than a real search ranking lever. That's a costly mistake.

The three Core Web Vitals metrics that directly impact your SEO:

LCP (Largest Contentful Paint): how fast your main content loads. Target: under 2.5 s.
CLS (Cumulative Layout Shift): how much the page jumps around during load. Target: under 0.1.
INP (Interaction to Next Paint): how quickly the page responds to user input. Target: under 200 ms. (INP replaced FID as an official ranking signal in March 2024.)

The brutal reality for Core Web Vitals SEO: a React SPA that renders everything client-side ships an empty <div id="root"> to Googlebot. Googlebot can execute JavaScript, but it queues JS rendering and may crawl your page before the render completes. Your LCP score in that crawl window? Terrible. Your ranking potential? Wasted.

The diagnostic command to run before anything else:

npx unlighthouse --site https://your-site.com --reporter json

This crawls every route and dumps per-page Core Web Vitals data. Most teams discover that 3-4 specific routes are tanking the site-wide average and killing their overall search ranking.

Fixing LCP for Better Core Web Vitals SEO: Start With the Hero Image

LCP is the single most impactful Core Web Vitals metric for SEO because it directly correlates with perceived page speed. It measures the largest element that lands in the viewport. Nine times out of ten, it's a hero image, and nine times out of ten, that image is loaded lazily when it shouldn't be.

Wrong (this tanks your LCP score and your SEO):

// Lazy loading above-the-fold images delays LCP and hurts search rankings
<img src="/hero.webp" loading="lazy" alt="Hero" />

Right (Googlebot sees your content immediately):

// Preload in <head> + eager load = fast LCP = better Core Web Vitals SEO
// In your _document.tsx or index.html <head>:
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />

// In your component:
<img
  src="/hero.webp"
  loading="eager"
  fetchpriority="high"
  alt="Hero"
  width={1200}
  height={600}
/>

Always declare explicit width and height on images. Without them, the browser doesn't know the space to reserve, which causes layout shifts and damages your CLS score alongside your LCP.

Next.js shortcut for LCP optimization:

import Image from 'next/image';

<Image
  src="/hero.webp"
  alt="Hero"
  width={1200}
  height={600}
  priority {/* Sets fetchpriority="high" and disables lazy loading */}
/>

One priority prop. That's it. This single change has dropped LCP from 4.2 s to 1.8 s on production sites, pushing them from a "Needs Improvement" to a "Good" Core Web Vitals score in Search Console.

Fixing CLS: The Core Web Vitals SEO Bug That Only Appears in Production

CLS is the sneakiest of the Core Web Vitals issues for SEO because it doesn't show up in local development. Your machine loads assets instantly. Real users on mobile connections see your page jump and shift. Google's crawler notices.

Common CLS offenders that silently hurt your Core Web Vitals SEO score:

Images without explicit dimensions
Dynamically injected banners or cookie consent notices
Web fonts causing FOIT/FOUT (Flash of Invisible/Unstyled Text)
Async-loaded ad slots with no placeholder dimensions

For web fonts, use font-display: swap and preload:

@font-face {
  font-family: 'YourFont';
  src: url('/fonts/yourfont.woff2') format('woff2');
  font-display: swap; /* Prevents invisible text and reduces CLS */
}

<!-- In <head>, load before render-blocking kicks in -->
<link
  rel="preload"
  href="/fonts/yourfont.woff2"
  as="font"
  type="font/woff2"
  crossorigin
/>

For dynamic content, reserve layout space with a skeleton:

function HeroBanner() {
  const [loaded, setLoaded] = useState(false);

  return (
    // Reserve space upfront so no layout shift occurs when content loads
    <div style={{ minHeight: '320px' }}>
      {loaded ? (
        <ActualBanner />
      ) : (
        <div className="skeleton" aria-hidden="true" />
      )}
    </div>
  );
}

The minHeight approach is blunt but effective for Core Web Vitals CLS. The layout doesn't shift because the space was already reserved before the content arrived.

Automating Core Web Vitals SEO Audits in CI

Manual Lighthouse runs are not a Core Web Vitals SEO strategy. They're a ritual you perform twice and forget. Here's how to gate every deployment on Core Web Vitals scores using @lhci/cli, so regressions get caught before they reach Google.

Install Lighthouse CI:

npm install -D @lhci/cli

lighthouserc.js (drop this in your project root):

module.exports = {
  ci: {
    collect: {
      url: ['http://localhost:3000/', 'http://localhost:3000/about'],
      startServerCommand: 'npm run start',
      numberOfRuns: 3,
    },
    assert: {
      assertions: {
        // Fail the build if Core Web Vitals drop below SEO thresholds
        'categories:performance': ['error', { minScore: 0.85 }],
        'first-contentful-paint': ['warn', { maxNumericValue: 2000 }],
        'largest-contentful-paint': ['error', { maxNumericValue: 2500 }],
        'cumulative-layout-shift': ['error', { maxNumericValue: 0.1 }],
        'total-blocking-time': ['warn', { maxNumericValue: 300 }],
      },
    },
    upload: {
      target: 'temporary-public-storage',
    },
  },
};

Add to your GitHub Actions CI pipeline:

- name: Run Core Web Vitals SEO Audit
  run: |
    npm run build
    npx lhci autorun
  env:
    LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

Now every PR gets a Core Web Vitals report attached, and the check fails automatically if LCP exceeds 2.5 s or CLS exceeds 0.1. You stop shipping search ranking regressions silently.

On the metadata side of Core Web Vitals SEO, consistent canonical tags, Open Graph data, and structured JSON-LD schema matter too. Missing or duplicate canonicals dilute your ranking signals even when your performance scores are perfect. For managing this across many routes without copy-paste errors, I've been using [power-seo], an npm package that centralizes all of it in one config:

import { generateSEOHead } from 'power-seo';

const seo = generateSEOHead({
  title: 'Your Page Title',
  description: 'Concise meta description under 160 chars',
  canonical: 'https://your-site.com/page',
  og: { image: 'https://your-site.com/og-image.png' },
  schema: { type: 'Article', author: 'Your Name' },
});

You still own the logic; it just eliminates the boilerplate that causes canonical inconsistencies at scale. More context on combining technical SEO with Core Web Vitals in this complete Core Web Vitals SEO guide for JavaScript sites.

Key Takeaways: Core Web Vitals SEO in Practice

LCP is almost always an image loading problem. Add priority or fetchpriority="high" to your above-the-fold image and measure again before touching anything else. This one fix alone can move you from "Needs Improvement" to "Good" in Google Search Console.
CLS is a "works on my machine" bug. Throttle your network to Fast 3G in Chrome DevTools and watch what breaks. You'll find your layout shift culprit within 60 seconds.
Googlebot is not your user's browser. It renders pages in a queue, often without waiting for full JavaScript execution. If your critical content lives only in JS state, move those routes to SSR or SSG. Your Core Web Vitals SEO scores will reflect the difference immediately.
Automate or you'll regress. One Lighthouse CI config committed to your repo is worth more than 50 manual Core Web Vitals audits you promised yourself you'd run every sprint.

If you want to try the metadata automation approach alongside your Core Web Vitals SEO fixes, here's the repo: https://github.com/CyberCraftBD/power-seo

Over to You

What's been your most frustrating Core Web Vitals SEO debugging experience, and what was the fix that finally moved the needle in Search Console?

Drop it in the comments. I'm especially curious whether anyone has seen INP become a ranking bottleneck after Google's March 2024 switch from FID. My gut says heavy React hydration is the next silent SEO killer after CLS, but I'd love to hear real data from production sites.

Power SEO Analytics vs Looker Studio vs GA4: Pros, Cons & Key Differences

Mitu Das — Sun, 03 May 2026 05:46:17 +0000

I Wasted Two Weeks Looking at the Wrong Metrics

Here's something nobody tells you early enough: GA4, Looker Studio, and dedicated SEO analytics tools are not interchangeable. They answer different questions. I spent two weeks diagnosing a traffic drop by staring at GA4 dashboards before realizing the problem was a crawlability issue GA4 is architecturally blind to. The fix took 20 minutes once I was looking at the right tool.

This article is a practical breakdown of when each platform earns its place in your stack, with real code for pulling data from each. If you've been working through a JavaScript SEO checklist and hit a wall trying to figure out which tool actually surfaces the data you need, this should clear things up.

GA4: Great for User Behavior, Blind to Crawlers

GA4 is JavaScript-first. That's both its strength and its hard limitation for SEO work.

What it's genuinely good at: session data, conversion funnels, event tracking, audience segmentation. If you want to know what users do after they land, GA4 is unbeaten.

What it cannot do: GA4 has zero visibility into Googlebot. It doesn't see crawl errors, indexing gaps, or how your JavaScript-rendered content appears to search engines. If your React or Next.js app has hydration timing issues, GA4 will happily report "users are visiting" while Googlebot quietly ignores your pages.

Here's a quick GA4 Data API call using Node.js to pull organic landing page data:

// npm install @google-analytics/data
import { BetaAnalyticsDataClient } from '@google-analytics/data';

const analyticsDataClient = new BetaAnalyticsDataClient();

async function getOrganicLandingPages(propertyId) {
  const [response] = await analyticsDataClient.runReport({
    property: `properties/${propertyId}`,
    dateRanges: [{ startDate: '30daysAgo', endDate: 'today' }],
    dimensions: [{ name: 'landingPage' }, { name: 'sessionDefaultChannelGroup' }],
    metrics: [{ name: 'sessions' }, { name: 'bounceRate' }],
    dimensionFilter: {
      filter: {
        fieldName: 'sessionDefaultChannelGroup',
        stringFilter: { value: 'Organic Search' },
      },
    },
  });

  return response.rows.map(row => ({
    page: row.dimensionValues[0].value,
    sessions: row.metricValues[0].value,
    bounceRate: row.metricValues[1].value,
  }));
}

This is useful data, but notice what's missing: there's no ranking data, no impression count, no crawl frequency. GA4 simply doesn't have it. That gap is exactly why a JavaScript SEO checklist needs more than one tool to be actionable.

Looker Studio: Powerful Glue, Not a Native SEO Tool

Looker Studio (formerly Data Studio) is a visualization and data-joining layer. It doesn't generate SEO data; it displays data you've already collected from other sources via connectors.

Where it shines: combining GA4 + Search Console + CRM data into one dashboard. If you're reporting to a non-technical stakeholder who needs a clean visual, Looker Studio is genuinely the right tool.

Where it falls short: it's fundamentally a BI/reporting layer. Building a useful SEO dashboard requires you to already have clean, normalized data sources. The built-in Google Search Console connector is read-only and limited to 16 months. You can't run custom queries or do anything programmatic inside Looker Studio itself.

For teams who need to automate data into Looker Studio, the Community Connector API is worth knowing:

// Looker Studio Community Connector skeleton
function getConfig(request) {
  const config = DataStudioApp.createConfig();
  config.newTextInput()
    .setId('domain')
    .setName('Domain to Analyze')
    .setHelpText('e.g. example.com');
  return config.build();
}

function getSchema(request) {
  const fields = DataStudioApp.createFields();
  fields.newDimension().setId('page_url').setName('Page URL').setType(DataStudioApp.FieldType.TEXT);
  fields.newMetric().setId('organic_clicks').setName('Organic Clicks').setType(DataStudioApp.FieldType.NUMBER);
  fields.newMetric().setId('impressions').setName('Impressions').setType(DataStudioApp.FieldType.NUMBER);
  return { schema: fields.build() };
}

function getData(request) {
  // Fetch from your data source and return rows
  const rows = fetchSEOData(request.configParams.domain);
  return { schema: request.fields, rows };
}

The upshot: Looker Studio is a dashboard, not an SEO tool. Treating it as one leads to fragile, hard-to-maintain setups.

Power SEO Analytics: Where Dedicated Tooling Makes a Difference

When I started evaluating dedicated SEO analytics libraries for a headless Next.js project, I needed something that could track technical SEO signals, including Core Web Vitals, crawl metadata, and structured data validation, not just session behavior.

Power SEO Analytics is a Node.js package built specifically for this gap. It connects to Search Console's full API, surfaces crawl anomalies, and produces structured reports you can pipe into any dashboard (including Looker Studio, if that's your reporting layer). It's also become a reliable way to automate the crawl-side items on a JavaScript SEO checklist, the ones that are easy to verify manually once but painful to monitor continuously.

// npm install power-seo-analytics
import { PowerSEOClient } from 'power-seo-analytics';

const client = new PowerSEOClient({ domain: 'yoursite.com' });

async function auditIndexingHealth() {
  const report = await client.getIndexingReport({
    dateRange: '30d',
    includeRenderingSignals: true,  // Catches JS rendering gaps
    includeCoreWebVitals: true,
  });

  // Returns structured data you can log, store, or send to a dashboard
  console.log(report.crawlErrors);       // Googlebot-specific errors
  console.log(report.renderingIssues);   // JS pages Googlebot can't parse
  console.log(report.coreWebVitals);     // CWV breakdown by page template

  return report;
}

auditIndexingHealth();

The key differentiator: it surfaces Googlebot-perspective data, not user-perspective data. That's the category GA4 misses entirely. For a full walkthrough of integrating this into a CI pipeline, the team's blog at ccbd.dev/blog/power-seo-analytics-vs-looker-studio-vs-ga4 has solid documentation.

Choosing Based on the Question You're Actually Asking

Here's the mental model I now use:

Question	Right Tool
What are users doing on my site?	GA4
How do I visualize this for stakeholders?	Looker Studio
Can Googlebot actually see my content?	Power SEO Analytics / Search Console API
Why did my rankings drop?	All three, in that order

The mistake most developers make is defaulting to GA4 for everything because it's already installed. GA4 is a user analytics tool. Treating it as a crawl health tool is like using browser devtools to debug a server error; you'll see some symptoms but miss the actual cause.

If you're working through a JavaScript SEO checklist, map each item to the tool that actually has the data. Rendering signals belong in a dedicated SEO tool. Behavioral signals belong in GA4. Reporting belongs in Looker Studio. Mixing them up is where debugging time disappears.

Key Takeaways

GA4 is blind to crawlers. Never use it to diagnose indexing or rendering issues on JavaScript-heavy sites.
Looker Studio amplifies data you already have. It doesn't generate SEO signals on its own. Your dashboards are only as good as your upstream data sources.
Dedicated SEO analytics fill the Googlebot-perspective gap that neither GA4 nor Looker Studio cover natively.
For Next.js, Nuxt, or any SSR/SSG app, crawl rendering signals are the first thing to check when traffic drops, before you touch GA4. Keep a JavaScript SEO checklist handy and make sure each item is mapped to the tool that can actually verify it.

Let's Talk About This

Why is SEO analysis for JavaScript websites fundamentally different from traditional static-site SEO?

I have opinions, but I'm curious what your experience has been, especially if you've worked with heavily client-rendered apps. Have you hit the "GA4 looks fine but rankings dropped" trap? What did you find when you dug deeper?

Drop your war stories in the comments. These are the edge cases the documentation never covers.

Next.js for SEO: Why Your App Is Invisible to Google

Mitu Das — Sat, 02 May 2026 05:15:34 +0000

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

After checking Search Console, running a crawl, and nearly rage-quitting, I realized my beautifully crafted SPA was returning a blank <body> to Googlebot. All that content - loaded by JavaScript after the bot had already moved on. Classic. If you've hit this wall, this article will show you exactly how Next.js solves it, what to configure, and how to verify Google can actually read what you built.

Why Client-Side React Fails for SEO (And What's Really Happening)

Here's the uncomfortable truth: Google can render JavaScript - but it puts JS-rendered pages in a second crawl queue that can take days to weeks. Meanwhile, your competitor's server-rendered page gets indexed in hours.

When a bot hits a plain Create React App page, it sees something like this:

<!DOCTYPE html>
<html>
  <head><title>My App</title></head>
  <body>
    <div id="root"></div> <!-- 👈 Nothing here yet -->
  </body>
</html>

No content. No metadata. No structured data. Just a div waiting for a JS bundle to hydrate it.

Next.js changes this by rendering the full HTML on the server before sending it to the client. The bot gets real content on the first byte - no waiting, no second queue.

Setting Up Server-Side Rendering the Right Way

Next.js gives you three rendering strategies. For SEO-critical pages, you want either SSR (getServerSideProps) for dynamic content or SSG (getStaticProps) for content that doesn't change per-request.

Here's a product page using SSR that Google will actually be able to read:

// app/products/[slug]/page.tsx (Next.js 14 App Router)

import { Metadata } from 'next';

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

// This runs on the server - Google gets the full HTML
export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const product = await fetchProduct(params.slug);

  return {
    title: `${product.name} | My Store`,
    description: product.description.slice(0, 155),
    openGraph: {
      title: product.name,
      description: product.description,
      images: [{ url: product.image, width: 1200, height: 630 }],
    },
    alternates: {
      canonical: `https://yoursite.com/products/${params.slug}`,
    },
  };
}

export default async function ProductPage({ params }: Props) {
  const product = await fetchProduct(params.slug);

  return (
    <main>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <span>Price: ${product.price}</span>
    </main>
  );
}

async function fetchProduct(slug: string) {
  const res = await fetch(`https://api.yourstore.com/products/${slug}`, {
    next: { revalidate: 3600 }, // ISR: revalidate every hour
  });
  return res.json();
}

Result: Google crawls this page and immediately sees the <title>, <meta description>, Open Graph tags, and the full product content - all in the initial HTML response.

Structured Data: The SEO Signal Most Devs Skip

Title tags and meta descriptions are table stakes. Structured data (JSON-LD) is where you unlock rich results - star ratings, breadcrumbs, FAQs - directly in the SERP. Almost nobody does this properly.

Here's a reusable component that injects JSON-LD without a library:

// components/JsonLd.tsx

type JsonLdProps = {
  data: Record<string, unknown>;
};

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

// Usage in your product page:
import { JsonLd } from '@/components/JsonLd';

export default async function ProductPage({ params }: Props) {
  const product = await fetchProduct(params.slug);

  const structuredData = {
    '@context': 'https://schema.org',
    '@type': 'Product',
    name: product.name,
    description: product.description,
    image: product.image,
    offers: {
      '@type': 'Offer',
      price: product.price,
      priceCurrency: 'USD',
      availability: 'https://schema.org/InStock',
    },
  };

  return (
    <main>
      <JsonLd data={structuredData} />
      <h1>{product.name}</h1>
      <p>{product.description}</p>
    </main>
  );
}

Deploy this and validate your schema using Google Search Console's coverage report. If it passes, you're eligible for enhanced listings.

Measuring What Actually Matters: Core Web Vitals + Crawlability

Writing good code is step one. Knowing whether Google agrees is step two. Most devs skip the verification loop and wonder why rankings don't move.

A few things worth automating:

1. Verify your pages are actually being server-rendered

curl -A "Googlebot" https://yoursite.com/products/your-slug | grep "<h1>"

If you see your <h1> content in the terminal output, you're good. If you see nothing - SSR isn't working.

2. Generate a sitemap automatically

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

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

  return products.map((product) => ({
    url: `https://yoursite.com/products/${product.slug}`,
    lastModified: new Date(product.updatedAt),
    changeFrequency: 'weekly',
    priority: 0.8,
  }));
}

Next.js will serve this at /sitemap.xml automatically. Submit it in Google Search Console.

3. Audit your metadata at scale

When you have dozens of pages, manually checking each one breaks down fast. For this, I've been using @power-seo - an npm package that crawls your Next.js routes and flags missing titles, duplicate descriptions, broken canonical tags, and missing structured data in one pass.

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

It's not magic - it's the same checks you'd do manually, but automated. The output is a JSON report you can pipe into CI to fail builds when critical SEO tags are missing. For a deeper walkthrough of the full configuration, the Next.js SEO complete guide covers integrating it with GitHub Actions.

What I Learned (After Getting It Wrong First)

SSR alone isn't enough. You can server-render perfectly and still tank on Core Web Vitals. LCP, CLS, and FID are ranking signals - use Next.js Image component, font optimization, and avoid layout shifts from async data loads.
Canonical tags matter more than you think. If your product pages are accessible at multiple URLs (with/without trailing slash, with query params), Google splits link equity across them. One canonical tag fixes this.
generateMetadata is not optional for dynamic routes. Static pages can get away with a global layout metadata. Dynamic routes need per-page metadata or you'll have dozens of pages sharing the same title.
Automate your SEO checks before they become surprises. A missing <title> on a high-traffic page can sit unnoticed for weeks. Build the audit into your pipeline - whether that's @power-seo, a Lighthouse CI run, or a custom script.

Let's Talk About This

Here's something worth discussing: Why is SEO analysis for JavaScript websites fundamentally different from traditional HTML site analysis?

Most SEO tools were built assuming HTML is what the server sends. But with JS frameworks, the "real" HTML only exists after execution. That gap changes everything - from how you audit, to how you structure data, to how you think about crawl budget.

Drop your thoughts in the comments. Have you hit crawlability issues with React or Next.js? What solved it for you? I'm especially curious whether anyone's had luck with dynamic rendering as a fallback versus going full SSR.

Forem: Mitu Das

SEO Mistakes That Are Silently Killing Your Dev Projects

Mistake #1: Your <head> Is Almost Empty

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

Mistake #3: You Have No Structured Data

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

What I Actually Learned

What's Your Biggest SEO Headache?

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

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

Auditing Structured Data and Open Graph Tags Programmatically

Automating Multi-Page Audits with a Crawl Script

Going Deeper: When You Need More Than a Script

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

What's your biggest JavaScript SEO headache?

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

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

1. Add Product Structured Data (JSON-LD)

2. Dynamic Meta Tags Per Product Page

3. Canonical URLs and Faceted Navigation

4. Automating This Across a Large Catalog

What I Learned

What's Your Biggest E-commerce SEO Headache?

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

The React SEO Problem Nobody Notices Until Production

The Fastest Fix Is Injecting OG Tags Server Side

Step 1: Create an Express server

Step 2: Add placeholders to index.html

Result

Dynamic OG Images Improve CTR More Than Most Developers Expect

Result

A Cleaner Approach Using @power-seo

How to Verify Your Open Graph Tags Actually Work

Twitter Card Validator

LinkedIn Post Inspector

Facebook Sharing Debugger

Common Open Graph React SEO Mistakes

1. Using React Helmet Alone

2. Forgetting Absolute URLs

3. Wrong Image Size

4. Not Caching OG Images

What I Learned

React SEO Guide: Making Google Actually See Your React App

Why React Apps Are Invisible to Search Engines

The result:

The real issue:

Step 1: Add Proper Meta Tags (Baseline Fix)

What changed?

Result:

Step 2: Server Side Rendering or Pre rendering

Option A: SSR with Node and Express

What this fixes:

Option B: Static pre rendering

Step 3: Automating SEO Without Manual Meta Work

Why this helps in real projects:

Result:

Step 4: Invisible SEO Factors Developers Miss

1. Semantic HTML

2. Clean URL structure

3. Sitemap generation

What I Learned (Key Takeaways)

React vs WordPress: Why I Stopped Fighting the SEO Battle and Started Automating It

The Real Reason WordPress Still Wins on SEO (It's Not Magic)

Step 1: Stop Relying on document.title. Use a Proper Head Manager

Step 2: Generate Your Sitemap Automatically (Not Manually)

Step 3: Automate Meta Generation for Content-Heavy Apps

Step 4: Validate Before You Ship

What I Learned

Your Turn

SEO Checklist for JavaScript Apps: Fix Your Rankings Before Your Next Deploy

SEO Checklist Step 1: Solve the JavaScript Rendering Problem First

SEO Checklist Step 2: Meta Tags on Every Route, Not Just the Homepage

SEO Checklist Step 3: Structured Data, the Signal Most JavaScript Devs Skip

SEO Checklist Step 4: Automate the Audit So Nothing Gets Skipped

Key Takeaways

Your Turn

Next.js SEO in 2026: The Stuff That Actually Moved My Rankings

Why Most Next.js Apps Still Have SEO Problems

1. Centralize Metadata Instead of Repeating It Everywhere

Reusable SEO Utility

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

Step 2: Add placeholders to `index.html`

Step 1: Stop Relying on `document.title`. Use a Proper Head Manager