## Why Metadata Matters You can build the fastest, prettiest [Next.js](/courses/nextjs) page on Earth... but if Google sees: ```text Untitled Page ``` and someone shares your link on social media and gets: ```text No title No description No image Just vibes ``` we have a problem. 😭 That's where **metadata** comes in. Metadata describes your page to: - Search engines - Browsers - Social platforms - Messaging apps - Link preview crawlers It includes information such as: ```text Page title Description Canonical URL Open Graph image Twitter/X card Robots instructions Icons ``` Most of this information lives inside the page's: ```html ``` For example: ```html Learn Next.js | My App ``` [Next.js](/courses/nextjs) gives you a built-in **Metadata API** so you don't have to manually manage all of these tags. --- > **Definition: Metadata** > > Metadata is information that describes a webpage to browsers, search engines, crawlers, and social platforms without being part of the page's main visible content. --- # Why Metadata Is Important for SEO Search engines use several signals to understand your pages. Metadata helps provide useful information about: ```text What is this page about? What should its title be? What URL is canonical? Should it be indexed? What image represents it? ``` For example: ```js export const metadata = { title: "Next.js Routing Tutorial for Beginners", description: "Learn file-based routing, dynamic routes, nested routes, and navigation in the Next.js App Router.", } ``` Next.js can generate: ```html Next.js Routing Tutorial for Beginners ``` You describe the page in [JavaScript](/courses/javascript). Next.js handles the actual [HTML](/courses/html) tags. Pretty clean. 😎 --- # Metadata Also Controls Link Previews Imagine you share: ```text https://example.com/blog/nextjs-routing ``` on: - WhatsApp - Slack - Discord - LinkedIn - Facebook - X - Other messaging platforms You may see a rich preview containing: ```text ┌──────────────────────────────┐ │ │ │ Preview Image │ │ │ ├──────────────────────────────┤ │ Next.js Routing Guide │ │ │ │ Learn routing in Next.js... │ └──────────────────────────────┘ ``` That information commonly comes from **Open Graph metadata** and platform-specific metadata such as Twitter/X cards. --- > **Definition: Open Graph** > > Open Graph is a metadata protocol originally created by Facebook that lets websites describe how their pages should appear when shared on social and messaging platforms. Common Open Graph properties include: ```text og:title og:description og:image og:url og:type og:site_name ``` --- # How Metadata Works in the App Router Next.js gives you two main ways to define metadata: ```text 1. Static metadata 2. Dynamic metadata ``` Static metadata uses: ```js export const metadata = {} ``` Dynamic metadata uses: ```js export async function generateMetadata() {} ``` Simple rule: ```text Metadata known while writing code? ↓ metadata object ``` ```text Metadata depends on data or route params? ↓ generateMetadata() ``` --- # 1. Static Metadata Suppose you have: ```text /about ``` The title probably doesn't depend on a database. You already know what it should be. Use: ```js export const metadata ``` Example: ```jsx export const metadata = { title: "About Us", description: "Learn about our company, mission, and team.", } export default function AboutPage() { return (

About Us

) } ``` Next.js automatically turns this into the appropriate metadata elements. No: ```jsx ``` management required. --- # Static Metadata with Open Graph You can add social sharing metadata too. ```jsx export const metadata = { title: "About Us", description: "Learn about our mission and team.", openGraph: { title: "About Us", description: "Learn about our mission and team.", url: "https://example.com/about", siteName: "My App", images: [ { url: "https://example.com/og/about.jpg", width: 1200, height: 630, alt: "About My App", }, ], type: "website", }, twitter: { card: "summary_large_image", title: "About Us", description: "Learn about our mission and team.", images: [ "https://example.com/og/about.jpg" ], }, } ``` Now Next.js generates the relevant: ```text title description Open Graph Twitter/X ``` metadata for you. --- # `metadata` Can Live in Pages or Layouts You can export metadata from: ```text page.jsx ``` or: ```text layout.jsx ``` Example: ```text app/ ├── layout.jsx ├── page.jsx │ └── blog/ ├── layout.jsx └── page.jsx ``` You might define global metadata in: ```text app/layout.jsx ``` and more specific metadata inside: ```text app/blog/page.jsx ``` This creates a metadata hierarchy similar to your layout hierarchy. --- # Metadata Is Server-Side Only The: ```js metadata ``` object and: ```js generateMetadata() ``` are only supported in **[Server Components](/courses/nextjs)**. So this is not valid: ```jsx "use client" export const metadata = { title: "Dashboard" } ``` Instead, keep your page as a Server Component: ```jsx export const metadata = { title: "Dashboard" } export default function Page() { return ( ) } ``` Then move interactivity into: ```jsx "use client" export default function InteractiveDashboard() { // state, events, etc. } ``` Metadata belongs to the server-side route definition. --- # You Cannot Use Both in the Same Segment Inside one: ```text page.jsx ``` or: ```text layout.jsx ``` you choose either: ```js export const metadata ``` or: ```js export function generateMetadata() ``` Not both. So this: ```js export const metadata = { title: "Blog" } export async function generateMetadata() { // ❌ Don't export both } ``` is not valid. Choose the one that fits your situation. --- # 2. Dynamic Metadata Now imagine: ```text /blog/[slug] ``` You could have thousands of articles: ```text /blog/nextjs-routing /blog/react-hooks /blog/javascript-promises ``` Each one needs its own: ```text title description OG image canonical URL ``` You obviously don't want to hardcode all of them. That's where: ```js generateMetadata() ``` comes in. --- # Basic `generateMetadata()` Example ```jsx export async function generateMetadata({ params }) { const { slug } = await params const post = await getPostBySlug(slug) if (!post) { return { title: "Post Not Found" } } return { title: post.title, description: post.excerpt, } } ``` Notice: ```js await params ``` In modern Next.js, route: ```js params ``` is [asynchronous](/javascript/promises-asynchronous-javascript). So this older pattern: ```js params.slug ``` is something you'll still see in older tutorials. Modern code uses: ```js const { slug } = await params ``` --- # Dynamic Blog Metadata A more complete example: ```jsx export async function generateMetadata({ params }) { const { slug } = await params const post = await getPostBySlug(slug) if (!post) { return { title: "Post Not Found", robots: { index: false, follow: false, }, } } return { title: post.title, description: post.excerpt, alternates: { canonical: `/blog/${slug}`, }, openGraph: { title: post.title, description: post.excerpt, url: `/blog/${slug}`, type: "article", images: [ { url: post.coverImage, }, ], }, twitter: { card: "summary_large_image", title: post.title, description: post.excerpt, images: [ post.coverImage ], }, } } ``` Now every article can generate its SEO metadata from the article itself. That's exactly what you want on a content-heavy site. --- # The Page Uses the Same Params Your page might look like: ```jsx export default async function BlogPost({ params }) { const { slug } = await params const post = await getPostBySlug(slug) return (

{post.title}

{post.body}

) } ``` So both: ```text generateMetadata() ``` and: ```text BlogPost() ``` need the same article. Which raises an important question. --- # Does Next.js Fetch the Same Data Twice? Suppose you do: ```jsx export async function generateMetadata({ params }) { const { slug } = await params const response = await fetch( `https://api.example.com/posts/${slug}` ) const post = await response.json() return { title: post.title } } ``` Then your page does the same request: ```jsx export default async function BlogPost({ params }) { const { slug } = await params const response = await fetch( `https://api.example.com/posts/${slug}` ) const post = await response.json() return (

{post.title}

) } ``` For matching `fetch()` requests during the same server rendering work, Next.js automatically memoizes the request. Conceptually: ```text generateMetadata() ↓ fetch post ↓ Network request ``` Then: ```text Page ↓ Same fetch ↓ Reuse memoized result ``` This helps avoid unnecessary duplicate network work. --- > **Interview Highlight** > > **Q: If `generateMetadata()` and the page make the same `fetch()` request, does Next.js necessarily fetch the data twice?** > > No. Matching `fetch()` requests are automatically memoized across places such as `generateMetadata`, `generateStaticParams`, layouts, pages, and [Server Components](/courses/nextjs) during rendering. --- # Important: Database Calls Are Different This is where the original idea often gets explained incorrectly. Next.js automatically memoizes: ```js fetch() ``` But this does **not automatically mean**: ```js db.posts.findBySlug() ``` will magically deduplicate itself. For example: ```js await db.post.findUnique(...) ``` inside: ```text generateMetadata ``` and again inside: ```text page.jsx ``` may execute the database query twice unless you add your own memoization strategy. --- # Using React `cache()` for Database Queries For server-side [functions](/javascript/functions-in-javascript) that don't use `fetch()`, [React](/courses/reactjs) provides: ```js cache() ``` Example: ```js import { cache } from "react" export const getPost = cache(async slug => { return db.post.findUnique({ where: { slug } }) }) ``` Now both: ```js generateMetadata() ``` and: ```js page.jsx ``` can call: ```js getPost(slug) ``` Example: ```jsx export async function generateMetadata({ params }) { const { slug } = await params const post = await getPost(slug) return { title: post.title, description: post.excerpt, } } export default async function Page({ params }) { const { slug } = await params const post = await getPost(slug) return (

{post.title}

) } ``` Much cleaner. --- # Metadata Inheritance Metadata is evaluated through your route hierarchy. Imagine: ```text app/layout.jsx ↓ app/blog/layout.jsx ↓ app/blog/[slug]/page.jsx ``` Metadata from parent layouts can flow down into child routes. For example: ```jsx // app/layout.jsx export const metadata = { title: "My App", description: "Learn modern web development.", openGraph: { siteName: "My App", }, } ``` Then: ```jsx // app/blog/page.jsx export const metadata = { title: "Blog", } ``` The child can override certain fields while inheriting others. --- # Important: Metadata Merging Is Shallow This is an advanced but important detail. Suppose your root layout has: ```js openGraph: { title: "My App", description: "Learn web development.", images: [ "/default-og.jpg" ] } ``` Then your page defines: ```js openGraph: { title: "Next.js Tutorial" } ``` Don't assume Next.js deeply merges every nested Open Graph property. Nested metadata objects are generally **shallowly merged**. The later: ```js openGraph ``` object can replace the earlier one. So you may lose: ```text description images ``` unless you include them again or deliberately extend parent metadata. This is worth remembering when your social previews suddenly lose an image and you start blaming WhatsApp. 😭 --- # Accessing Parent Metadata `generateMetadata()` can receive parent metadata too. Example: ```jsx export async function generateMetadata( { params }, parent ) { const { slug } = await params const post = await getPost(slug) const previousImages = (await parent) .openGraph ?.images || [] return { title: post.title, openGraph: { images: [ post.coverImage, ...previousImages, ], }, } } ``` This lets you extend parent metadata rather than completely replacing it. --- # Title Templates Now imagine your site has 500 pages. You want all titles to end with: ```text | My App ``` You *could* write: ```text Pricing | My App About | My App Blog | My App Dashboard | My App ``` 500 times. Or you could maintain your sanity. 😄 Use a **title template**. --- # Root Title Template Inside: ```text app/layout.jsx ``` write: ```jsx export const metadata = { title: { template: "%s | My App", default: "My App", }, description: "Learn modern web development.", } ``` Now a child page can simply say: ```jsx export const metadata = { title: "Pricing" } ``` Final browser title: ```text Pricing | My App ``` Very useful. --- # `default` Title The: ```js default ``` value is used when a child doesn't provide a title. Example: ```js title: { template: "%s | My App", default: "My App - Learn Web Development", } ``` If the page has no title: ```text My App - Learn Web Development ``` If the page provides: ```text Next.js Tutorial ``` you get: ```text Next.js Tutorial | My App ``` --- # Canonical URLs Here's another important SEO concept: **Canonical URLs** Suppose the same page could appear through multiple URLs: ```text /products/macbook ``` and: ```text /products/macbook?ref=homepage ``` You may want to tell search engines: > "This is the main URL for this content." That's what: ```text rel="canonical" ``` does. Next.js supports this using: ```js alternates ``` Example: ```jsx export const metadata = { alternates: { canonical: "https://example.com/products/macbook", }, } ``` Next.js generates something like: ```html ``` For SEO-heavy applications, this is very useful. --- # `metadataBase` Writing full absolute URLs everywhere becomes annoying. Instead, set: ```js metadataBase ``` in your root layout. Example: ```jsx export const metadata = { metadataBase: new URL( "https://example.com" ), title: { template: "%s | Example", default: "Example", }, } ``` Now child routes can use relative URLs. Example: ```jsx export const metadata = { alternates: { canonical: "/about", }, openGraph: { images: [ "/og/about.jpg" ], }, } ``` Next.js can resolve them against: ```text https://example.com ``` to produce: ```text https://example.com/about ``` and: ```text https://example.com/og/about.jpg ``` Much cleaner. --- # A Strong Root Metadata Setup A practical root layout might contain: ```jsx export const metadata = { metadataBase: new URL( "https://example.com" ), title: { template: "%s | Example", default: "Example - Learn Web Development", }, description: "Learn modern web development with practical tutorials.", openGraph: { type: "website", siteName: "Example", images: [ { url: "/og/default.jpg", width: 1200, height: 630, alt: "Example", }, ], }, twitter: { card: "summary_large_image", }, } ``` Then individual pages only need to define what changes. That's a much better architecture than repeating your full SEO configuration everywhere. --- # Robots Metadata Sometimes you **don't** want a page indexed. Examples: ```text /admin /dashboard /search /private preview pages ``` You can use: ```js robots ``` Example: ```jsx export const metadata = { robots: { index: false, follow: false, }, } ``` Conceptually: ```text index: false ``` means: > "Don't include this page in search results." And: ```text follow: false ``` asks crawlers not to follow links from the page. For public content, you'll usually allow indexing. For private application pages, you may choose otherwise. --- # Open Graph Images A strong social preview usually needs: ```text Title Description Image ``` Example: ```jsx export const metadata = { openGraph: { title: "Next.js Metadata Guide", description: "Learn SEO and metadata in Next.js.", images: [ { url: "/og/nextjs-metadata.jpg", width: 1200, height: 630, alt: "Next.js Metadata Guide", }, ], }, } ``` A common OG image size is: ```text 1200 × 630 ``` which works well across many platforms. --- # File-Based Metadata Now for one of the nicest [App Router](/courses/nextjs) features. Some metadata doesn't even need a [JavaScript](/courses/javascript) object. Next.js recognizes special filenames automatically. Examples: ```text favicon.ico icon.png apple-icon.png opengraph-image.jpg twitter-image.jpg robots.txt sitemap.xml manifest.json ``` Place them in the appropriate App Router location and Next.js can automatically generate the related metadata. --- # Example File Structure ```text src/app/ ├── favicon.ico ├── icon.png ├── opengraph-image.jpg ├── twitter-image.jpg ├── robots.js ├── sitemap.js ├── layout.jsx └── page.jsx ``` Next.js understands these names. No: ```jsx ``` manually required. --- # File-Based Metadata Has Higher Priority This is worth knowing. If file-based metadata and config-based metadata conflict, **file-based metadata has higher priority**. For example, an: ```text opengraph-image.jpg ``` file can override an Open Graph image defined through: ```js metadata ``` or: ```js generateMetadata() ``` So if your OG image refuses to change... check whether somebody left: ```text opengraph-image.jpg ``` sitting in the route folder like a tiny SEO saboteur. 😭 --- # Favicons The easiest favicon setup is: ```text src/app/favicon.ico ``` Next.js recognizes it automatically. You can also use special icon files such as: ```text icon.png apple-icon.png ``` for different platforms. --- # `robots.js` Instead of manually maintaining: ```text robots.txt ``` you can generate it using JavaScript. Example: ```js export default function robots() { return { rules: { userAgent: "*", allow: "/", disallow: [ "/admin/", "/dashboard/", ], }, sitemap: "https://example.com/sitemap.xml", } } ``` Next.js generates: ```text /robots.txt ``` from it. This can be extremely useful when your robots configuration depends on deployment environment or application logic. --- # `sitemap.js` A sitemap helps search engines discover important URLs. Create: ```text src/app/sitemap.js ``` Example: ```js export default function sitemap() { return [ { url: "https://example.com", lastModified: new Date(), changeFrequency: "weekly", priority: 1, }, { url: "https://example.com/about", lastModified: new Date(), changeFrequency: "monthly", priority: 0.8, }, { url: "https://example.com/blog", lastModified: new Date(), changeFrequency: "daily", priority: 0.9, }, ] } ``` Next.js serves it as: ```text /sitemap.xml ``` Pretty convenient. --- # Dynamic Sitemaps For content-heavy sites, manually writing every URL would be painful. Imagine: ```text 20,000 articles ``` Yeah, no. 💀 Instead: ```js export default async function sitemap() { const posts = await db.post.findMany({ select: { slug: true, updatedAt: true, }, }) return posts.map(post => ({ url: `https://example.com/blog/${post.slug}`, lastModified: post.updatedAt, })) } ``` Now your sitemap can be built from your actual content. This is especially useful for: - Blogs - Learning platforms - E-commerce sites - Documentation - News sites - Large content libraries --- # Dynamic Open Graph Images Here's one of the coolest Metadata API features. Imagine you have 10,000 blog posts. Instead of manually creating 10,000 OG images, Next.js can generate them. Create: ```text app/blog/[slug]/opengraph-image.jsx ``` and use: ```js ImageResponse ``` from: ```js next/og ``` --- # Dynamic OG Image Example ```jsx import { ImageResponse } from "next/og" export const size = { width: 1200, height: 630, } export const contentType = "image/png" export default async function Image({ params }) { const { slug } = await params const post = await getPost(slug) return new ImageResponse( (

{post.title}

), { ...size, } ) } ``` Now each post can receive its own generated social preview. Conceptually: ```text /blog/react-hooks ↓ Generate OG image ↓ "React Hooks Explained" ``` and: ```text /blog/nextjs-routing ↓ Generate OG image ↓ "Next.js Routing Guide" ``` Same template. Different content. 🔥 --- # Why Dynamic OG Images Are Powerful They work especially well for: - Articles - Course chapters - Product pages - User profiles - Documentation pages - Events - News content Instead of designing thousands of images manually, your application can generate them from data. --- # Metadata Streaming Modern Next.js includes another interesting feature: **Streaming Metadata** Suppose: ```js generateMetadata() ``` needs a slow request. Traditionally, you might imagine the entire page must wait until the metadata finishes. Modern Next.js can sometimes send the initial UI first and stream the resolved metadata afterward. Conceptually: ```text Request ↓ Start rendering page ↓ Send initial UI ↓ generateMetadata resolves ↓ Metadata added ``` This can improve perceived page performance. --- # What About Social Bots? Not every crawler behaves like a modern browser. Some social preview bots expect metadata to be available immediately in the document head. Next.js handles this automatically for known [HTML](/courses/html)-limited bots. So the framework can use: ```text Streaming metadata ``` for capable clients, while ensuring metadata blocks rendering for crawlers that need traditional: ```html ``` metadata. You generally don't need to configure this yourself. Next.js handles the boring crawler detective work for you. 😎 --- # Metadata and Cache Components If you're using the modern Next.js Cache Components model, `generateMetadata()` follows similar caching rules to other server-side work. If your metadata comes from reusable external data, it can be cached. For example: ```jsx export async function generateMetadata() { "use cache" const site = await getSiteSettings() return { title: site.title, description: site.description, } } ``` But if metadata genuinely depends on request-time information such as: ```text cookies headers searchParams ``` it may need to resolve at request time. This is another example of modern Next.js treating metadata as part of the rendering architecture rather than a separate afterthought. --- # Viewport Metadata Older Next.js code may define things like: ```js themeColor ``` inside: ```js metadata ``` Modern Next.js moved viewport-related fields into a separate: ```js viewport ``` export. Example: ```jsx export const viewport = { width: "device-width", initialScale: 1, themeColor: "#ffffff", } ``` --- # Do You Need to Configure the Viewport? Usually? Not much. Next.js already provides a sensible default viewport: ```text width=device-width initial-scale=1 ``` So you don't normally need to copy this into every project just because you saw it in a tutorial. Use the: ```js viewport ``` export when you actually need to customize something. For example: ```jsx export const viewport = { themeColor: "#111827", } ``` --- # Dynamic Viewport There is also: ```js generateViewport() ``` for cases where viewport settings genuinely depend on dynamic information. Example: ```jsx export function generateViewport() { return { themeColor: "#000000", } } ``` Most applications will never need dynamic viewport logic. And that's okay. Not every API needs to become part of your personality. 😭 --- # Static Metadata vs Dynamic Metadata Here's the simple comparison: | Situation | Use | |---|---| | Title known ahead of time | `metadata` | | Description known ahead of time | `metadata` | | Blog metadata comes from database | `generateMetadata()` | | Product metadata comes from API | `generateMetadata()` | | Dynamic canonical URL | `generateMetadata()` | | Global site name | Root `metadata` | | Reusable title suffix | `title.template` | | Dynamic social preview | `opengraph-image.jsx` | | Sitemap | `sitemap.js` | | Robots rules | `robots.js` | | Favicon | `favicon.ico` | | Viewport settings | `viewport` | --- # A Real-World Blog Setup Imagine you have: ```text example.com ``` with thousands of articles. Your root layout could contain: ```jsx export const metadata = { metadataBase: new URL( "https://example.com" ), title: { template: "%s | Example", default: "Example - Developer Tutorials", }, description: "Learn JavaScript, React, Next.js, Node.js and modern web development.", openGraph: { type: "website", siteName: "Example", }, twitter: { card: "summary_large_image", }, } ``` Then: ```text blog/[slug]/page.jsx ``` uses: ```jsx export async function generateMetadata({ params }) { const { slug } = await params const post = await getPost(slug) return { title: post.title, description: post.excerpt, alternates: { canonical: `/blog/${slug}`, }, openGraph: { title: post.title, description: post.excerpt, url: `/blog/${slug}`, type: "article", }, } } ``` Then add: ```text blog/[slug]/opengraph-image.jsx ``` for dynamic social images. And: ```text app/sitemap.js ``` for search engines. Now you've built a pretty serious SEO architecture without manually managing: ```html ``` on every page. --- # Common Mistake: Using the Same Metadata Everywhere Bad: ```text Home Title: My Website Blog Title: My Website Next.js Article Title: My Website React Article Title: My Website ``` Search engines and users now have almost no clue what each page is actually about. Better: ```text Home My Website - Developer Tutorials Blog Developer Blog | My Website Next.js Article Next.js Server Components Explained | My Website React Article Understanding useEffect in React | My Website ``` Each page should accurately describe its own content. --- # Common Mistake: Keyword Stuffing Don't do: ```js title: "Next.js Tutorial Next.js Course Learn Next.js NextJS Guide Best NextJS Tutorial" ``` That's not optimization. That's your title having a panic attack. 💀 Write metadata for humans first. Good: ```text Next.js Server Components: Beginner Guide ``` Clear. Specific. Useful. --- # What About `keywords`? Next.js supports a: ```js keywords ``` metadata field. Example: ```js export const metadata = { keywords: [ "Next.js", "React", "App Router", ], } ``` But don't confuse: ```text metadata keywords ``` with your actual SEO keyword strategy. Modern search engines may ignore traditional: ```html ``` signals. Your real keyword targeting should naturally appear in things that matter more: ```text Page title Headings Body content URLs Internal links Descriptions Structured content ``` Don't spend three hours perfecting a meta keywords list while your actual article says nothing useful. 😄 --- # Common Mistake: Missing Canonicals If your application creates multiple URLs pointing to similar content, use a canonical URL where appropriate. For example: ```js alternates: { canonical: `/blog/${slug}`, } ``` This helps establish the preferred URL for the content. --- # Common Mistake: Bad Social Images A link preview containing: ```text Broken Image ``` doesn't exactly scream: > "Click me, I'm trustworthy." 😭 Make sure your Open Graph image: - Exists - Is publicly accessible - Uses a suitable aspect ratio - Has readable text - Represents the page - Isn't enormous - Isn't blocked from crawlers --- # Common Mistake: Fetching Database Data Twice If both: ```text generateMetadata ``` and: ```text page ``` query your database independently: ```js db.post.findUnique(...) ``` don't assume automatic `fetch()` memoization applies. Consider creating one memoized server [function](/javascript/functions-in-javascript): ```js import { cache } from "react" export const getPost = cache(async slug => { return db.post.findUnique({ where: { slug } }) }) ``` Then reuse it. Cleaner architecture. Less unnecessary database work. --- # Metadata Mental Model Think of your SEO structure like this: ```text ROOT LAYOUT │ ├── Site name ├── Default title ├── Title template ├── Default description ├── metadataBase ├── Default social metadata │ └── PAGE │ ├── Specific title ├── Specific description ├── Canonical URL ├── OG metadata └── Twitter/X metadata ``` Then add file-based features: ```text favicon.ico robots.js sitemap.js opengraph-image.jsx ``` Now your metadata architecture scales with your application instead of becoming copy-paste soup. --- # Quick Reference | Feature | API | |---|---| | Static title | `metadata.title` | | Static description | `metadata.description` | | Dynamic metadata | `generateMetadata()` | | Site-wide title pattern | `title.template` | | Default title | `title.default` | | Base domain | `metadataBase` | | Canonical URL | `alternates.canonical` | | Social metadata | `openGraph` | | Twitter/X card | `twitter` | | Search indexing control | `robots` | | Favicon | `favicon.ico` | | Open Graph image | `opengraph-image.jpg` | | Dynamic OG image | `opengraph-image.jsx` + `ImageResponse` | | Sitemap | `sitemap.js` | | Robots file | `robots.js` | | Viewport settings | `viewport` | | Dynamic viewport | `generateViewport()` | --- # Interview Quick Hits > **Q: What is the difference between `metadata` and `generateMetadata()`?** > > `metadata` is used when metadata is known statically, while `generateMetadata()` is used when metadata depends on route parameters, external data, or other dynamic information. --- > **Q: Can `metadata` be exported from a Client Component?** > > No. `metadata` and `generateMetadata()` are only supported in Server Components. --- > **Q: Can you export both `metadata` and `generateMetadata()` from the same page?** > > No. A route segment must use one or the other. --- > **Q: Are duplicate database calls automatically memoized?** > > Not automatically. Matching `fetch()` requests are memoized during rendering, but database or ORM functions may need [React](/courses/reactjs) `cache()` or another memoization/caching strategy. --- > **Q: How do you create metadata for a dynamic route?** > > Export an [async](/javascript/promises-asynchronous-javascript) `generateMetadata()` function and resolve the route `params`. --- > **Q: How do you create dynamic OG images?** > > Create an `opengraph-image.jsx` or `.tsx` file and return an `ImageResponse`. --- > **Q: Where should viewport configuration go?** > > Use the separate `viewport` export or `generateViewport()` API rather than putting viewport-related fields inside the Metadata API. --- # Summary Next.js gives you a built-in metadata system for managing SEO and social sharing information without manually writing `` tags everywhere. The most important things to remember are: - Use `metadata` for static metadata - Use `generateMetadata()` when metadata depends on data or route parameters - Modern dynamic `params` should be awaited - `metadata` and `generateMetadata()` only work in Server Components - You cannot export both from the same route segment - Matching `fetch()` requests are automatically memoized during rendering - Arbitrary database calls are not automatically memoized the same way - React `cache()` can help deduplicate reusable server-side data functions - Parent layouts can provide metadata inherited by child pages - Metadata merging is shallow for nested objects such as `openGraph` - `title.template` avoids repeating your site name - `metadataBase` makes URL-based metadata easier to manage - `alternates.canonical` defines canonical URLs - `openGraph` controls social sharing metadata - `robots` controls crawler instructions - `favicon.ico`, `opengraph-image`, `robots`, and `sitemap` have special file conventions - File-based metadata has higher priority than config-based metadata - `ImageResponse` can generate dynamic OG images - Modern Next.js supports streaming metadata - Viewport settings use the separate `viewport` API The big mental model is: ```text Page Content ↓ What humans see Metadata ↓ How browsers, search engines, and sharing platforms understand and represent that page ``` Good metadata won't magically make bad content rank #1, but it makes sure every great page gets a clear title, description, canonical URL, and share preview instead of showing up on the internet looking half-dressed. 😭 And that's exactly the goal on **asif.to** — build useful developer content first, then give search engines and sharing platforms clean signals so that content has the best chance to be discovered, understood, and clicked. 🚀