Skip to content

Next.js redesign: preserving your SEO and URLs

By the AXELITES team

Laptop displaying dashboards and application interfaces

A move to Next.js changes how the site is built; it does not require changing every public address. The first SEO objective is to preserve access to useful content and make necessary changes explicit.

Prepare a URL inventory, intended destinations and verification criteria. Next.js provides metadata, rendering and redirect mechanisms, but these still require content decisions and checks against the delivered website.

1. Inventory URLs before designing the new site

Collect pages from sitemaps, internal links and measurement tools. Identify URLs bringing visits or enquiries, useful downloads and multilingual content. Retain their titles, descriptions, H1 headings, canonicals and indexing directives.

Classify each URL as retained, moved to an equivalent or removed without replacement. This mapping connects editorial decisions to routing. It also reveals pages omitted from designs even though they still serve a useful purpose.

2. Preserve useful addresses and map changes

If content and intent stay the same, retaining its URL reduces the changes to manage. When an address changes, define a server-side permanent redirect, commonly 301 or 308 depending on the mechanism. Next.js supports configuration redirects and permanentRedirect, among other options.

Fictional example: /offers/business-application becomes /services/business-application. The old URL should lead directly to the equivalent content without a redirect chain. Where no relevant equivalent exists, handle removal with an appropriate status rather than sending everything to the homepage.

3. Check rendered content and metadata

Verify that public pages expose their main content and links without requiring an interaction. Choose rendering and caching according to how often information changes. A page that stays empty while waiting for a browser request needs different analysis from content prepared on the server.

The Next.js Metadata API supports titles, descriptions, canonical URLs and language alternatives. Inspect final values for every template and its variants: categories, pagination, filtered results and missing pages. Each translation should retain a canonical consistent with its own URL.

4. Check indexing and SEO files

The production sitemap should contain the intended canonical URLs. Robots rules and noindex directives must follow the indexing policy. Protect working environments and ensure restrictions used during testing are not left on the public website.

Update internal links and language associations when addresses change. Review social images and structured data too. A URL returning 200 with an error message is not a proper missing page: test the actual response status.

  • Priority pages accessible and indexable according to the agreed scope.
  • Old addresses redirecting directly to the right destinations.
  • Canonicals, languages and sitemap entries consistent with final URLs.

5. Prepare acceptance testing and launch

Test the main templates on mobile and desktop using actual content. Compare metadata and text against the original inventory, verify forms and measure performance under documented conditions. Include downloads and useful external links.

Name the people who approve redirects, content and commercial journeys. Prepare domain configuration, cache behaviour and rollback criteria. A deployment can succeed technically while leaving an important form or resource inaccessible.

6. Monitor signals after the redesign

After launch, check representative URLs, submit the sitemap in Search Console and monitor errors, indexing and redirects. Compare the same pages and conversion outcomes over relevant periods.

A migration can produce fluctuations while pages are recrawled. Analyse changes by page and query before drawing conclusions. Retain the URL mapping and necessary redirects: deployment completion does not mean external links have been updated.

Frequently asked questions

Must URLs change when moving to Next.js?
No. The framework does not require a new public URL structure. Keep useful addresses and document changes justified by the project.
Does Next.js guarantee better rankings?
No. Content, links, indexing and user experience remain important. Framework features must be configured correctly and verified.
How should an old page with no equivalent be handled?
First review its usefulness and incoming links. If removal is confirmed and there is no relevant destination, return a genuine 404 or 410 according to your strategy rather than an unrelated redirect.

Sources and documentation

Plan your Next.js redesign

Share your website and the journeys to preserve so we can scope content, URLs and acceptance testing.

Discuss my redesign

More resources

View all