DEV Community: i-afaqrashid

Next.js Open Graph Image Missing? Your Page Replaced It

i-afaqrashid — Mon, 02 Nov 2026 14:53:22 +0000

My homepage had a share image. Fourteen other pages on my site didn't, and nothing told me.

I only found out when I ran my own pages through a metadata checker I'd just built. Lighthouse hadn't flagged it: pages with no og:image still scored 100 for SEO.

The cause

Here's the setup almost every Next.js site starts with. The layout holds the shared tags, and each page adds its own title.

// app/layout.tsx
export const metadata: Metadata = {
  metadataBase: new URL("https://example.com"),
  openGraph: {
    type: "website",
    siteName: "Example",
    images: ["/og-image.jpg"],
  },
};

// app/pricing/page.tsx
export const metadata: Metadata = {
  title: "Pricing",
  openGraph: { title: "Pricing", url: "/pricing" },
};

It reads as if the page adds to the layout's Open Graph tags. It doesn't. Next.js merges metadata shallowly, so nested fields like openGraph are "overwritten by the last segment to define them". The page's object replaces the layout's whole object.

That pricing page ships with no og:image, no og:type and no site name. The homepage usually looks fine because it never sets its own openGraph, which is why this is so easy to miss.

Why it stays hidden

Nothing fails. An openGraph object without images is valid, so my build gave no error or warning. The page renders and can rank as normal.

The only symptom is in a shared link, which appears without an image in chat apps and social feeds. And you probably test sharing with your homepage, the one page that works.

The fix

Keep the shared fields in one object and spread it into every openGraph. The Next.js docs suggest the same pattern.

// lib/metadata.ts
export const OG_DEFAULTS = {
  type: "website" as const,
  locale: "en_US",
  siteName: "Example",
  images: [{ url: "/og-image.jpg", width: 1200, height: 630, alt: "Example" }],
};

// app/pricing/page.tsx
export const metadata: Metadata = {
  title: "Pricing",
  openGraph: { ...OG_DEFAULTS, title: "Pricing", url: "/pricing" },
};

Put page-specific values after the spread, such as type: "article" on a blog post or a different image on a case study.

If one page deserves its own image, add an opengraph-image.jpg file to that page's folder. Next.js generates the tags for you, and file-based metadata takes priority over the metadata object.

X cards have a related trap

My layout also set twitter.title and twitter.description. Pages that didn't set their own twitter object inherited those, so every X card carried the homepage's title.

The fix was to keep only the card type in the layout. On Next.js 16, each page's X tags then took their title, description and image from that page's openGraph.

// app/layout.tsx
twitter: { card: "summary_large_image" },

Check your own site

Open a page, view its source and search for og:image. Don't stop at the homepage. Check one page from each route, because those are where the tag goes missing.

For a quicker check, paste the HTML into this free Next.js metadata checker. It lists what's missing and gives the Next.js fix for each tag.

The Open Graph protocol lists og:title, og:type, og:image and og:url as required. For the image, Meta recommends at least 1200 x 630 pixels. It also caches images by URL, so links shared before your fix may keep their old preview until they're refreshed.

Sources

Next.js robots.txt: Why You Shouldn't Block /_next/

i-afaqrashid — Mon, 02 Nov 2026 14:01:49 +0000

Plenty of Next.js sites have this in their robots.txt. Mine did.

User-agent: *
Allow: /
Disallow: /_next/

It looks tidy. /_next/ sounds like build output, and build output sounds like something a search engine has no reason to read. But that folder is how your pages reach a browser, and Google renders pages in a browser.

What lives under /_next/

/_next/static/ holds your compiled JavaScript and CSS, plus fonts and imported media. The folders inside it can change between Next.js versions and hosts, so don't write rules for them.
/_next/image is the default image optimization route. Every next/image on your site loads through it, unless you've set a custom loader or turned optimization off.

None of this is private. Anyone who opens your site downloads these files, so blocking them hides nothing.

What the rule does to Google

Google crawls a URL, renders the page in headless Chromium, then indexes the rendered HTML. It reads robots.txt first and skips any URL you've disallowed.

So with /_next/ blocked, Google gets your HTML and not much else. Its JavaScript docs are direct: "Google Search won't render JavaScript from blocked files or on blocked pages." Its robots.txt docs warn that if you block resources a page needs, Google "won't do a good job of analyzing pages that depend on those resources."

Images take a hit too. A next/image points to a URL under /_next/image, and robots.txt is one of the methods Google documents for keeping images out of search results. A blanket rule does that to every optimized image on the site.

Why nobody notices

Next.js sends real HTML from the server, so your text and links are in the first response. The page still gets indexed and can still rank for your name.

Your scores won't warn you either. My site scored 100 on all four Lighthouse categories with this rule in place.

The damage shows up elsewhere. Google analyzes a page without its styles, and anything that only appears after JavaScript runs is at risk.

The fix

Delete the line. If you have routes that crawlers shouldn't request, block those by name.

import type { MetadataRoute } from "next";

export default function robots(): MetadataRoute.Robots {
  return {
    rules: { userAgent: "*", allow: "/", disallow: "/private/" },
    sitemap: "https://example.com/sitemap.xml",
  };
}

Be careful with /api/ as well. If a page loads its content from an API route in the browser, blocking that route keeps the content from Google for the same reason.

Check your own site

In Search Console, open URL Inspection, run a live test and open the tested page. You get a screenshot of what Google rendered and a list of the resources it loaded. Google's help page says visual differences there "might be the result of resources that are blocked".

For a quicker check, paste your robots.txt into this free Next.js robots.txt checker. It runs in your browser and shows which Next.js paths are blocked and which line is doing it.

robots.txt isn't a privacy tool

If the goal was to hide something, this rule was never going to do it. Google says robots.txt "is not a mechanism for keeping a web page out of Google", and a blocked URL can still appear in results without a description.

To keep a page out of search, use noindex or a password. Don't block that page in robots.txt as well, because Google has to crawl it to see the noindex.