Coder Legion - Recent posts tagged metadata

Strip EXIF and AI Metadata in the Browser Before Instagram Upload

Mon, 14 Sep 2026 16:35:45 +0000

Most developers treat social uploads as a product problem for marketers. In practice it is also a metadata problem.

When a creator exports a still from CapCut, Lightroom, or an AI-assisted editor, the file can still carry EXIF, XMP, GPS, and provenance-style tags. Instagram may rewrite some of that on ingest, but leaving a dirty master in the upload path is still a bad habit—especially if the same asset later goes to email, marketplaces, or another app that preserves more of the container.

What usually leaks

GPS and capture time
Camera / software strings
Editor or generative-tool fingerprints that platforms may treat as AI-related signals

You do not need a desktop EXIF suite for every batch. A browser-side scrub of a social copy is enough for many workflows, as long as the original stays untouched in your archive.

A boring workflow that works

Keep the master file offline.
Duplicate a social-ready copy.
Strip location and AI-related metadata from that copy only.
Move the cleaned file to the phone / IG app.
Upload from the cleaned file—not from camera roll originals.

If you want a quick desktop step before the phone transfer, I use this free Instagram tool for a one-pass scrub: https://removeailabel.com/instagram

Why this belongs in a developer checklist

Ship checklists already cover secrets, PII in logs, and signed URLs. Image containers deserve the same skepticism. Treat every upload as an export boundary: originals stay rich; public copies stay minimal.

That is it—no magic, just fewer accidental leaks before the post button.

The Complete Technical SEO Checklist for Next.js Developers (2026 Guide)

Sun, 09 Aug 2026 05:53:15 +0000

You can write the best blog post in your niche, ship a beautifully designed landing page, and still get zero organic traffic — because Google never properly crawled it, never understood what it was, or ranked a slower competitor above it instead. That's the frustrating part of SEO nobody warns you about: content quality is only half the battle. The other half is technical SEO — the plumbing that decides whether search engines can find, understand, and trust your pages in the first place.

The good news is that technical SEO isn't a mystery box. It's a checklist. Once you know what to check, most of it takes an afternoon to fix in a Next.js app — no marketing degree required.

By the end of this guide, you'll have a complete, practical checklist covering crawlability, metadata, structured data, Core Web Vitals, and content quality — with real Next.js 16 App Router code for each item.

Why Technical SEO Is Different From "Writing Good Content"

Content SEO is about what you say. Technical SEO is about whether search engines can even reach what you said. A page can have perfect content and still fail because:

It's blocked in robots.txt by accident
It has no canonical URL, so Google indexes three duplicate versions of it
It loads so slowly that Google deprioritizes it in rankings
It has no structured data, so it never qualifies for rich results

None of these are content problems — they're implementation problems. And implementation problems are exactly what a developer is best positioned to fix.

Why Technical SEO Matters for AI Search Too

In 2026, "search" doesn't just mean the Google results page anymore. Tools like ChatGPT, Gemini, Claude, and Perplexity all crawl and cite web pages when answering questions — and the exact same fundamentals that help Google rank you are what let these AI systems find, parse, and trust your content in the first place.

Structured data gives AI systems an unambiguous, machine-readable summary of what a page is — an article, a product, a FAQ — instead of forcing them to guess from raw HTML.
Semantic HTML (real <h1>–<h3> headings, <article>, <nav>, proper list elements instead of div soup) makes it far easier for any crawler, AI or otherwise, to understand a page's structure and pull an accurate answer out of it.
Crawlable pages — no accidental noindex, no content trapped behind client-side-only rendering with nothing in the initial HTML — matter just as much to an AI crawler as to Googlebot. If a bot can't fetch it, it can't cite it.

The practical takeaway: none of this requires a separate "AI SEO" strategy. Everything in this checklist already does double duty — it's the same groundwork that gets a page indexed by Google, ranked well, and eligible to be cited by an AI assistant.

1. Crawlability & Indexing

Before Google can rank your page, it has to find it and be allowed to index it. This is the foundation — get it wrong and nothing else on this list matters.

Add a `robots.txt`

robots.txt tells search engine crawlers which parts of your site they're allowed to visit. In Next.js, you don't write raw text — you export a config from a special file.

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

export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: "*",
      allow: "/",
      disallow: ["/admin", "/api"], // block anything that shouldn't be crawled
    },
    sitemap: "https://yourdomain.com/sitemap.xml",
  };
}

What's happening here: Next.js automatically generates a working /robots.txt route from this file. allow: "/" lets crawlers visit everything by default, while disallow blocks specific paths like admin dashboards or internal API routes that have no business being indexed.

⚠️ Common Mistake: Accidentally leaving disallow: "/" in a robots.txt after moving from staging to production. This single line blocks your entire site from every search engine — always double-check this file right after deploying.

Add a `sitemap.xml`

A sitemap is a map of every URL on your site that you want indexed. It doesn't force Google to index anything, but it makes discovery much faster — especially for new pages that have no other links pointing to them yet.

// app/sitemap.ts
import { MetadataRoute } from "next";
import { getAllPosts } from "@/lib/posts";

export default function sitemap(): MetadataRoute.Sitemap {
  const baseUrl = "https://yourdomain.com";

  const posts = getAllPosts().map((post) => ({
    url: `${baseUrl}/blog/${post.slug}`,
    lastModified: new Date(post.updatedAt || post.publishedAt),
    changeFrequency: "weekly" as const,
    priority: 0.8,
  }));

  const staticRoutes = ["", "/about", "/blog", "/contact"].map((route) => ({
    url: `${baseUrl}${route}`,
    lastModified: new Date(),
    changeFrequency: "monthly" as const,
    priority: route === "" ? 1 : 0.6,
  }));

  return [...staticRoutes, ...posts];
}

What's happening here: this generates every blog post URL dynamically from your data source, plus a handful of static pages, and outputs them at /sitemap.xml automatically. lastModified helps Google know when to re-crawl a page; priority is a soft hint about relative importance, not a guarantee.

💡 Tip: Submit your sitemap URL directly inside Google Search Console → Sitemaps after deploying. It won't guarantee faster indexing, but it removes any ambiguity about where your sitemap lives.

Check Your Robots Meta Tag

Even if robots.txt allows crawling, an individual page can still say "don't index me" via a meta tag. This matters most for things like thank-you pages, internal search results, or draft content.

// app/some-page/page.tsx
import type { Metadata } from "next";

export const metadata: Metadata = {
  robots: {
    index: false, // don't show this page in search results
    follow: true, // but still crawl the links on it
  },
};

⚠️ Common Mistake: Setting index: false on your root layout "just to be safe" during development, then forgetting to remove it before launch. This is one of the most common reasons a brand-new site gets zero organic traffic — always verify your homepage's robots meta in production.

Verify With Google Search Console

Search Console is free and non-negotiable. It tells you, directly from Google, which pages are indexed, which are excluded (and why), and whether your sitemap was actually read. Set it up early — indexing issues are invisible until you check.

The single most-used feature here is the URL Inspection Tool. Paste any URL from your site into it and Google tells you exactly whether that page is indexed, when it was last crawled, and — if it's not indexed — why not. After a major change to a page (new metadata, fixed structured data, a rewritten intro), use it to request reindexing instead of waiting for Google to notice on its own.

💡 Tip: URL Inspection is also the fastest way to debug "why isn't my new blog post showing up in search" — it'll tell you plainly if it's still queued, blocked, or already indexed but just not ranking yet (which is a different problem).

Don't Forget Bing Webmaster Tools

Google isn't the only search engine worth indexing on. Bing powers Bing search itself, plus Yahoo, DuckDuckGo (partially), and is the underlying index behind Microsoft Copilot's web results — meaningful traffic that's easy to pick up for almost no extra work.

Sign up at Bing Webmaster Tools and verify your site
Submit the exact same sitemap.xml you already built for Google — no separate file needed
Bing also offers a URL Inspection-style tool and a URL Submission option for faster indexing of new pages

💡 Tip: Bing Webmaster Tools lets you import your verified site directly from Google Search Console in a couple of clicks, which skips most of the manual verification steps entirely.

2. Metadata: Titles, Descriptions & Canonical URLs

Metadata doesn't change how your page looks — it changes how search engines describe and rank it, and how it appears when shared.

Related: How to Add Metadata in Next.js 16 (2026 Beginner's Guide) covers the full Metadata API in more depth if you want a deeper dive after this section.

Set a Title Template Once, Not on Every Page

// app/layout.tsx
import type { Metadata } from "next";

export const metadata: Metadata = {
  metadataBase: new URL("https://yourdomain.com"),
  title: {
    default: "YourSite — Tagline Here",
    template: "%s | YourSite",
  },
  description: "A clear, honest description of what your site does.",
};

What's happening here: metadataBase resolves every relative URL elsewhere in your metadata (like Open Graph images) into an absolute URL automatically. title.template means any page that sets title: "My Post" automatically renders as "My Post | YourSite" — you never repeat the suffix manually.

⚠️ Common Mistake: Manually typing "My Post | YourSite" as the title on individual pages while also having a template set in the root layout. This doubles the suffix into something like "My Post | YourSite | YourSite". Let the template do the work — pages should only set the unique part.

Write Unique Titles and Descriptions Per Page

// app/blog/[slug]/page.tsx
export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const { slug } = await params;
  const post = getPostBySlug(slug);

  return {
    title: post.title,
    description: post.description,
    alternates: {
      canonical: `https://yourdomain.com/blog/${post.slug}`,
    },
  };
}

Length guidelines to actually stick to:

Title: ~50–60 characters (roughly 580px) before Google truncates it
Description: ~150–160 characters — treat it as ad copy for your own page, not a summary

Canonical URLs

A canonical tag tells Google "this is the one true version of this page" when the same content is reachable through multiple URLs — with or without a trailing slash, with query params, or duplicated across categories.

export const metadata: Metadata = {
  alternates: {
    canonical: "https://yourdomain.com/blog/my-post",
  },
};

💡 Tip: Next.js already infers a canonical URL from your route and metadataBase in most cases. Set this explicitly only when you have genuine duplicate content — like a product reachable at two different category paths.

3. Structured Data (JSON-LD)

Structured data doesn't change what a page looks like to a human — it tells search engines and AI assistants explicitly what kind of content a page is: an article, a product, an FAQ, a business. This is what unlocks rich results like star ratings, breadcrumbs, and FAQ dropdowns directly in search listings.

// app/blog/[slug]/page.tsx
import Script from "next/script";

<Script
  id="blog-post-jsonld"
  type="application/ld+json"
  dangerouslySetInnerHTML={{
    __html: JSON.stringify({
      "@context": "https://schema.org",
      "@type": "BlogPosting",
      headline: post.title,
      description: post.description,
      datePublished: post.publishedAt,
      dateModified: post.updatedAt || post.publishedAt,
      author: { "@type": "Person", name: "Your Name" },
      publisher: {
        "@type": "Organization",
        name: "YourSite",
        url: "https://yourdomain.com",
      },
    }),
  }}
/>

What's happening here: this injects a <script type="application/ld+json"> block with zero visible UI impact. Google's crawler parses it separately from your rendered content to understand the page's structure.

⚠️ Common Mistake: Assuming valid JSON-LD automatically means eligible for rich results. Google layers its own required-field requirements on top of the schema.org spec — an Article missing an author, for instance, is valid JSON-LD that Google will still ignore for rich-result purposes. Always test with Google's Rich Results Test before assuming it's working.

Common types worth adding depending on your page:

Page type	Schema type
Blog post	`Article` / `BlogPosting`
FAQ section	`FAQPage`
Product page	`Product`
Local business	`LocalBusiness`
Software/SaaS tool	`SoftwareApplication`
Nav trail	`BreadcrumbList`

💡 Save time: use the JSON-LD Generator to generate any of these schema types with a live eligibility checklist scored against Google's actual Rich Results requirements, instead of hand-writing and second-guessing the JSON.

4. Open Graph & Twitter Cards

This is technically a "social sharing" feature, but it directly affects click-through rate from search and social — and CTR is a real ranking signal.

export const metadata: Metadata = {
  openGraph: {
    title: post.title,
    description: post.description,
    url: `https://yourdomain.com/blog/${post.slug}`,
    siteName: "YourSite",
    type: "article",
    images: [{ url: "/og-image.png", width: 1200, height: 630 }],
  },
  twitter: {
    card: "summary_large_image",
    title: post.title,
    description: post.description,
  },
};

💡 Tip: 1200×630px is the sweet spot for Open Graph images — smaller images get stretched and look blurry on most platforms. Reuse the same image for both openGraph and twitter unless you have a specific reason not to.

Not sure how Open Graph and Twitter Cards actually differ, or whether you need both? Open Graph vs Twitter Cards: What's the Difference? breaks down the exact syntax differences and when each one is read. And if you'd rather generate all of this instead of hand-writing it, the Meta Tag Generator outputs SEO tags, Open Graph, Twitter Cards, and JSON-LD from one set of inputs.

5. Core Web Vitals & Performance

Google explicitly uses Core Web Vitals as a ranking signal. These aren't vague "make it fast" advice — they're three specific, measurable metrics.

Metric	What it measures	Good threshold
LCP (Largest Contentful Paint)	How fast the main content loads	Under 2.5s
INP (Interaction to Next Paint)	How responsive the page feels to input	Under 200ms
CLS (Cumulative Layout Shift)	How much the layout jumps around while loading	Under 0.1

The Next.js-Specific Fixes That Matter Most

// Always use next/image instead of <img>
import Image from "next/image";

<Image
  src="/hero.jpg"
  alt="Descriptive alt text" // required — also helps SEO and accessibility
  width={1200}
  height={630}
  priority // only for above-the-fold images
/>

Why this matters: next/image automatically serves resized, modern-format (WebP/AVIF) images and reserves layout space before the image loads — directly improving both LCP and CLS. priority should only go on the one or two images visible without scrolling; overusing it defeats lazy loading for everything else.

// Load fonts through next/font to avoid layout shift
import { Inter } from "next/font/google";

const inter = Inter({ subsets: ["latin"], display: "swap" });

Why this matters: next/font self-hosts Google Fonts at build time, eliminating the render-blocking network request to Google's font CDN and preventing the "flash of invisible/unstyled text" that causes layout shift.

⚠️ Common Mistake: Reserving no space for ads, embeds, or dynamically loaded content. Every element that pops in after initial render without a reserved size pushes content around — that's exactly what CLS measures.

Run Lighthouse (built into Chrome DevTools) for quick local lab data, but don't stop there — Google PageSpeed Insights runs the same Lighthouse audit and layers in real-user field data (from the Chrome User Experience Report) when enough traffic exists for your URL. That field data is what actually matters, since lab data and field data can disagree, and Google ranks based on the field data your real visitors generate — not your local Lighthouse score. Cross-check both there and in Search Console's Core Web Vitals report.

6. Mobile-Friendliness

Google indexes the mobile version of your site first (mobile-first indexing), not desktop. If your mobile layout is broken, that's the version Google evaluates for ranking — even for desktop searches.

Quick checklist:

Responsive layout at all breakpoints (test with Tailwind's sm:/md:/lg: prefixes actually rendering correctly)
Tap targets at least 44×44px
No horizontal scrolling
Text readable without zooming (16px minimum for body text)

💡 Tip: Test with Chrome DevTools' device toolbar set to an actual mid-range device profile, not just "responsive" mode dragged to a guess-width.

7. URL Structure & Internal Linking

Keep URLs Short, Readable, and Keyword-Relevant

Good:  /blog/nextjs-metadata-guide
Bad:   /blog/post?id=48291&ref=xyz

Next.js's file-based routing makes this almost automatic — just name your route folders and slugs sensibly.

Internal links help Google understand which pages are related and pass authority between them. They also keep users (and crawlers) moving deeper into your site instead of bouncing after one page.

<p>
  Once auth is set up, check out our{" "}
  <Link href="/blog/stripe-checkout-guide">Stripe Checkout guide</Link> to
  add billing next.
</p>

⚠️ Common Mistake: Building tool pages or landing pages with almost no surrounding prose or internal links. Thin, isolated pages are exactly what tools like Google AdSense and Search Console's coverage report flag as low-value content — a page with substantial explanatory text and links to related pages reads as more legitimate to both crawlers and ad review systems.

8. HTTPS & Basic Security

This one's usually already handled if you're on Vercel, Netlify, or similar — but confirm it:

Every page loads over https://, with no mixed-content warnings (images/scripts loaded over plain http://)
www vs non-www redirects to one canonical version, not both serving live content
No broken SSL certificate warnings

HTTPS has been a confirmed Google ranking signal since 2014 — it's small, but it's free, so there's no reason to skip it.

9. Content Quality & Thin Content

Technical SEO gets your page crawled and indexed. It does not make a page worth ranking if there's nothing substantial on it. This matters especially for:

Tool pages (calculators, generators) — pair the actual tool with real explanatory prose about what it does and why it matters, not just a bare form
Category/index pages — a list of links with zero context reads as thin to both search engines and human reviewers
Duplicate boilerplate — if ten pages share 90% identical copy with one variable swapped, consolidate or genuinely differentiate them

💡 Tip: A useful gut check: if you deleted the interactive/dynamic part of a page, would there still be a paragraph or two of genuinely useful content left? If not, that page is a thin-content risk.

The Full Checklist at a Glance

[ ] robots.txt exists and isn't accidentally blocking the whole site
[ ] sitemap.xml exists and is submitted in Search Console
[ ] No unintended noindex on pages that should rank
[ ] Site verified and sitemap submitted in Bing Webmaster Tools too
[ ] Every page has a unique title (50–60 chars) and description (150–160 chars)
[ ] Canonical URLs set where duplicate content is possible
[ ] JSON-LD structured data added for articles, FAQs, products, or business info
[ ] Open Graph + Twitter Card tags on every shareable page
[ ] Images use next/image with descriptive alt text
[ ] Fonts loaded through next/font
[ ] Core Web Vitals checked in Search Console (not just Lighthouse locally)
[ ] Mobile layout tested on a real device profile
[ ] URLs are short, readable, and keyword-relevant
[ ] Related pages link to each other with real anchor context
[ ] Site is fully on HTTPS with no mixed content
[ ] No thin, boilerplate-only, or near-duplicate pages

Frequently Asked Questions

How long does it take for technical SEO changes to affect rankings?

Indexing changes (like fixing robots.txt) can show up in days. Ranking changes from Core Web Vitals or content improvements typically take weeks, since Google needs to re-crawl and re-evaluate the page relative to competitors.

Do I need a sitemap if my site is small?

Technically no — Google can discover a handful of linked pages without one. But it costs almost nothing to add and removes any doubt about discovery, so there's no real reason to skip it even on small sites.

Is Core Web Vitals a huge ranking factor?

It's one signal among many, and generally a tiebreaker rather than a dominant factor — strong content with mediocre performance usually still outranks weak content with perfect performance. That said, "mediocre" has a floor; genuinely poor Core Web Vitals can hold a page back.

Can I check all of this without Google Search Console?

Not fully. Lighthouse and third-party tools give you lab data, but Search Console gives you real user field data and actual indexing status — which is what Google uses for ranking decisions. It's free and essential, not optional.

Does technical SEO matter if I'm not writing much content yet?

Yes — technical SEO is largely a one-time setup cost (metadata patterns, sitemap, structured data templates) that pays off on every future page automatically. It's far easier to build it into your app's foundation now than to retrofit dozens of pages later.

Wrapping Up

Technical SEO isn't a mysterious marketing skill — it's a checklist of implementation details that a developer is uniquely positioned to get right: correct metadata exports, a real sitemap, valid structured data, and a page that actually loads fast. Get the foundation right once in your layout.tsx, sitemap, and robots files, and every page you ship afterward inherits it for free.

From here, a natural next step is auditing your existing pages against the checklist above one by one, starting with your highest-traffic pages first — small technical fixes there tend to move the needle fastest.

Useful Resources

How to Add Metadata in Next.js 16 (2026 Beginner's Guide)

Fri, 07 Aug 2026 04:36:07 +0000

You've built your Next.js app, it looks great, it works great — and then you share the link on Twitter or Slack and it shows up as a bare, ugly URL with no title, no image, nothing. Or worse, Google indexes your page with a title that just says "Home."

That's what happens when metadata is an afterthought. The good news: Next.js 16's App Router has a built-in, type-safe way to handle all of this — no next/head, no manual <meta> tag juggling. In this guide, you'll learn exactly how metadata works in the App Router, how to set it per-page, how to make it dynamic for things like blog posts, and the mistakes that trip up almost everyone the first time.

Why Metadata Matters

Metadata is the stuff that doesn't show up on your page, but controls how it's represented everywhere else:

The tab title and description in search results
The preview card when someone shares your link on X, LinkedIn, or Discord
Whether search engines are even allowed to index the page

Skip it, and your app might work perfectly for people already on it, while being invisible or unappealing to everyone who hasn't found it yet.

The Old Way vs the App Router Way

If you've used the Pages Router before, you probably reached for next/head and manually wrote <meta> tags inside a <Head> component. The App Router replaces this entirely with a Metadata API — you export a plain object (or a function) from your page or layout file, and Next.js generates all the right tags for you at build or request time, including merging metadata from parent layouts.

💡 Tip: You never import anything for basic metadata — no next/head, no <Head> component. Just export metadata (or generateMetadata) from the file.

Step 1: Static Metadata on a Page

For a page with fixed content — an About page, a Contact page — export a metadata object directly:

// app/about/page.tsx
import type { Metadata } from "next";

export const metadata: Metadata = {
  title: "About Us",
  description: "Learn more about our team and what we build.",
};

export default function AboutPage() {
  return <h1>About Us</h1>;
}

What's happening here: Next.js scans your app directory at build time, finds this exported metadata object, and injects the corresponding <title> and <meta name="description"> tags into the <head> automatically. No manual DOM manipulation, no client-side JavaScript needed.

Step 2: Metadata in the Root Layout (Site-Wide Defaults)

Your root layout.tsx is the place to set defaults that apply across the whole site — things like your site name and a fallback description.

// app/layout.tsx
import type { Metadata } from "next";

export const metadata: Metadata = {
  metadataBase: new URL("https://example.com"),
  title: {
    default: "DevStacked",
    template: "%s | DevStacked",
  },
  description: "Practical Next.js, React, and Supabase tutorials.",
};

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  );
}

Understanding title.template: this is one of the most useful (and most missed) features. Once you set a template in the root layout, any page that sets its own title gets automatically wrapped in that pattern.

So if a blog post page sets:

export const metadata: Metadata = {
  title: "Stripe Checkout Guide",
};

The actual rendered <title> becomes "Stripe Checkout Guide | DevStacked" — you never have to type "| DevStacked" on every single page.

⚠️ Common Mistake: Setting a full title like "Stripe Checkout Guide | DevStacked" on every page manually. If you've set a template in the root layout, this doubles up or looks inconsistent. Let the template do the work — just set the page-specific part.

What Does `metadataBase` Do?

Notice the metadataBase field above. Any relative URL you use elsewhere in your metadata — an openGraph.images path, a canonical URL — gets resolved against this base automatically. Without it, Next.js falls back to http://localhost:3000 in development and can log a warning in production, or worse, ship a broken relative URL to a social platform that needs an absolute one.

export const metadata: Metadata = {
  metadataBase: new URL("https://devstacked.tech"),
  openGraph: {
    images: ["/og/cover.png"], // resolves to https://devstacked.tech/og/cover.png
  },
};

Set it once, in the root layout, and every nested page and layout can use short relative paths instead of repeating the full domain everywhere.

Metadata Inheritance

Metadata in the App Router isn't isolated per file — it's merged down the layout tree. A field set in app/layout.tsx applies to every page unless a more specific layout.tsx or page.tsx overrides it. So app/blog/layout.tsx could add a shared openGraph.siteName, and each app/blog/[slug]/page.tsx only needs to set the fields that actually change per post, like title and description.

The merge is shallow per key, not a deep object merge — if a page sets its own openGraph object, that whole object replaces the parent's openGraph, it doesn't merge field-by-field inside it. Keep that in mind if a nested page's Open Graph tags seem to be missing fields you set higher up.

Example:

// layout.tsx

openGraph: {
  siteName: "DevStacked",
  images: [...]
}

// page.tsx
openGraph: {
  title: "Stripe Guide"
}

Result? People often expect:

siteName
+
images
+
title

But actually

openGraph
↓
entire object replaced

Step 3: Dynamic Metadata with `generateMetadata`

Static objects work fine when you already know the content. But what about a blog post page at /blog/[slug] — the title and description depend on which post is being viewed, and that's only known at request time. For this, Next.js gives you generateMetadata, an async function that runs before the page renders.

// app/blog/[slug]/page.tsx
import type { Metadata } from "next";
import { getPostBySlug } from "@/lib/posts";
import { notFound } from "next/navigation";

interface Props {
  params: Promise<{ slug: string }>;
}

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

  if (!post) {
    notFound();
  }

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

export default async function BlogPostPage({ params }: Props) {
  const { slug } = await params;
  const post = getPostBySlug(slug);

  return <article>{/* ... */}</article>;
}

Why this matters: generateMetadata runs on the server, separately from your page component, and Next.js waits for it to resolve before streaming the <head> to the browser — so search engines and social crawlers always see the correct, post-specific title and description, not a generic fallback.

⚠️ Common Mistake: Forgetting params is a Promise in Next.js 16. Just like inside the page component itself, you must await params before reading slug — reading it directly (params.slug) will throw a type error or return undefined.

Step 4: Open Graph Tags (Rich Link Previews)

Open Graph tags control how your link looks when shared on LinkedIn, Slack, Discord, or Facebook — the title, description, and preview image shown in the card.

export const metadata: Metadata = {
  title: "Stripe Checkout Guide",
  description: "Learn how to integrate Stripe Checkout with Next.js 16.",
  openGraph: {
    title: "Stripe Checkout Guide",
    description: "Learn how to integrate Stripe Checkout with Next.js 16.",
    url: "https://example.com/blog/stripe-checkout-guide",
    siteName: "DevStacked",
    images: [
      {
        url: "https://example.com/og/stripe-checkout.png",
        width: 1200,
        height: 630,
        alt: "Stripe Checkout Guide",
      },
    ],
    type: "article",
  },
};

Why a separate openGraph object instead of reusing title/description? Because you often want slightly different copy for a social preview card versus a search result snippet — a social card benefits from being punchier, while a search description often needs to match user search intent more literally. Next.js lets you diverge, but falls back to the top-level title/description if you don't specify openGraph values.

💡 Tip: The recommended Open Graph image size is 1200×630px. Anything smaller gets stretched and looks blurry on most platforms.

Step 5: Twitter Card Tags

X (formerly Twitter) can technically fall back to your Open Graph tags, but adding explicit Twitter Card metadata gives you more reliable control:

export const metadata: Metadata = {
  twitter: {
    card: "summary_large_image",
    title: "Stripe Checkout Guide",
    description: "Learn how to integrate Stripe Checkout with Next.js 16.",
    images: ["https://example.com/og/stripe-checkout.png"],
  },
};

card: "summary_large_image" is what you want almost every time — it renders a large, prominent image above the title and description, instead of a small square thumbnail next to the text.

Step 6: Generating Open Graph Images Dynamically

Instead of designing a static OG image for every single blog post, Next.js lets you generate one on the fly using next/og. Drop a special file named opengraph-image.tsx right next to your page.tsx:

// app/blog/[slug]/opengraph-image.tsx
import { ImageResponse } from "next/og";

export const runtime = "edge";
export const alt = "Blog Post Preview";
export const size = { width: 1200, height: 630 };
export const contentType = "image/png";

export default async function Image({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const title = slug.replace(/-/g, " ");

  return new ImageResponse(
    (
      <div
        style={{
          height: "100%",
          width: "100%",
          display: "flex",
          alignItems: "center",
          justifyContent: "center",
          backgroundColor: "white",
          fontSize: 64,
          fontWeight: 700,
          textTransform: "capitalize",
        }}
      >
        {title}
      </div>
    ),
    { ...size }
  );
}

What's happening here: Next.js automatically detects this file, renders the JSX into a PNG using the Edge Runtime, and serves it at a route matching the page — then automatically wires it up as the og:image for that page. No manual linking required.

💡 Tip: runtime = "edge" matters here — image generation is CPU-light but benefits from edge deployment for fast, globally distributed rendering.

Step 7: Canonical URLs and Robots

Two smaller but important fields:

export const metadata: Metadata = {
  alternates: {
    canonical: "https://example.com/blog/stripe-checkout-guide",
  },
  robots: {
    index: true,
    follow: true,
  },
};

Canonical URLs tell search engines "this is the one true version of this page" — useful if the same content is reachable through multiple URLs (with/without trailing slash, query params, etc.), so you don't get penalized for duplicate content.

💡 Tip: Next.js already auto-generates a canonical URL for a page based on its route and your metadataBase, so in many straightforward cases you don't have to set alternates.canonical at all. Setting a custom value matters when you have genuine duplicate content — the same product reachable at two different URLs, paginated pages that should all canonicalize back to page 1, or a query-string variant of a page that shouldn't be indexed separately.

Robots controls whether search engines should index the page at all. Set index: false for things like admin pages, thank-you pages, or draft content you don't want showing up in search results.

Step 8: File-Based Metadata

Not all metadata comes from a metadata object or generateMetadata function. Next.js also supports file-based metadata — special file names inside your app folder that Next.js automatically detects and turns into the correct tags, no export required:

File	What it generates
`favicon.ico`	The browser tab icon
`icon.tsx` / `icon.png`	App icons (including dynamically generated ones via `next/og`)
`apple-icon.png`	Icon used on iOS home screens
`opengraph-image.tsx` / `.png`	The `og:image` tag, as shown in Step 6
`twitter-image.tsx` / `.png`	The Twitter Card image, if different from Open Graph
`sitemap.ts`	Your `sitemap.xml`
`robots.ts`	Your `robots.txt`

Just like opengraph-image.tsx, you can drop any of these next to a page.tsx to scope them to that route, or in the root app folder for site-wide defaults. Next.js wires up the correct <link> or <meta> tag automatically — you never manually reference these files anywhere else in your code.

Frequently Asked Questions

Do I need `generateMetadata` for every page?

No — only for pages where the metadata depends on data you don't know until request time (a slug, a database lookup, etc.). Static pages like About or Contact should just export a plain metadata object; it's simpler and doesn't need to run on every request.

What happens if I set metadata in both the layout and the page?

Next.js merges them, with the page's metadata taking priority for overlapping fields. Non-overlapping fields (like a description only set in the layout) still apply. This is what lets title.template work — the layout sets the pattern, the page sets the specific title.

Can I use `generateMetadata` and `generateStaticParams` together?

Yes, and you should for statically generated dynamic routes. generateStaticParams tells Next.js which slugs exist at build time; generateMetadata runs for each of those and produces the right metadata per page — both commonly pull from the same data source.

Most likely the image URL isn't absolute, or the platform cached an old preview. Always use a full https:// URL in openGraph.images, and if you're testing, use each platform's own debugger tool (like Facebook's Sharing Debugger) to force a re-scrape.

Does metadata affect Core Web Vitals or performance?

No — metadata is just <head> tags, not render-blocking scripts or styles. generateMetadata running on the server also doesn't block your page's own data fetching, since Next.js can run them in parallel.

Why isn't Google showing my description?

Google often rewrites meta descriptions if it thinks another page excerpt better matches the user's search query.

What's the ideal title length?

Aim for roughly 50–60 characters (or about 580–600 pixels) so titles are less likely to be truncated in search results.

Wrapping Up

Next.js 16's Metadata API takes what used to be manual, error-prone <head> management and turns it into a small, typed export at the top of your file. Static pages get a plain object, dynamic pages get generateMetadata, and layouts let you set sensible defaults once instead of repeating them everywhere.

From here, a natural next step is wiring up JSON-LD structured data for rich search results, or building out per-post dynamic OG images across your whole blog if you haven't already.

💡 Save time: Use our Meta Tag Generator to instantly generate a complete Metadata object, Open Graph tags, Twitter Cards, and JSON-LD for any page — fill in a page's title, description, URL, and image once, and it outputs both raw HTML <meta> tags and a ready-to-paste Next.js Metadata object.

Useful Resources

Continue Learning

Fixing your site's metadata: a practical checklist

Thu, 06 Aug 2026 18:35:01 +0000

You've done it. You're finally done building the website or application you've been working on for quite a while. Proud and elated, you go to share this on your socials or to your buddies — uh oh, what's this now? The preview in WhatsApp shows no headline, your avatar is cropped and dimensions seem wrong. I've been there too. The site looked fine in the browser.

The problem was everything outside the browser: link previews, search snippets, and tab icons all use a separate metadata layer most of us skip until something breaks.

So, how do you fix this? Use this as a pre-launch checklist — or run it on a site that's already live but sharing badly.

What I ran into on my own portfolio

When I ran this audit on shwethaadiraj.com, the site rendered fine — but sharing it told a different story. I had pointed both the favicon and Open Graph image at my profile avatar. At tab size the illustration was unreadable; in link previews it got cropped awkwardly.

An OG validator then flagged two things I hadn't considered: the image was 512×512 (most platforms expect 1200×630), and there was no headline or CTA on the image itself — so Slack and LinkedIn showed a plain square with none of the context from my meta title. I replaced the favicon with a simplified monogram, regenerated the OG image at the correct aspect ratio with my name, tagline, and site URL on it, and re-ran the debuggers. Even then, previews didn't update until I hit Scrape Again — platforms cache OG data aggressively, so fixes on your end won't show up until you bust that cache.

None of this required rethinking the app. It was a metadata pass — the kind of work that's easy to defer and annoying to discover at the share button.

Before we get into the specifics, here's a primer on what metadata can actually impact:

What is metadata for?

Metadata, simply put, is data about data. Search engines, crawlers and social sites all parse different metadata from your app.

Search & Discovery: The title and description in your app's <meta> tags tell search engines, crawlers, and AI chatbots how relevant your content is to a user's query.
Social Platforms: Open Graph (OG) and Twitter/X cards give you more control over how your app is presented when shared on social platforms.
Browser: Adding favicons and apple touch icons helps consolidate your brand identity across browser tabs, notifications and bookmarks.

The metadata audit checklist

A page can render properly and function well but it can still fail when it comes to browser, socials or search engine checks. Run this audit on every public-facing page on your app.

1. Favicon and touch icons

Does the browser tab show a clear icon at 16×16 and 32×32?
Is there a dedicated Apple touch icon (typically 180×180) for “Add to Home Screen”?
Is the favicon a simplified mark, not a full photo or illustration?
Are favicon URLs absolute (or resolvable via a consistent base URL)?

Why it matters: Large images or detailed illustrations lose detail at tab size. Users with many tabs rely on favicons to find your site. A blurry or generic icon makes the site look unfinished even when the page itself is polished.

How to verify

Open the site in a browser and inspect the tab icon.
Visit the favicon URL directly (e.g. /icon or /favicon.ico).
On mobile, add the site to the home screen and check the icon.
Use a favicon checker or DevTools → Application → Manifest / Icons if you ship a PWA manifest.

2. Page title and description

Does every route have a unique <title>?
What is the length of the titles? Are they concise and readable?
Does every page have a description summarizing content of that specific page?

Why it matters: Title and description are what show up in Google results and often in link previews when OG tags are missing. Duplicate or empty metadata makes pages compete with each other and look spammy in search.

How to verify

View page source and search for <title> and name="description".
Paste the URL into a search preview tool and confirm the title/description match what you expect.

3. Canonical URL

Does every page declare one canonical URL via <link rel="canonical">?
For your app or any routes in it, is it app.com/blog/ or app.com/blog?

Why it matters: Search engines treat duplicate URLs (http/https, www/bare, trailing slash variants) as separate pages. Canonical URL tells them which version to index and pass ranking signals to.

How to verify

View source on each page type and find link rel="canonical".
Confirm the href matches the URL you'd share publicly.
Try alternate forms (with/without www, with trailing slash) and check redirects or canonical tags.

Does your page have og:title, og:description, and og:url, and do they match the page content?
Are the image dimensions in og:image 1200×630 (1.91:1)?
Does the image include readable headline and/or CTA text — many validators flag “no conversion text” because platforms often show the image without your meta title overlay.
Are twitter:title, twitter:description, and twitter:image defined and aligned with Open Graph tags?
Does twitter:card match your image: summary_large_image for wide OG art, summary only for small square cards?

Why it matters: These tags control how your link appears on Slack, LinkedIn, iMessage, and X. Wrong aspect ratio gets cropped; missing image means no preview. X can fall back to OG tags, but explicit Twitter tags and the right card type avoid inconsistent layouts.

How to verify

opengraph.xyz — paste URL, inspect warnings.
Facebook Sharing Debugger — use “Scrape Again” after fixes.
LinkedIn Post Inspector
Twitter Card Validator
Open your og:image URL directly in the browser — confirm it loads and reads at thumbnail size.
Compare previews across at least two platforms for the same URL.

5. Robots and indexing

Does your robots.txt allow crawling of public pages and block only private or paywalled content?
Is the sitemap URL declared in robots.txt?

Why it matters: Accidentally blocking / or omitting the sitemap slows discovery. Blocking too little exposes internal paths to crawlers.

How to verify

Visit /robots.txt on production.
View source for <meta name="robots"> on key pages.
Google Search Console → Pages / Sitemaps (if you use it).

6. Sitemap

Does /sitemap.xml exist and return valid XML?
Do new routes get added when you ship pages?
Is the URL in your sitemap matching canonical URL structure?

Why it matters: Sitemaps help search engines find pages that aren't heavily linked.

How to verify

Open /sitemap.xml in the browser.
Count URLs vs what you expect to be public.
Resubmit in Search Console after major additions.

Going further: agentic browsing

Once the basics above are solid, there's a second audience worth optimizing for: AI agents browsing on behalf of users. That means accessibility tree completeness, llms.txt, layout stability, and eventually APIs like WebMCP. I wrote a separate post on this — Your Website's New Audience: AI Agents — but the order matters: get favicons, Open Graph, and canonical URLs right first, then layer agent-ready improvements on top.

Closing thoughts

When building any new application, people focus on the app itself — metadata gets deferred until you share a link and it looks unpolished. You don't need every advanced technique on day one — get titles and descriptions, canonical URLs, favicons, and Open Graph images right first; robots.txt and sitemap next. That covers the failures people actually notice.

I've been experimenting with a Cursor agent skill that runs this checklist against a real codebase — try it on your project and let me know how it works.

Open Graph vs Twitter Cards: What's the Difference? (Nextjs 16)

Thu, 06 Aug 2026 04:15:34 +0000

You share a link on Slack, and it shows up as a beautiful card with a title, description, and image. You share a link on X, and it shows up... as bare text. Same website, two totally different results. What's going on?

The short answer: those preview cards aren't magic, and they're not one single system. They're powered by two separate sets of meta tags — Open Graph and Twitter Cards — and if you only add one of them, some platforms simply won't know what to show.

By the end of this guide, you'll know exactly what each one does, how they're different, when you actually need both, and how to add them correctly in a Next.js 16 App Router project.

Why This Confuses Almost Everyone

Here's the thing that trips people up: Open Graph and Twitter Cards look almost identical. Both control a title, a description, and an image. Both live in your page's <head>. Both were designed for the exact same job — making a shared link look good.

So why do we need two of them?

Because they were built by two different companies, at two different times, for two different platforms — and neither one fully committed to just using the other's format.

Open Graph vs Twitter Cards: The Real Differences

	Open Graph	Twitter Cards
Created by	Facebook	Twitter (now X)
Attribute used	`property`	`name`
Prefix	`og:`	`twitter:`
Used by	Facebook, LinkedIn, Slack, Discord, WhatsApp, and most others	X (Twitter)
Controls layout?	Not really — mostly fixed	Yes, via `twitter:card`
Required if you already have OG tags?	—	Technically no, X can fall back to OG — but see below

Does X Really Fall Back to Open Graph?

Yes, X can fall back to Open Graph tags for several fields, but relying on the fallback means you can't explicitly control twitter:card, so providing Twitter Card tags is still recommended.

⚠️ Common Mistake: Assuming "X reads Open Graph tags anyway, so I don't need Twitter tags." Technically true for basic fields, but you'll usually get a worse-looking card. If X previews matter for your traffic, add both.

What Is Open Graph?

Open Graph (often shortened to "OG") is a protocol created by Facebook in 2010. It defines a set of <meta> tags that tell any platform reading your page: "here's the title, description, image, and type of content this page represents."

<meta property="og:title" content="Stripe Checkout Guide" />
<meta property="og:description" content="Learn how to integrate Stripe Checkout with Next.js 16." />
<meta property="og:image" content="https://example.com/og-image.png" />
<meta property="og:url" content="https://example.com/blog/stripe-checkout-guide" />
<meta property="og:type" content="article" />

💡 Tip: Notice the tags use property, not name, for the attribute. That's an Open Graph convention — it's part of the original protocol spec, not a typo you'll see in other meta tags.

Open Graph became the industry default. Facebook, LinkedIn, Slack, Discord, WhatsApp, and dozens of other platforms all read Open Graph tags to build their link preview cards. If you only add one type of meta tag to your site, this is the one to add — it covers the widest range of platforms.

What Are Twitter Cards?

Twitter Cards (still called that even though the platform is now X) are a separate set of meta tags created by Twitter, also released around 2010–2012, specifically for how links preview inside tweets.

<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="Stripe Checkout Guide" />
<meta name="twitter:description" content="Learn how to integrate Stripe Checkout with Next.js 16." />
<meta name="twitter:image" content="https://example.com/twitter-image.png" />

💡 Tip: Unlike Open Graph, Twitter Card tags use the standard name attribute — this is one of the small syntax differences that catches people copy-pasting between the two.

The one genuinely unique piece here is twitter:card, which controls the layout of the preview:

Value	What it does
`summary`	Small square image, text beside it
`summary_large_image`	Large image above the title and description (the one you want almost every time)
`player`	Embeds video/audio directly in the tweet
`app`	Links to a mobile app store listing

Adding Both in Next.js 16

Next.js's App Router Metadata API handles both tag types through one typed object — no manual <meta> tags needed.

// app/blog/[slug]/page.tsx
import type { Metadata } from "next";

export const metadata: Metadata = {
  title: "Stripe Checkout Guide",
  description: "Learn how to integrate Stripe Checkout with Next.js 16.",

  openGraph: {
    title: "Stripe Checkout Guide",
    description: "Learn how to integrate Stripe Checkout with Next.js 16.",
    url: "https://example.com/blog/stripe-checkout-guide",
    siteName: "DevStacked",
    type: "article",
    images: [
      {
        url: "https://example.com/og-image.png",
        width: 1200,
        height: 630,
        alt: "Stripe Checkout Guide",
      },
    ],
  },

  twitter: {
    card: "summary_large_image",
    title: "Stripe Checkout Guide",
    description: "Learn how to integrate Stripe Checkout with Next.js 16.",
    images: ["https://example.com/og-image.png"],
  },
};

What's happening here: the openGraph object generates every og:* tag, and the twitter object generates every twitter:* tag — Next.js writes the correct property or name attributes for you under the hood. You're writing one object; Next.js is producing two separate tag sets.

💡 Tip: You can reuse the same image for both. There's no rule requiring separate images — most sites use one 1200×630px image for both og:image and twitter:image.

Can I Skip the Twitter Object Entirely?

If you set openGraph but skip twitter, Next.js does not automatically duplicate your OG tags into Twitter tags — it just omits twitter:* tags from the page entirely, relying on X's own (imperfect) fallback behavior described above.

// This works, but X's preview may not use the large-image layout
export const metadata: Metadata = {
  openGraph: {
    title: "My Post",
    images: ["/og-image.png"],
  },
  // no twitter object — X falls back to og: tags, but loses twitter:card
};

If you want a guaranteed summary_large_image layout on X, always set the twitter object explicitly.

Image Size: One Size Fits (Almost) Both

Both formats recommend the same dimensions, which is why one image usually works everywhere:

Recommended size: 1200×630px
Aspect ratio: roughly 1.91:1
Format: PNG or JPEG, keep it under ~5MB

⚠️ Common Mistake: Using a square logo as your og/twitter image. It gets stretched or cropped awkwardly on most platforms — build a proper wide banner image instead, even a simple one with your title text on a solid background.

Frequently Asked Questions

If I only have time to add one, which should I pick?

Open Graph. It covers Facebook, LinkedIn, Slack, Discord, WhatsApp, and (partially) X. Twitter Cards only improve the experience on one platform — X — but that improvement (the large image layout) is significant enough to add both if you can.

Does Google use Open Graph or Twitter Cards for search results?

Neither, directly. Google Search mostly relies on your page's <title>, meta description, and structured data (JSON-LD) — not OG or Twitter tags. OG/Twitter tags are purely for social link-preview cards, not search rankings or snippets.

Why isn't my preview updating after I changed the image?

Almost every platform caches link previews aggressively. Facebook has a Sharing Debugger to force a re-scrape, and X's card validator works similarly — always test with these tools instead of just re-sharing the link and hoping.

Do I need `og:type` set to something other than "website"?

Only if you want to be precise. article is common for blog posts, product for e-commerce pages, video.other for video content. Most platforms treat website as a safe default and won't visibly change your card's appearance.

Can I test my tags without actually posting them?

Yes — use Facebook's Sharing Debugger for Open Graph and Twitter's Card Validator for Twitter Cards. Both let you paste a URL and preview exactly how the card will render before you share it anywhere.

Wrapping Up

Open Graph and Twitter Cards solve the same problem — making your links look good when shared — but they're two separate protocols from two separate companies, with slightly different syntax and slightly different platform support. The safest move is simple: always set both openGraph and twitter in your Next.js metadata, reuse one well-sized image for both, and test with each platform's debugger before you trust it in production.

From here, a natural next step is wiring up JSON-LD structured data for richer search results, or generating dynamic OG images per page with next/og if you haven't already.

If you're new to metadata, first read How to Add Metadata in Next.js 16 (2026 Beginner's Guide).

💡 Save time: use the Meta Tag Generator to generate both Open Graph and Twitter Card tags — plus canonical URLs and JSON-LD — from one set of inputs, in both raw HTML and Next.js Metadata API format.

Useful Resources

Continue Learning

Data can Kill: How A Billion Dollar industry is Missing this?

Sun, 15 Feb 2026 02:25:28 +0000

Target: Senior Software Architects and Back-end Devs.

Implementation-focused and Code-heavy.

Title: Implementing Tier-Weighted Data Governance with DAIS-10

If you're tired of writing brittle unit tests for data schemas, you need to look at the DAIS-10

Methodology. It's a formal standard for semantic attribute importance.The architecture is built on 8 interdependent engines.

For developers, the AMD-10 (Automated Meaning Diagnostics) is the game changer.
It runs 22 systematic tests to ensure your importance scores aren't drifting over-time.
The Logic: Instead of if col is null: error, we use SIF-10 weights to calculate a record completeness score $C(r)$.

If an Essential attribute is missing, $C(r)$ drops below the threshold instantly.

If an Enrichment attribute is missing, the record stays valid. We are standardizing this for Concept to ensure our pipelines are resilient, not just "correct.

"Key Algorithms included in the spec: Visit Github.

https://github.com/usman19zafar/Project-DAIS.10-with-CLaude/blob/main/Methodology (Plain English).md

DAIS10_Classify: O(k) interpretation.
DIFS-10: Exponential decay calculations.
Tier-Weighted SQL generation.

Coder Legion - Recent posts tagged metadata

Strip EXIF and AI Metadata in the Browser Before Instagram Upload

What usually leaks

A boring workflow that works

Why this belongs in a developer checklist

The Complete Technical SEO Checklist for Next.js Developers (2026 Guide)

Why Technical SEO Is Different From "Writing Good Content"

Why Technical SEO Matters for AI Search Too

1. Crawlability & Indexing

Add a robots.txt

Add a sitemap.xml

Check Your Robots Meta Tag

Verify With Google Search Console

Don't Forget Bing Webmaster Tools

2. Metadata: Titles, Descriptions & Canonical URLs

Set a Title Template Once, Not on Every Page

Write Unique Titles and Descriptions Per Page

Canonical URLs

3. Structured Data (JSON-LD)

4. Open Graph & Twitter Cards

5. Core Web Vitals & Performance

The Next.js-Specific Fixes That Matter Most

6. Mobile-Friendliness

7. URL Structure & Internal Linking

Keep URLs Short, Readable, and Keyword-Relevant

Link Between Related Pages Deliberately

8. HTTPS & Basic Security

9. Content Quality & Thin Content

The Full Checklist at a Glance

Frequently Asked Questions

How long does it take for technical SEO changes to affect rankings?

Do I need a sitemap if my site is small?

Is Core Web Vitals a huge ranking factor?

Can I check all of this without Google Search Console?

Does technical SEO matter if I'm not writing much content yet?

Wrapping Up

Useful Resources

How to Add Metadata in Next.js 16 (2026 Beginner's Guide)

Why Metadata Matters

The Old Way vs the App Router Way

Step 1: Static Metadata on a Page

Step 2: Metadata in the Root Layout (Site-Wide Defaults)

What Does metadataBase Do?

Metadata Inheritance

Example:

Step 3: Dynamic Metadata with generateMetadata

Step 4: Open Graph Tags (Rich Link Previews)

Step 5: Twitter Card Tags

Step 6: Generating Open Graph Images Dynamically

Step 7: Canonical URLs and Robots

Step 8: File-Based Metadata

Frequently Asked Questions

Do I need generateMetadata for every page?

What happens if I set metadata in both the layout and the page?

Can I use generateMetadata and generateStaticParams together?

Why isn't my Open Graph image showing up when I share the link?

Does metadata affect Core Web Vitals or performance?

Why isn't Google showing my description?

What's the ideal title length?

Wrapping Up

Useful Resources

Continue Learning

Fixing your site's metadata: a practical checklist

What I ran into on my own portfolio

What is metadata for?

The metadata audit checklist

1. Favicon and touch icons

2. Page title and description

3. Canonical URL

4. Open Graph and social link previews

5. Robots and indexing

6. Sitemap

Going further: agentic browsing

Closing thoughts

Open Graph vs Twitter Cards: What's the Difference? (Nextjs 16)

Why This Confuses Almost Everyone

Open Graph vs Twitter Cards: The Real Differences

Does X Really Fall Back to Open Graph?

What Is Open Graph?

What Are Twitter Cards?

Add a `robots.txt`

Add a `sitemap.xml`

What Does `metadataBase` Do?

Step 3: Dynamic Metadata with `generateMetadata`

Do I need `generateMetadata` for every page?

Can I use `generateMetadata` and `generateStaticParams` together?

Do I need `og:type` set to something other than "website"?