Why this is a strong SEO topic

Next.js caching changed significantly across recent App Router versions. Developers are searching for concrete examples because the old mental model does not fully apply. Long-tail searches like "Next.js use cache example", "Cache Components App Router", and "cacheTag revalidateTag Next.js" are practical and high-intent.

• Performance-focused developers want faster TTFB and fewer repeated database calls.
• SEO-focused teams want pages that render quickly and consistently.
• App Router users need migration guidance from older caching patterns.
• Interview candidates need a clear explanation of static, dynamic, and cached server work.

The basic use cache mental model

The use cache directive marks a route, component, or async function as cacheable. Instead of recomputing the same result for every request, Next.js can reuse the cached output according to the configured lifetime and revalidation rules.

export async function getProducts() {
  'use cache';

  const products = await db.product.findMany({
    where: { isPublished: true },
  });

  return products;
}

The important part is not the syntax. The important part is choosing the right boundary. Cache stable product data, documentation pages, public category lists, and expensive computations. Do not cache request-specific data unless you are using the correct private pattern.

Route-level caching

If an entire page is public and deterministic, route-level caching can be clean. A blog article, documentation page, or public landing page often fits this model. The route can be cached while dynamic elements such as a user avatar are composed outside the cached boundary or loaded separately.

// app/blog/[slug]/page.tsx
'use cache';

export default async function BlogPost({ params }) {
  const post = await getPost(params.slug);
  return <Article post={post} />;
}

This can improve performance for SEO-critical pages because the server does less repeated work for the same public content.

Component-level caching

Component-level caching is useful when only part of the page is stable. For example, an e-commerce product page may have public product details, but price experiments, inventory, recommendations, or user-specific discounts may be dynamic.

export async function ProductDetails({ slug }) {
  'use cache';

  const product = await getPublicProductBySlug(slug);
  return <ProductSummary product={product} />;
}

This gives you a smaller, safer cache boundary. The rest of the page can still read cookies, headers, or session state outside the cached scope.

Function-level caching

Function-level caching works well for repeated data access or expensive calculations. If multiple components need the same stable lookup, caching the function avoids duplicating both code and work.

export async function getPopularTags() {
  'use cache';

  return db.tag.findMany({
    where: { postCount: { gt: 0 } },
    orderBy: { postCount: 'desc' },
    take: 25,
  });
}

This pattern is especially useful in layouts, sidebars, footer data, nav menus, sitemap helpers, and public category pages.

Revalidation with cache tags

Caching becomes production-ready when you can invalidate it deliberately. Cache tags let you group cached work and revalidate the right pieces after a mutation.

import { cacheTag } from 'next/cache';

export async function getPost(slug) {
  'use cache';
  cacheTag('post:' + slug);
  return db.post.findUnique({ where: { slug } });
}

// In a server action after updating the post:
// revalidateTag('post:' + slug)

The practical rule: tag cached data by the thing that changes. A product page should have a product tag. A blog article should have an article tag. A category list should have a category or collection tag.

Common mistakes

• Reading cookies or headers inside a shared cached function.
• Caching user-specific data with a public cache boundary.
• Adding use cache too high in the tree and accidentally caching dynamic UI.
• Forgetting revalidation after admin edits.
• Using one broad cache tag for everything and invalidating too much.
• Caching data that changes every few seconds and then fighting stale UI.

Caching should reduce repeated work. It should not make the application harder to reason about. If a cache boundary makes data ownership unclear, move the boundary lower.

Interview explanation

A strong answer: use cache lets Next.js cache the result of a route, component, or async function. It is best for deterministic server work. Runtime values such as cookies and headers should be read outside cached scopes and passed as explicit arguments only when safe. Revalidation should be designed with cache tags that match the data model.

Quick FAQ

Should every App Router page use use cache?

No. Cache public, deterministic work. Keep personalized, request-specific, or rapidly changing data dynamic unless you are using a private caching strategy intentionally.

Is use cache good for SEO?

It can help SEO indirectly by improving speed and consistency for public pages. The content still needs to be useful, crawlable, and correctly linked.

What is the safest first use case?

Start with public content such as blog articles, docs pages, category lists, and expensive public database reads that change only after admin actions.

Official references

• Next.js documentation: use cache
• Next.js documentation: Cache Components