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.
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. It tells search engines and AI systems that each entry is a formal definition, which helps with citation in AI Overviews and answer boxes. 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
Two or more redirects in sequence. For example, URL A redirects to URL B, which redirects to URL C. Browsers and crawlers have to follow each hop, which costs crawl budget and slows user experience. Google can tolerate short chains, but four or more hops risk dropped crawls. Every chain should collapse to a single redirect: URL A directly to URL C.
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 table that pairs every old URL with its new URL. The foundation of any SEO-safe migration. Good redirect maps are built from a full crawl of the old site plus search console and analytics data, not from guessing. Bad redirect maps cover only the top pages, which is how sites lose the 30 percent of traffic that comes from the long tail.
Rich Results
Enhanced search result formats like star ratings, FAQ accordions, breadcrumbs, and product cards. Triggered by valid structured data on the page. Losing rich results after a migration usually means the schema was not ported correctly or was ported as Microdata instead of JSON-LD. Rich results directly affect click-through rate, so losing them hurts traffic even when positions hold.
Schema Parity
A verification step where every structured data block on the old site has a matching, valid block on the new site. Product, Article, Organization, BreadcrumbList, Review, FAQPage, and so on. Parity is confirmed by running the Rich Results Test on both versions of each page type. A mismatch can trigger a manual action in Search Console or silently strip your listings of rich features.
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, Bing, and AI systems use structured data to understand entities, relationships, and facts. Proper structured data is what triggers rich results and what makes your content citable in AI Overviews. Schema.org is the shared vocabulary all major search engines support.
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.