Reference
Glossary
Plain-English definitions of the SEO and engineering terms that come up during a WordPress to Next.js migration.
301 Redirect
A server response that tells browsers and search engines a page has permanently moved to a new URL. During a WordPress to Next.js migration, every indexed old URL needs a 301 to its new home. Miss one and Google treats the new URL as a fresh, unranked page. A 302 is not a substitute. 302 signals temporary and does not fully pass ranking signals. Edge redirects at the CDN layer are the fastest. Application-level redirects are fine for smaller sites. Chains of two or more redirects cost crawl budget and should be collapsed to a single hop.
Canonical Tag
An HTML tag that tells Google which version of a page is the source of truth when duplicate or near-duplicate URLs exist. Looks like rel=canonical in the head. Common triggers during migration: trailing slash variants, tracking parameters, pagination, and language alternates. Every page should have exactly one canonical that points to itself unless you intentionally want to consolidate. Mismatched canonicals after a rebuild are one of the most common causes of sudden deindexing.
Canonical Drift
Canonical drift is a migration defect where the canonical URL on a rebuilt page no longer matches the URL that should rank. The page can return 200 and look correct, while the canonical points to an old WordPress URL, staging URL, redirected URL, or filtered duplicate.
Example: /blog/migration-guide is live on the new site, but the canonical still points to oldsite.com/blog/migration-guide/ or to a redirected staging URL. Google now has mixed signals about which URL is authoritative.
Core Web Vitals
Google's three measured speed and stability metrics: LCP, INP, and CLS. LCP tracks how fast the largest visible element paints. INP tracks how quickly the page responds to interaction. CLS tracks how much the layout shifts during load. Google uses these as a ranking signal for all sites. A WordPress site loaded with builder plugins usually fails one or more. A well-built Next.js site usually passes all three without tuning.
Crawl Budget
The number of URLs Googlebot will fetch from your site in a given window. Small sites rarely run into budget limits. Sites with thousands of pages, faceted navigation, or parameter explosions can burn budget on low-value URLs, leaving important pages uncrawled. Clean internal linking, tight robots.txt rules, and correct canonicals keep budget focused on pages that should rank.
DefinedTerm
A Schema.org type used to mark up individual vocabulary entries, usually inside a DefinedTermSet. This glossary uses it to make each definition explicit in structured data. DefinedTerm needs a name, a description, and an inDefinedTermSet reference to group related terms together.
INP (Interaction to Next Paint)
Google's replacement for First Input Delay as of March 2024. Measures how long the page takes to visually respond after a user taps, clicks, or presses a key. Target is under 200 milliseconds. WordPress sites with heavy JavaScript bundlers, third-party chat widgets, or builder plugins commonly land above 500 ms. Moving rendering to the server and deferring non-critical scripts brings INP into range without gutting functionality.
LCP (Largest Contentful Paint)
The time it takes for the largest visible element on the page to finish rendering. Usually a hero image or a block of text above the fold. Target is under 2.5 seconds on mobile. LCP is the single metric most correlated with whether a page feels fast. WordPress with a builder plugin typically lands at 3 to 5 seconds. A static-rendered Next.js page usually lands under 2 seconds.
Metadata Parity
A verification step during migration where every new URL is checked to ensure its title tag, meta description, canonical, Open Graph tags, and indexation directives match what the old URL had, unless a deliberate improvement was approved. Missing metadata parity after launch is the fastest way to drop a page out of SERP features. We run automated diffs before launch and after launch to confirm nothing silently disappeared.
Mobile-First Indexing
Google crawls and ranks your site based on the mobile version, not the desktop one. Has been the default since 2019. If your mobile page hides content, lazy-loads critical data client-side, or renders differently than desktop, Google ranks the mobile version. Most ranking losses during migration trace back to mobile rendering issues, not desktop.
Next.js App Router
The routing system introduced in Next.js 13 and now the default. File-based routing inside src/app with server components by default, streaming, and native metadata handling. Preferred for new migrations because it makes metadata parity and per-route caching easier to get right. Requires a different mental model than the Pages Router. Cannot be mixed casually with Pages Router on the same route tree.
Next.js Pages Router
The original file-based routing system in Next.js, based on the pages directory. Still fully supported. Uses getStaticProps and getServerSideProps for data fetching. Many older Next.js codebases and tutorials use it. New migrations default to the App Router. Pages Router is a fine choice if the team already knows it and the site does not need streaming or server components.
Redirect Chain
A redirect chain is two or more redirects in sequence. Browsers and crawlers have to follow each hop, which costs crawl budget and slows users. During migration QA, old URLs should resolve in one hop from the legacy URL to the final canonical destination.
Example: /old-service redirects to /services, then to /services/wordpress-to-nextjs-migration. The fix is one direct 301 from /old-service to the final canonical page.
Redirect Loop
A redirect that eventually points back to itself, creating an infinite cycle. Kills the page for users and crawlers immediately. Usually caused by mismatched rules across server config, CDN, and application layers during a migration. The fix is always to pick one layer to own redirects and remove conflicting rules from the others.
Redirect Map
A redirect map is the migration table that pairs every old URL with its new destination, status code, priority, and test result. It should be built from a full crawl, sitemap, Search Console, analytics, and backlink data, not from the visible navigation alone.
Example: /old-category/blue-widgets maps to /products/blue-widgets with a 301 status, a 200-status destination check, and a priority note if the old URL had clicks or backlinks.
Migration Rollback
A migration rollback is the decision to restore the old site, old routes, or previous deployment because the launch is causing unacceptable SEO or conversion damage. For SEO, the rollback plan must preserve URL responses, redirects, canonicals, robots rules, sitemap state, analytics, and Search Console evidence.
Example: the new Next.js launch ships with thousands of product URLs missing from the sitemap and canonical tags pointing to staging. The rollback path restores the last known stable deployment while the redirect map, sitemap, and canonical generator are fixed.
Rich Results
Enhanced search result formats such as review stars, breadcrumbs, product snippets, and other supported Search features. Valid structured data can make a page eligible, but Google decides whether to show a rich result and some older formats, including FAQ rich results, no longer appear in Google Search.
Schema Parity
Schema parity is the migration check that every useful structured data block on the old site has a matching, valid block on the new site where the visible content still supports it. It covers Product, Article, Organization, BreadcrumbList, Review, FAQPage, and other page-type markup without assuming every schema type still produces a Google rich result.
Example: old WordPress blog posts used BlogPosting, BreadcrumbList, and FAQPage JSON-LD. The rebuilt Next.js post template should render equivalent valid JSON-LD from the post metadata, not a hardcoded generic object.
Sitemap Parity
Sitemap parity means the new XML sitemap contains every canonical, indexable URL that should survive the migration, and excludes old, redirected, noindexed, parameter, staging, or duplicate URLs. It is checked by comparing the old crawl, old sitemap, GSC top pages, analytics landing pages, and new sitemap output.
Example: the old WordPress sitemap had 2,500 product URLs and 120 category URLs. The new Next.js sitemap should include the surviving canonical product and category URLs, split into sitemap indexes if needed, and each listed URL should return 200 with a self-canonical.
Server-Side Rendering (SSR)
The server generates the full HTML of the page on each request before sending it to the browser. Gives search engines a fully rendered page without waiting for client-side JavaScript. Good for content that changes often or depends on user session. Higher server cost than static generation. Next.js supports SSR through the App Router's dynamic rendering mode.
Static Generation (SSG)
HTML is generated once at build time and served as a static file. Fastest possible response because there is no server computation per request. Perfect for blog posts, marketing pages, and documentation. Next.js generates static pages by default in the App Router when there is no dynamic data dependency. Pages can be revalidated on a schedule to stay fresh.
Structured Data
Machine-readable tags that describe what a page is about. Usually written as JSON-LD in a script tag. Google and other search systems use structured data to understand entities, relationships, and facts. Valid structured data can qualify content for supported rich result formats, but it does not guarantee display in Search or special inclusion in AI features.
Trailing Slash Consistency
Pick one: URLs end with a slash or they do not. Mixed behavior creates duplicate content, splits ranking signals, and causes redirect chains. WordPress defaults to trailing slashes on permalinks. Next.js App Router defaults to no trailing slash. Pick a convention at the start of the migration, redirect the other variant, and enforce it in next.config with trailingSlash set explicitly.
URL Parameter Handling
How your site treats query strings like ?utm_source=x or ?color=red. Each unique parameter combination is a separate URL to Google. Without rules, parameters can balloon into thousands of near-duplicate pages. Fixes: canonical tags that point to the clean URL, robots.txt disallow for parameters that should never be crawled, and proper use of rel=nofollow on filtered links.
XML Sitemap
A machine-readable list of URLs you want search engines to crawl. Lives at /sitemap.xml by convention. Should include only canonical, indexable URLs with 200 status codes. Next.js App Router supports sitemap generation through app/sitemap.ts. After a migration, resubmit the new sitemap in Search Console and keep the old one live for a few weeks so Google can reconcile the two.
Hreflang
An HTML tag that tells Google which language or regional version of a page should appear for which audience. Required for multilingual sites. Must be bidirectional: page A in English references page B in French, and page B must reference page A back. Hreflang errors are one of the most common silent traffic killers during international migrations. Verify every page in Search Console after launch.
robots.txt
A text file at the root of your domain that tells crawlers which paths they are allowed to fetch. Not a security control. Not an indexing directive. If you want a page out of the index, use a noindex meta tag, not robots.txt. The most common migration mistake is shipping a robots.txt that disallows the entire site because staging left it in place.