Verified against Claude Code · 2026-07-05
Wire up generateMetadata so every page actually gets dynamic SEO tags
Adds a proper generateMetadata function per route — dynamic title/description from real data, canonical URLs, and Open Graph images — instead of a static object copied across pages.
The prompt
Ready to copy — highlighted parts are example details you can swap.
<context>
Page type and route: A product detail page at /products/[slug]
Where the page's data comes from (same source generateMetadata should read): getProduct(slug) — a shared data-fetching function used by both the page and generateMetadata
Site domain, for absolute URLs: https://shop.example.com
</context>
<task>
Add or fix generateMetadata for this route. If the page's title/description depend on data (a product name, a blog post title), generateMetadata must be an async function that fetches that same data — using the shared fetch/data function so the request gets deduped against the page component's own fetch, not a second separate query.
</task>
<requirements>
- Export generateMetadata as an async function accepting the same params/searchParams the page receives, and return title, description, and openGraph fields built from real fetched data, not placeholder text.
- Set metadataBase in the root layout's metadata export to https://shop.example.com so relative OG/Twitter image paths resolve to absolute URLs — don't hardcode the domain into every individual page's metadata.
- Set a canonical URL per page via alternates.canonical, especially for any route reachable through more than one URL pattern (query params, trailing slash variants).
- For pages that shouldn't be indexed (draft content, internal tools, duplicate parameterized views), set robots: { index: false } explicitly rather than relying on it being excluded from a sitemap alone.
- If the data fetch inside generateMetadata fails or returns nothing (e.g. a deleted product), return sensible fallback metadata (a generic title, noindex) instead of letting the function throw and take down the whole page render.
</requirements>
<output_format>
The generateMetadata function code, plus one line confirming the fetch it makes is the same cached/deduped call the page component uses (name the shared function), and one line listing which routes on this app should be marked noindex.
</output_format>Customize the highlighted detailsoptional — the prompt above already works
Why this works
generateMetadata runs on the server and resolves before the page's HTML shell is sent, which is exactly why it has to use the same shared data-fetching function as the page component rather than its own separate query — Next.js's fetch memoization dedupes identical requests made during the same render, so calling getProduct(slug) from both generateMetadata and the page costs one network request, not two, but only if it's actually the same function call, not a copy-pasted variant. The metadataBase requirement fixes a mistake that's invisible in local dev (relative image paths resolve fine against localhost) and only breaks in production when a social platform tries to fetch an OG image from a relative path with no origin. And the explicit fallback-on-failure rule matters because generateMetadata throwing on a 404'd product would otherwise take down the entire page render, not just the metadata.
What you get back
generateMetadata for /products/[slug] returns { title: product.name + ' | Example Shop', description: product.shortDescription, openGraph: { images: [product.heroImage] } } using the same getProduct(slug) call the page uses. If getProduct returns null, metadata falls back to { title: 'Product not found', robots: { index: false } } instead of throwing.
Verified against
Claude Code Sonnet 4.6 · 2026-07-05
GitHub Copilot 2026.7 · 2026-07-10
Changelog
- 2026-07-05 — Initial version, tested against Claude Code on Next.js 16 dynamic product pages.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
