Migrating to Next.js without losing your rankings
A replatform is open-heart surgery on your organic traffic. The exact checklist our Dubai team runs so nothing flatlines — from URL inventory to the first 90 days.
By Oybek Khalikovic
A replatform is one of the highest-leverage moves a growing business can make, and also one of the easiest ways to quietly erase years of organic traffic. We rebuild marketing sites and storefronts on Next.js for clients across Dubai and the wider UAE, and the single biggest fear we hear is always the same: “will we lose our Google rankings?” The honest answer is that you only lose rankings when the migration is treated as a design refresh instead of a search-engineering project. Done with discipline, a move to Next.js usually improves visibility, because the things Google rewards — speed, crawlability, clean structure — are exactly what the framework is good at.
This is the playbook we run on every migration, written for marketing leads and founders rather than engineers. It is deliberately not a list of npm commands; it is the sequence of decisions that decides whether your traffic survives the cutover.
Why migrations lose rankings in the first place
Search engines have spent years learning your old site: which URLs exist, what each page is about, and how authority flows between them through internal and external links. A migration changes the surface those expectations were built on. Rankings drop when that learned map suddenly stops matching reality.
In practice, the damage almost always traces back to one of a small number of preventable mistakes:
- URLs that change without a redirect, so authority and indexing are lost.
- Metadata, canonicals or structured data that silently get dropped in the rebuild.
- Content that gets “tidied up” during the move, so pages no longer match the queries they used to rank for.
- For bilingual UAE sites, broken or missing hreflang between Arabic and English versions.
None of these are framework problems. They are process problems, and the rest of this article is about the process.
Step 1: Inventory before you architect
Before a single Next.js route is built, you map what you already have. Crawl the current site end to end, export Google Search Console and analytics, and rank every URL by the traffic, conversions and backlinks it carries. This inventory is the source of truth for everything that follows.
That ranking drives the information architecture. High-value URLs keep their paths wherever possible; anything that must move gets a deliberate, signed-off redirect. Treating SEO and content strategy as an input to the rebuild — rather than something you bolt on afterwards — is the difference between a confident launch and a nervous one.
Most migration disasters are not technical failures. They are forgotten URLs that nobody knew were earning traffic until it disappeared.
Step 2: Build a redirect map you can trust
Every URL that changes needs a permanent 301 redirect to its closest equivalent on the new site. The redirect map is not a spreadsheet you write once and forget; it is a tested, versioned artefact that is reviewed like code. Three rules keep it honest:
- One hop only. Redirect old URLs straight to the final destination, never through a chain of intermediate redirects.
- No lazy fallbacks. Avoid mapping everything to the homepage; each old page should point to the most relevant new page.
- Test before launch. Run the full list against a staging build so you catch loops, 404s and typos while they are still cheap to fix.
Next.js makes this maintainable, because redirects live in configuration that ships and reviews alongside the rest of the application rather than in an opaque server panel.
Step 3: Launch with metadata parity, then improve
The instinct during a rebuild is to improve everything at once: new titles, sharper descriptions, restructured copy. Resist it on launch day. The goal at cutover is parity — titles, meta descriptions, canonicals, hreflang and structured data carried across field-for-field and validated with an automated diff against the old site.
Parity gives you a clean baseline. If you change the platform and the content in the same release, you can no longer tell which change moved the numbers. The right sequence is: ship parity, confirm rankings are stable, then iterate on improvements one controlled batch at a time.
This is where Next.js earns its place. Its Metadata API turns every page’s SEO surface into code that is visible in the pull request, so a missing canonical or a dropped Open Graph tag is caught in review instead of in a traffic report three weeks later. Server rendering also means crawlers receive fully formed HTML rather than waiting on client-side JavaScript.
Performance is part of SEO now
Core Web Vitals are a ranking signal, and they are also where most legacy sites are weakest. A Next.js rebuild is the natural moment to fix them: automatic image optimisation, code-splitting and modern rendering typically move a site from amber to green on the metrics Google actually measures. Faster pages help rankings and conversions at the same time, which makes the performance work the easiest part of the project to justify.
Don’t forget the Arabic side of the site
For UAE businesses serving both Arabic and English audiences, a migration is also a chance to get internationalisation right. Each language version needs its own indexable URL and correct hreflang annotations so Google serves the right page to the right searcher. Right-to-left layout, locale-aware metadata and a clean URL structure for both languages should be designed in from the start, not retrofitted after launch.
The first 90 days after launch
Going live is the midpoint, not the finish line. The monitoring window is where you confirm the migration worked and catch anything the checklist missed:
- Submit the new XML sitemap and request indexing of priority pages.
- Watch crawl stats and the coverage report for spikes in 404s or newly excluded URLs.
- Keep the redirect map live for at least a year — search engines and old backlinks find legacy URLs long after launch.
- Track rankings for your most valuable keywords weekly, not just overall sessions.
Expect a few weeks of turbulence as Google re-crawls and re-evaluates the new structure; some movement during this period is normal and usually settles. Sustained drops beyond that window mean something on the checklist was missed — and because you started with a full inventory, you already know exactly where to look.
The takeaway
Migrating to Next.js without losing rankings is not luck, and it is not about avoiding the move. It is about treating search as a first-class requirement: inventory first, redirect everything that moves, launch at parity, then improve under measurement. Handled that way, a replatform protects the traffic you have and gives you a faster, cleaner foundation to grow it. The framework rarely costs you rankings — a careless process does.
Will I lose my Google rankings when migrating to Next.js?
Not if the migration is run as a search-engineering project. Rankings drop when URLs change without redirects or when metadata is dropped — both preventable. With a full URL inventory, a tested 301 redirect map and metadata parity at launch, a move to Next.js usually maintains and often improves rankings because of better speed and crawlability.
How long does it take for rankings to recover after a migration?
Expect a few weeks of turbulence as Google re-crawls and re-evaluates the new site; minor movement during this window is normal and usually settles within four to six weeks. Sustained drops beyond that period point to a specific issue — most often a missed redirect or dropped metadata — which your pre-launch inventory helps you locate quickly.
Do I need 301 redirects if my URLs stay the same?
If a URL keeps the exact same path, it does not need a redirect. In practice, most migrations change at least some paths — trailing slashes, casing, folder structure or pagination — so a redirect map is almost always required. Audit every URL during the inventory step and add a permanent 301 for anything that moves.
Does Next.js actually help SEO, or just performance?
Both, and they overlap. Server rendering gives crawlers fully formed HTML, the Metadata API makes every page’s SEO surface reviewable in code, and built-in image and asset optimisation improves Core Web Vitals — which is itself a ranking signal. Performance and SEO are no longer separate concerns.
How do you handle Arabic and English versions during a migration?
Each language gets its own indexable URL with correct hreflang annotations so Google serves the right version to the right searcher. We design right-to-left layout and locale-aware metadata in from the start, treating the Arabic site as a first-class version rather than a translated afterthought.