Question 1

Does the Next.js App Router hurt AI crawler visibility compared to the Pages Router?

Accepted Answer

Not inherently, but the default patterns in the App Router create new failure modes the Pages Router did not have. The biggest is streaming with Suspense. When a page wraps a data-dependent component in a Suspense boundary, Next.js streams the shell first and the fallback HTML for that boundary, then later flushes the resolved component. A modern browser holds the connection open and patches the DOM as chunks arrive. Many AI crawlers — including the lighter HTTP fetchers used by ChatGPT browsing, Perplexity's bot, and Common Crawl — read the initial chunk and disconnect. They see the Suspense fallback, not the resolved content. The fix is not to abandon the App Router. It is to be deliberate about which content is allowed to stream, which content blocks the initial response, and which components render on the server versus the client. The teams getting cited in 2026 made those decisions consciously rather than defaulting to the framework's happy path.

Question 2

What is the difference between server components and client components for AEO?

Accepted Answer

Server components render entirely on the server and ship as HTML in the initial response. Client components ship as JavaScript bundles that hydrate in the browser. For AI crawlers, the difference is decisive. AI crawlers that do not execute JavaScript see the full content of server components and see nothing inside client components except whatever placeholder the server rendered before hydration. The practical rule is to default every page-level component and every content-bearing component — articles, product descriptions, FAQ blocks, schema markup, pricing tables — to server components. Use client components only for genuinely interactive surfaces like modals, dropdowns, theme toggles, and forms. Mixing server and client incorrectly is the most common Next.js 15 AEO bug we see in audits. A correctly architected App Router page should ship its primary content as static HTML with stable URLs, and reserve interactivity for the leaf nodes.

Question 3

How does the Next.js 15 Metadata API affect AI search citations?

Accepted Answer

The Metadata API in Next.js 15 is the canonical way to generate page metadata — title, description, Open Graph tags, Twitter cards, robots directives, and JSON-LD when paired with the script tag pattern. For AEO, three of its capabilities matter most. First, generateMetadata as an async function lets pages compute titles and descriptions from the same data fetch the page uses, which keeps metadata accurate even when content changes. Second, the openGraph object generates the OG tags that AI crawlers ingest for entity extraction and link previews. Third, the metadataBase property and absolute URL handling fix a class of broken-OG-tag bugs that used to silently kill social and AI citation. Pairing the Metadata API with a JSON-LD injection pattern in the same layout gives AI crawlers a consistent metadata surface across the site. The Vercel-hosted reference sites — Linear, Cal.com, Cursor — all use this pattern in production.

Question 4

Should I use the App Router or Pages Router if AEO is my top priority?

Accepted Answer

Use the App Router. The Pages Router still works and is supported, but the App Router is where Next.js 15 and Next.js 16 are receiving new features, including the metadata improvements, Partial Prerendering, and the more granular caching primitives that matter for AI crawler performance. The App Router is also where the React ecosystem is moving — React Server Components are the platform direction for the next decade. The transition cost is real, but the AEO downside of staying on the Pages Router is that you will fall behind on framework features the cited competitors are already using. The decision is not App Router versus Pages Router for AEO. It is App Router versus other frameworks like Remix or Astro, where the underlying rendering models are genuinely different and where the tradeoffs are worth comparing. For most teams running on Vercel or self-hosted Next.js, the App Router is the right answer in 2026.

Question 5

What is Partial Prerendering and is it good for AI crawlers?

Accepted Answer

Partial Prerendering, or PPR, is a Next.js 15 rendering mode that combines static and dynamic content on the same page. The page is prerendered at build time with a static shell. When a request arrives, the dynamic portions stream in. The key AEO question is whether the static shell contains enough cited content to serve as a useful response for an AI crawler that does not wait for the stream. If your hero copy, product description, schema markup, and primary content are in the static shell, PPR is fine. If the primary content is inside a dynamic hole, PPR will harm citation rate. The pattern that works in practice is to use PPR for pages where the static portion is the substantive content — blog posts, documentation, product pages — and reserve dynamic holes for personalization, real-time pricing, or other content that genuinely requires per-request data. Treat the static shell as the AEO surface and design accordingly.