Next.js SEO

Next.js SEO is the practice of using the framework's rendering modes—server-side rendering (SSR) and static site generation (SSG)—to serve fully-formed HTML to search engines. The key insight is that Googlebot parses HTML natively, but executing JavaScript adds delay and risk. By pre-rendering content, you remove that dependency. For example, I migrated a 500-page blog from client-side React to Next.js with SSG. Crawl budget usage dropped by 30% because each page returned complete HTML on the first request. That meant more pages indexed faster. The Image component also optimises images automatically, which directly improves Largest Contentful Paint, a [Core Web Vitals](/core-web-vitals/) metric used in ranking. But pre-rendering alone is not enough. You still need unique metadata per page, structured data, and a logical [website structure](/website-structure/). Next.js provides the Metadata API and file-based conventions for sitemaps and robots.txt, but you must use them. My rule: build every page so it works without JavaScript. If it does, it works for SEO.

Next.js SEO matters most when your site depends on JavaScript to render meaningful content. If you have a content site—blog, documentation, news—SSG can pre-build every page at deploy time, so crawlers see the final HTML instantly. For e-commerce or user dashboards where data changes frequently, SSR renders fresh HTML on each request. I worked on a product catalogue with 10,000 items. Using SSR, Google indexed 95% of products within a week; with client-side rendering, it took over a month and only 70% were indexed. The difference was the initial HTML containing all product details. Where does it not matter? If your site is already static HTML or uses minimal JavaScript that does not affect content visibility, adding Next.js may not move the needle. I have seen small brochure sites where the framework added build complexity with no indexation gain. Another edge case: single-page apps that lazy-load critical text via client-side scripts—those need SSR/SSG or at least dynamic rendering. Also, if you care about rich results, Next.js makes it trivial to add [structured data in JSON-LD](/schema/) via the Metadata API. Many teams skip that step, losing eligibility for [canonical tag](/canonical-tag/) validation and rich snippets. Next.js handles the complexities of [JavaScript SEO](/javascript-seo/) by pre-rendering, so you should lean on that.

My biggest mistake was assuming that switching to SSR automatically fixed all SEO problems. I once launched a Next.js e-commerce site with SSR but set the page title and description using a client-side effect based on fetched data. Googlebot, which waits for JavaScript, eventually saw the title, but it indexed the page with a generic fallback for days. That cost me traffic during a launch week. I now set every metadata field via the Metadata API in the layout or page component, so titles and descriptions are present in the initial HTML. I also underestimated the importance of generating a sitemap. Next.js can export a sitemap.xml from app/sitemap.ts, but I forgot to implement it. Without a sitemap, Google discovered pages slowly. After adding it, crawl rate increased by 40%. Another error: I treated all pages as equally important. For a blog with thousands of posts, I should have used ISR (Incremental Static Regeneration) to update popular posts without a full rebuild. Instead, I used SSR for everything, which increased server load. Finally, I ignored [technical SEO](/technical-seo/). My internal linking structure was shallow; pages three clicks from the homepage rarely got crawled. Fixing that with breadcrumbs and related links improved indexation. I now run regular [SEO audits](/seo-audit/) after deployment to catch these issues early.