Forem: Alamin Sarker

How to Design a Modern Website in 2026: A Developer's Practical Guide

Alamin Sarker — Tue, 21 Apr 2026 06:57:31 +0000

The Problem Nobody Talks About

You've read the articles. You've followed the tutorials. You've picked Tailwind, maybe Radix or shadcn/ui, and you're using React like everyone told you to.

And then your "modern" site still feels like it was built in 2019.

Here's the uncomfortable truth: most "modern website" advice recycles the same stack choices without addressing why certain patterns work — or what the web actually demands from a site in 2026. Core Web Vitals are now a hard ranking factor. Container queries have been baseline for two years. The CSS you're writing is still fighting the browser instead of working with it.

This article won't tell you to "just use Next.js." It'll show you the actual decisions — layout, performance, rendering, discoverability — that separate a site that looks modern from one that performs like it.

1. Layout: Stop Using Flexbox for Everything

Flexbox is one-dimensional. That's fine — until you're using it to approximate a two-dimensional grid and your alignment code looks like a tax return.

CSS Grid has been baseline since 2020. In 2026, there's no excuse not to use it for page-level layout. Here's a clean, modern approach:

/* Modern page scaffold — works without any framework */
.page-layout {
  display: grid;
  grid-template-columns:
    [full-start] minmax(1rem, 1fr)
    [content-start] min(65ch, 100%)
    [content-end] minmax(1rem, 1fr)
    [full-end];
}

.page-layout > * {
  grid-column: content;
}

.page-layout > .full-bleed {
  grid-column: full;
}

This pattern — named grid lines with a 65ch prose column — gives you a typographically sound content width and a clean escape hatch for full-bleed hero images or banners. No media queries needed for the basic structure.

Layer in container queries for components:

@container (min-width: 40rem) {
  .card-grid {
    grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
  }
}

The shift here is mental: page layout via Grid, component responsiveness via container queries. Your components stop caring about the viewport and start responding to where they actually live.

2. Performance: The Metrics That Actually Get You Ranked

Google's ranking algorithm weighs three Core Web Vitals: LCP (Largest Contentful Paint), INP (Interaction to Next Paint, which replaced FID in 2024), and CLS (Cumulative Layout Shift).

The most common LCP killer I see isn't server speed — it's hero images without proper hints:

<!-- Without this, your LCP image waits in the browser's queue -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />

<!-- The image itself -->
<img
  src="/hero.webp"
  alt="Product dashboard screenshot"
  width="1200"
  height="630"
  fetchpriority="high"
  decoding="async"
/>

That fetchpriority="high" attribute alone can shave 300–600ms off LCP. Pair it with explicit width and height to eliminate layout shift (CLS).

For INP, the pattern that causes the most silent damage is heavy main-thread work during interactions. Offload it:

// Instead of blocking the main thread:
button.addEventListener('click', async () => {
  // Yield to the browser before doing heavy work
  await scheduler.yield();
  runExpensiveCalculation();
});

scheduler.yield() is now baseline in all major browsers. It's one line that makes your site feel snappier without rewriting your architecture.

3. Discoverability: The Part Developers Actually Skip

Here's a pattern I see constantly: developers spend weeks on the UI, then drop 4 meta tags in <head> and call it "SEO done."

Metadata in 2026 is a structured problem. Search engines, social platforms, and AI crawlers all consume it differently. You need at minimum:

<head>
  <title>How to Design a Modern Website | Your Site</title>
  <meta name="description" content="A practical guide to modern web design in 2026, covering CSS Grid, Core Web Vitals, and structured metadata." />

  <!-- Open Graph (Facebook, LinkedIn, Discord unfurls) -->
  <meta property="og:title" content="How to Design a Modern Website in 2026" />
  <meta property="og:description" content="Practical patterns for layout, performance, and discoverability." />
  <meta property="og:image" content="https://yoursite.com/og/modern-website-2026.png" />
  <meta property="og:type" content="article" />

  <!-- Twitter/X cards -->
  <meta name="twitter:card" content="summary_large_image" />
  <meta name="twitter:title" content="How to Design a Modern Website in 2026" />

  <!-- Canonical (critical for syndicated content) -->
  <link rel="canonical" href="https://yoursite.com/blog/how-to-design-a-modern-website" />

  <!-- JSON-LD for structured data -->
  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "TechArticle",
    "headline": "How to Design a Modern Website in 2026",
    "author": { "@type": "Person", "name": "Your Name" },
    "datePublished": "2026-04-21"
  }
  </script>
</head>

Writing this by hand for every page is tedious and error-prone. I've been using @power-seo to automate it — it generates the full tag set from a single config object and keeps canonical URLs consistent across environments. You can see a working example of this setup at ccbd.dev.

But even if you don't use a package: write the tags. All of them. Every time.

4. Component Architecture: Composition Over Configuration

The trend that's quietly won in 2026 is headless, composable UI — Radix primitives, your own design tokens, styled with vanilla CSS or Tailwind. The "everything-in-one" component libraries are losing ground because they're harder to customize and bloat your bundle.

Here's a minimal card component that reflects current best practice:

// card.jsx — composable, accessible, no library dependency
export function Card({ children, as: Tag = 'article', className = '' }) {
  return (
    <Tag className={`card ${className}`}>
      {children}
    </Tag>
  );
}

Card.Header = function CardHeader({ children }) {
  return <header className="card__header">{children}</header>;
};

Card.Body = function CardBody({ children }) {
  return <div className="card__body">{children}</div>;
};

// Usage:
// <Card>
//   <Card.Header><h2>Title</h2></Card.Header>
//   <Card.Body><p>Content</p></Card.Body>
// </Card>

The compound component pattern keeps API surface small, slots flexible, and lets you upgrade the internals without breaking consumers.

What I Actually Learned

CSS Grid + container queries is the layout combo you should be using by default in 2026 — flexbox is for component internals, not page structure.
fetchpriority="high" on your hero image is the easiest LCP win most sites haven't shipped yet.
scheduler.yield() is one line of code that makes event handlers feel instant — stop sleeping on it.
Metadata is a system, not an afterthought. OG tags, canonical URLs, and JSON-LD are table stakes. Automate them so they're never forgotten.

If you want to explore the metadata approach in more depth, here's the writeup: https://ccbd.dev/blog/how-to-design-a-modern-website-in-2026

Let's Argue About It

Here's my genuine question for the thread: do you think React apps can rank well on Google in 2026 without SSR? I have opinions, but I've also been wrong before — the crawl behavior has changed enough times that I'm not fully confident.

Drop your experience in the comments. Have you seen client-rendered React pages ranking competitively, or is SSR/SSG still a hard requirement for discoverability? Real data points welcome.

How to Optimize React & Next.js Apps for SEO and Rank Faster

Alamin Sarker — Mon, 20 Apr 2026 06:20:29 +0000

I spent 3 hours debugging why Google couldn't see my React app. Turns out, Googlebot was rendering a blank white page — because my entire content lived inside client-side JavaScript that hadn't loaded yet. The fix was 4 lines of code. But getting to those 4 lines cost me a week of confused Google Search Console reports, zero indexed pages, and a growing suspicion that SEO for single-page applications is fundamentally broken.

It's not broken. It's just different — and most tutorials skip the hard parts.

In this article, you'll learn exactly why SPAs struggle with SEO, how to fix the core rendering problem in Next.js, how to wire up dynamic meta tags properly, and how to generate sitemaps that actually get crawled. All with copy-paste ready code.

Why Google Struggles With React SPAs (And What's Actually Happening)

Google's crawler fetches your URL, gets an HTML file, and parses it. With a traditional server-rendered page, that HTML contains your actual content. With a client-side React SPA, that HTML contains roughly this:

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

No content. No headings. No text for Google to index.

Google can execute JavaScript — but it does so in a second wave, sometimes days or weeks later, using an older version of Chrome. That delay alone can tank your indexing. And even when it does render your JS, dynamic <title> and <meta> tags set via document.title are unreliable.

The solution isn't to abandon React. It's to move rendering to the server so that the HTML Googlebot receives already contains your content.

Fix 1: Use Next.js Server-Side Rendering for Content Pages

If you're on plain Create React App, migrating to Next.js is the single highest-leverage move you can make for SEO. Next.js gives you getServerSideProps and getStaticProps — both of which ensure your HTML is populated before it hits the browser or a crawler.

Here's the difference in practice:

// ❌ Client-side only — invisible to Googlebot on first pass
export default function BlogPost() {
  const [post, setPost] = useState(null);

  useEffect(() => {
    fetch(`/api/posts/${id}`).then(r => r.json()).then(setPost);
  }, []);

  return <article>{post?.content}</article>;
}

// Server-side rendered — content in HTML immediately
export async function getStaticProps({ params }) {
  const post = await fetchPostFromCMS(params.slug);

  return {
    props: { post },
    revalidate: 60, // ISR: regenerate every 60 seconds
  };
}

export default function BlogPost({ post }) {
  return <article>{post.content}</article>;
}

With getStaticProps + Incremental Static Regeneration (ISR), your pages are pre-built as static HTML, served instantly from a CDN, and refreshed in the background when content changes. For most content-heavy pages — blogs, product listings, docs — this is the right default.

Use getServerSideProps only when content must be real-time per-request (e.g., personalized dashboards). Static beats dynamic for SEO almost every time.

Fix 2: Dynamic Meta Tags That Actually Work

This is where most React SEO tutorials go wrong. Setting document.title = "My Page" in a useEffect is unreliable — crawlers often don't execute it. You need your <title> and <meta> tags in the initial HTML response.

In Next.js, use the <Head> component from next/head (or the newer generateMetadata in the App Router):

// pages/blog/[slug].jsx — Pages Router
import Head from 'next/head';

export default function BlogPost({ post }) {
  return (
    <>
      <Head>
        <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} />
        <meta property="og:type" content="article" />
        <link rel="canonical" href={`https://yourdomain.com/blog/${post.slug}`} />
      </Head>
      <article>
        <h1>{post.title}</h1>
        <div dangerouslySetInnerHTML={{ __html: post.content }} />
      </article>
    </>
  );
}

// app/blog/[slug]/page.jsx — App Router (Next.js 13+)
export async function generateMetadata({ params }) {
  const post = await fetchPost(params.slug);

  return {
    title: `${post.title} | My Blog`,
    description: post.excerpt,
    openGraph: {
      title: post.title,
      description: post.excerpt,
      images: [post.coverImage],
    },
    alternates: {
      canonical: `https://yourdomain.com/blog/${post.slug}`,
    },
  };
}

The canonical tag is easy to overlook but critical — it prevents duplicate content penalties when the same post is accessible via multiple URLs (e.g., with and without trailing slashes, or via pagination params).

Fix 3: Generate a Sitemap That Scales

A sitemap tells Google which URLs exist on your site and when they were last updated. Without one, Google has to discover your pages by crawling links — which means new content can take weeks to get indexed.

Here's a dynamic sitemap generator for Next.js that pulls from your CMS:

// pages/sitemap.xml.jsx
export async function getServerSideProps({ res }) {
  const posts = await fetchAllPosts(); // your CMS fetch
  const staticRoutes = ['/', '/about', '/blog'];

  const sitemap = `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  ${staticRoutes.map(route => `
  <url>
    <loc>https://yourdomain.com${route}</loc>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
  </url>`).join('')}
  ${posts.map(post => `
  <url>
    <loc>https://yourdomain.com/blog/${post.slug}</loc>
    <lastmod>${new Date(post.updatedAt).toISOString()}</lastmod>
    <changefreq>weekly</changefreq>
    <priority>0.6</priority>
  </url>`).join('')}
</urlset>`;

  res.setHeader('Content-Type', 'text/xml');
  res.setHeader('Cache-Control', 's-maxage=86400, stale-while-revalidate');
  res.write(sitemap);
  res.end();

  return { props: {} };
}

export default function Sitemap() { return null; }

Submit this URL in Google Search Console under Sitemaps. The Cache-Control header ensures it's cached for 24 hours at the CDN level without going stale.

For teams managing SEO metadata at scale across many pages, a package called @power-seo provides a structured schema layer on top of Next.js metadata — it's particularly useful when you need to enforce consistent OG tags and structured data (JSON-LD) across dozens of content types without repeating the same <Head> boilerplate in every template.

What I Learned (Key Takeaways)

Client-side rendering is the enemy of fast indexing. Move content pages to getStaticProps with ISR — it's the lowest-effort, highest-impact change you can make.
Meta tags belong in the server response, not in useEffect. Use next/head or generateMetadata. If Googlebot doesn't see it in the raw HTML, it's unreliable.
Canonical tags are not optional. Duplicate URLs without canonicals are a silent SEO tax that compounds over time.
Submit your sitemap and verify in Search Console. Don't assume Google will find your pages — tell it where they are and how often they change.

If you want to dig deeper into the patterns covered here, I wrote a longer breakdown with benchmarks and more edge cases at ccbd.dev.

Your Turn

Can React apps actually rank on Google? Yes — but only if you stop treating SEO as a post-launch concern and bake it into your rendering architecture from the start.

What's the trickiest SEO issue you've hit building SPAs?
Have you found SSR to be overkill for certain use cases, or do you go static-first by default now? Drop it in the comments — I'm curious what the community's experience has been.

How to Build a Provider-Agnostic AI SEO Pipeline in Next.js

Alamin Sarker — Sun, 19 Apr 2026 05:14:34 +0000

I spent an entire sprint ripping out OpenAI calls from a client's Next.js app because they wanted to switch to Anthropic. Every metadata generator, every schema builder, every keyword cluster — all tightly coupled to one SDK. Three days of refactoring for what should have been a config change.

That experience turned into an obsession: build an AI SEO tool pipeline that treats the model as a swappable dependency, not the foundation. In this article I'll show you the exact pattern — a provider-agnostic adapter layer in Next.js that generates SEO metadata, structured schema, and keyword suggestions without locking you into any single vendor.

The Problem with Most AI SEO Integrations

Most tutorials go straight to openai.chat.completions.create(...) inside a Route Handler and call it done. That works until:

Your client wants to use their own API key on a different provider
OpenAI raises prices and Gemini Flash is suddenly 10x cheaper
You want to A/B test output quality across models

The fix isn't clever prompt engineering. It's architecture.

Here's the pattern: define a SeoProvider interface, implement it for each vendor, and inject the right one at runtime via an environment variable. Your Next.js App Router handlers never import a specific SDK — they only talk to the interface.

Step 1: Define the Provider Interface

Create a shared type that all providers must satisfy:

// lib/seo/types.ts

export interface SeoInput {
  url: string;
  pageContent: string;
  targetKeyword?: string;
}

export interface SeoOutput {
  title: string;
  description: string;
  keywords: string[];
  schema: Record<string, unknown>;
}

export interface SeoProvider {
  generate(input: SeoInput): Promise<SeoOutput>;
}

That's your contract. Nothing else in the app needs to know which model is running.

Step 2: Implement Concrete Adapters

Now write one adapter per provider. They all implement the same interface:

// lib/seo/providers/openai.ts
import OpenAI from "openai";
import { SeoProvider, SeoInput, SeoOutput } from "../types";

export class OpenAIProvider implements SeoProvider {
  private client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

  async generate(input: SeoInput): Promise<SeoOutput> {
    const prompt = buildPrompt(input); // shared prompt builder (see below)

    const res = await this.client.chat.completions.create({
      model: "gpt-4o-mini",
      messages: [{ role: "user", content: prompt }],
      response_format: { type: "json_object" },
    });

    return JSON.parse(res.choices[0].message.content ?? "{}");
  }
}

// lib/seo/providers/anthropic.ts
import Anthropic from "@anthropic-ai/sdk";
import { SeoProvider, SeoInput, SeoOutput } from "../types";

export class AnthropicProvider implements SeoProvider {
  private client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY });

  async generate(input: SeoInput): Promise<SeoOutput> {
    const prompt = buildPrompt(input);

    const res = await this.client.messages.create({
      model: "claude-3-5-haiku-20241022",
      max_tokens: 1024,
      messages: [{ role: "user", content: prompt }],
    });

    const text = res.content[0].type === "text" ? res.content[0].text : "";
    return JSON.parse(text);
  }
}

Both use the same buildPrompt function:

// lib/seo/prompt.ts
import { SeoInput } from "./types";

export function buildPrompt(input: SeoInput): string {
  return `
    Analyze the following web page content and return a JSON object with these fields:
    - title: SEO-optimized page title (50-60 chars)
    - description: meta description (150-160 chars)
    - keywords: array of 8-10 relevant keywords
    - schema: a JSON-LD Article schema object

    Target keyword: ${input.targetKeyword ?? "none specified"}
    URL: ${input.url}

    Page content:
    ${input.pageContent.slice(0, 3000)}

    Return ONLY valid JSON. No markdown, no explanation.
  `;
}

The prompt is provider-agnostic — the same text goes to any model.

Step 3: The Provider Factory + Route Handler

Wire everything together with a factory function and a single API route:

// lib/seo/factory.ts
import { SeoProvider } from "./types";
import { OpenAIProvider } from "./providers/openai";
import { AnthropicProvider } from "./providers/anthropic";

export function getSeoProvider(): SeoProvider {
  const provider = process.env.SEO_AI_PROVIDER ?? "openai";

  switch (provider) {
    case "anthropic":
      return new AnthropicProvider();
    case "openai":
    default:
      return new OpenAIProvider();
  }
}

// app/api/seo/route.ts
import { NextRequest, NextResponse } from "next/server";
import { getSeoProvider } from "@/lib/seo/factory";

export async function POST(req: NextRequest) {
  const body = await req.json();
  const { url, pageContent, targetKeyword } = body;

  if (!url || !pageContent) {
    return NextResponse.json({ error: "Missing required fields" }, { status: 400 });
  }

  try {
    const provider = getSeoProvider();
    const result = await provider.generate({ url, pageContent, targetKeyword });
    return NextResponse.json(result);
  } catch (err) {
    console.error("[SEO Pipeline Error]", err);
    return NextResponse.json({ error: "Generation failed" }, { status: 500 });
  }
}

Switch providers by changing one env var:

# .env.local
SEO_AI_PROVIDER=anthropic   # or "openai", or whatever you add next

No code changes. No refactoring sprint.

Step 4: Consuming It from Your Frontend

A simple hook to call the pipeline from a Next.js page:

// hooks/useSeoGenerator.ts
import { useState } from "react";
import { SeoOutput } from "@/lib/seo/types";

export function useSeoGenerator() {
  const [result, setResult] = useState<SeoOutput | null>(null);
  const [loading, setLoading] = useState(false);

  async function generate(url: string, pageContent: string, targetKeyword?: string) {
    setLoading(true);
    try {
      const res = await fetch("/api/seo", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ url, pageContent, targetKeyword }),
      });
      const data = await res.json();
      setResult(data);
    } finally {
      setLoading(false);
    }
  }

  return { result, loading, generate };
}

Call it from any component:

const { result, loading, generate } = useSeoGenerator();

// On button click or form submit:
await generate("https://example.com/blog/post", articleText, "Next.js SEO");

// result now contains title, description, keywords, schema — ready to inject

You now have a working AI SEO tool pipeline that runs entirely on your infrastructure, with the provider as a runtime config value.

Bonus: Where a Dedicated SEO Package Saves Time

The adapter pattern above handles the AI layer, but you still need to handle things like robots.txt generation, sitemap injection, JSON-LD rendering, and keyword clustering logic. Rolling all of that from scratch adds up.

This is where I started using @power-seo as the pipeline's output consumer — it takes the structured JSON your provider generates and handles the Next.js <Head> injection, schema rendering, and sitemap updates automatically. Worth checking out if you want to skip that plumbing. There's also a deeper writeup on using it with this exact adapter pattern over at ccbd.dev.

What I Learned

Couple to the interface, not the SDK. The 30 minutes you spend writing an adapter pays back every time you switch models — and you will switch models.
Keep prompts in a shared module. Provider-specific quirks (like Anthropic's JSON formatting behavior) belong in the adapter, not the prompt. One prompt file means one place to improve output quality.
Use response_format: json_object (OpenAI) or explicit JSON instructions (Anthropic) — don't parse unstructured text from a model if you need structured data. You'll lose hours chasing intermittent parse errors.
Test with the cheapest model first. GPT-4o-mini and Claude Haiku are fast and cheap enough to run on every save in development. Use the heavyweight models only when you're tuning final output quality.

If you want to try this approach, here's the full writeup with repo links: https://ccbd.dev/blog/ai-seo-tool-that-works-with-every-llm-a-developers-guide-in-2026

What's your setup?

Genuinely curious: what is the best AI SEO tool for Next.js developers in 2026? Are you rolling your own pipeline, using a SaaS wrapper, or going full DIY with raw API calls? Drop your stack in the comments — especially if you've found a clever way to handle provider fallback when rate limits hit.

Stop Letting Googlebot Guess Fix Your React App's SEO Right

Alamin Sarker — Thu, 16 Apr 2026 06:34:53 +0000

I spent 3 hours debugging why Google couldn't index my React app. I checked robots.txt, verified the sitemap, and re-read Google Search Console docs twice. The fix turned out to be 4 lines of code I was missing in every single route. If you've ever shipped a React SPA and wondered why your pages weren't showing up in search results — this one's for you. By the end of this article, you'll know exactly why Googlebot struggles with SPAs, how to fix it with SSR or pre-rendering, and how to manage meta tags dynamically without losing your mind.

Why Googlebot Struggles With React SPAs

Here's the uncomfortable truth: Googlebot can execute JavaScript — but it doesn't do it the same way your browser does.

When Googlebot crawls a plain HTML page, it reads content immediately. When it hits a React SPA, it has to:

Download the JS bundle
Execute React
Wait for data fetches to resolve
Then read the DOM

That "wait" is the problem. Google runs JS crawling in a secondary wave that can be delayed by days. Worse, if your app does anything async before rendering visible text — an API call, a loading spinner, a suspense boundary — Googlebot might index the blank shell instead of your actual content.

Here's a simple test. In your browser, do View Page Source (not DevTools — actual source). If you see a nearly empty <div id="root"></div>, that's what Googlebot sees too, at least initially.

# Quick sanity check — fetch your page like Googlebot does
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1)" https://yoursite.com/your-page

If that curl returns minimal HTML, you have a problem worth solving.

Fix 1: Add Dynamic Meta Tags Per Route

Even if Googlebot eventually renders your page, without proper <title> and <meta> tags per route, your SEO is just guesswork. A single static title in index.html means every page on your site looks identical to a search crawler.

The most common fix is react-helmet-async:

npm install react-helmet-async

Wrap your app:

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

function App() {
  return (
    <HelmetProvider>
      <Router>
        <Routes />
      </Router>
    </HelmetProvider>
  );
}

Then in each page component, declare exactly what that page should tell search engines:

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

function BlogPost({ post }) {
  return (
    <>
      <Helmet>
        <title>{post.title} | My Blog</title>
        <meta name="description" content={post.excerpt} />
        <meta property="og:title" content={post.title} />
        <meta property="og:description" content={post.excerpt} />
        <meta property="og:image" content={post.coverImage} />
        <link rel="canonical" href={`https://myblog.com/posts/${post.slug}`} />
      </Helmet>

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

Result: Every route now has unique, crawlable metadata. No more Google showing "React App" as the title for your carefully-written product pages.

Fix 2: Pre-render Static Routes (Without Full SSR)

Full server-side rendering with Next.js is the gold standard, but it's not always an option — especially if you're maintaining an existing Vite or CRA app you don't want to rewrite.

Pre-rendering is the middle ground. You generate static HTML snapshots of your routes at build time, so crawlers always get real content without waiting for JS.

vite-plugin-ssg (for Vite) or react-snap work well for this. Here's a practical setup with vite-plugin-ssg:

npm install vite-plugin-ssg

// vite.config.js
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import { VitePluginSSG } from 'vite-plugin-ssg';

export default defineConfig({
  plugins: [react(), VitePluginSSG()],
});

// src/main.jsx — change the export pattern
import { ViteSSG } from 'vite-plugin-ssg';
import App from './App';
import routes from './routes';

export const createApp = ViteSSG(App, { routes });

Run vite build and you'll get pre-rendered HTML for every route defined in your router. Googlebot hits real HTML — no JS execution needed.

Result: Your /about, /pricing, and /blog/[slug] pages all arrive as fully-formed HTML. Crawl budget is used efficiently, and indexing happens in the first wave, not the secondary JS queue.

Fix 3: Automate Structured Data (JSON-LD)

This one is often skipped entirely, but structured data is how you communicate meaning to search engines — not just content. It's how you get rich snippets, FAQ dropdowns, and review stars in SERPs.

Adding it manually to every page is tedious and error-prone. A cleaner pattern is a reusable component:

// components/StructuredData.jsx
function StructuredData({ type, data }) {
  const schema = {
    '@context': 'https://schema.org',
    '@type': type,
    ...data,
  };

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

// Usage in a product page
function ProductPage({ product }) {
  return (
    <>
      <Helmet>
        <title>{product.name}</title>
      </Helmet>

      <StructuredData
        type="Product"
        data={{
          name: product.name,
          description: product.description,
          image: product.imageUrl,
          offers: {
            '@type': 'Offer',
            price: product.price,
            priceCurrency: 'USD',
          },
        }}
      />

      <main>{/* your page content */}</main>
    </>
  );
}

No library needed — just a wrapper around a <script> tag that keeps your schema co-located with your components rather than buried in config files.

Fix 4: Use a Meta Tag Management Package When It Gets Complex

Once you're managing dozens of routes, dynamic OG images, canonical URLs, and multiple schema types, maintaining all of it by hand becomes a real liability. This is where dedicated tooling helps.

One package worth knowing about is @power-seo, which consolidates meta tag management, structured data injection, and sitemap generation into a single API. I came across it while building a content-heavy app for ccbd.dev and found it useful for keeping SEO logic out of individual page components.

npm install @power-seo

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

function ArticlePage({ article }) {
  return (
    <>
      <SEOHead
        title={article.title}
        description={article.summary}
        canonical={`https://ccbd.dev/articles/${article.slug}`}
        openGraph={{
          type: 'article',
          image: article.ogImage,
          publishedTime: article.publishedAt,
        }}
        schema={{
          type: 'Article',
          headline: article.title,
          author: article.author,
        }}
      />
      <article>{/* content */}</article>
    </>
  );
}

It's not magic — under the hood it's doing the same things I showed you above. But for larger projects, the unified API reduces the chance of someone adding a page and forgetting the canonical tag or the OG image. Use it if you're maintaining a team codebase where consistency matters more than control.

What I Learned (The Hard Way)

View Page Source is your most honest SEO audit tool. DevTools lies to you — it shows you the rendered DOM. Page Source shows you what crawlers actually receive first.
Pre-rendering beats SSR for most content sites. Unless you need real-time personalization, static HTML snapshots are faster to serve, simpler to deploy, and crawlers love them.
One missing canonical tag can cause duplicate content penalties. If your React router allows /about and /about/ to both resolve, add a canonical on every page. No exceptions.
Structured data is the SEO multiplier nobody talks about enough. Getting your pages indexed is step one; getting rich snippets is step two and it's almost free if you add JSON-LD from day one.

If you want to explore the meta management approach further, the @power-seo npm package is at: https://www.npmjs.com/package/@power-seo/react

How Does Your Team Handle This?

I'm genuinely curious — are you using Next.js for SSR from the start, or retrofitting SEO onto an existing SPA? Have you found pre-rendering good enough, or did you eventually migrate to a framework with built-in SSR?

Drop a comment below. These are the kinds of tradeoffs that rarely have a clean universal answer, and the real-world context from other projects is always more useful than any tutorial (including this one).