Move the site. Keep the rankings.

Call us before the platform decision, not after the launch date

Almost every migration we're asked to rescue arrives the same way. The site went live on a Thursday. By the following Wednesday organic traffic is down 60% and everyone is very calm on the call in a way that suggests nobody is calm.

By then the options are narrow. The old site is gone, the old URL list exists only in Search Console and archive tools, and the redesign changed the content as well as the addresses — so nobody can separate what the redirects broke from what the copywriter removed.

The version that works starts six to eight weeks before launch, ideally before the platform is signed. Some choices are genuinely hard to undo: a headless build with client-side-only rendering, a CMS that can't hold arbitrary redirect rules, a URL structure the platform imposes on you. Those get decided in a procurement meeting nobody invites an SEO to.

The pre-launch freeze checklist, and who signs it

We produce one document. It lists every check that has to pass before the new site is allowed to go live, and it has three signature lines: us, your developer or dev shop, and you.

The signature isn't ceremony. It's the thing that stops the conversation where a launch date slips towards a Friday evening and somebody decides the redirect QA can happen next week. If the checklist isn't signed, we say so in writing and the decision to launch anyway becomes an explicit one rather than an accidental one.

1. The old URL list is complete. Pulled from Search Console, analytics, the live sitemap, a full crawl, and 30 days of server logs. Logs matter — they surface URLs Google still crawls that no internal link points to any more.
2. Every URL is mapped. One row, one destination, or an explicit decision to let it 404 or 410. Nothing is unassigned.
3. Staging directives are removed. The noindex tag and the blanket robots.txt disallow that protected staging must not travel with the build. This is the single most expensive line on the checklist.
4. Templates preserve on-page signals. Titles, H1s, body copy, structured data, canonicals and internal links carry over or change deliberately, with the change documented.
5. Analytics and Search Console are ready. New property verified, sitemaps prepared, GA4 and tag manager tested against the new templates, annotations set for launch day.
6. A rollback plan exists. Who reverts, how long it takes, and at what threshold we call it. Agreeing that at 2am on launch night is not agreeing it.

Redirect mapping when the URL list runs to 40,000 rows

Mapping the top 200 pages by traffic is straightforward and is not the job. The long tail is where the equity sits, and it's where the tedium lives.

We map at scale using pattern rules where the structure is consistent, then hand-map the exceptions — and there are always exceptions. A one-to-one match is always preferred over a redirect to a category page, and a redirect to a category page is always preferred over dumping everything on the homepage. Google treats a mass redirect to an irrelevant page as a soft 404, so that shortcut throws away exactly what you're trying to keep.

• Parameter URLs. Faceted filters, sort orders, session IDs, tracking parameters. Some get redirected, some get canonicalised, some should have been blocked years ago.
• Paginated series. Page 2 through page 40 of a listing hold internal link equity and often rank. They need destinations, not a bulk redirect to page 1.
• Media and documents. PDFs, spec sheets, images with inbound links. Routinely forgotten and routinely the source of a lost backlink.
• Legacy redirects. Chaining new rules onto the last migration's rules creates three-hop routes that leak. We flatten every chain to a single hop.
• Uppercase, trailing slashes and www. Duplicate variants that were quietly resolving before and stop resolving after.
• hreflang clusters, if you run them. Every alternate reference has to be rewritten in the same release or the whole cluster breaks.

Launch day and the week after

Launch day is verification, not celebration. We crawl the complete old URL list against the live site within the first hours and check the actual status codes, because a redirect rule that works in staging and a redirect rule that works behind a CDN are two different claims.

Then we watch the server logs, because they tell us what Googlebot is really doing while Search Console is still catching up. Week one is when problems are still cheap: a redirect loop found on day two costs an hour, and the same loop found in week five has been crawled a few thousand times.

1. Hours 0–6. Full crawl of the old URL list, status code audit, robots.txt and noindex check on production, sitemap submission, canonical spot-checks across every template.
2. Days 1–7. Daily log review, 404 monitoring, Search Console coverage and crawl stats, rankings tracked daily instead of weekly, redirect chains flattened as they surface.
3. Weeks 2–8. Weekly review as Google reprocesses the site. Internal link repair, sitemap cleanup, index bloat cleared, and the honest read on what moved and why.

What's included, and what isn't

This is a defined project with a defined edge. Here it is.

Fixed fee, and the 60-day window

Migrations are priced as a fixed project, not hourly. Hourly billing on a migration rewards the agency for a launch that goes badly, which is a strange thing to design into a contract.

• From ₹75,000 for sites under roughly 500 indexed URLs on a mainstream CMS. Ex-GST.
• ₹1,50,000 for roughly 500 to 5,000 URLs, or any move that changes domain as well as platform.
• Above 5,000 URLs, or multi-domain and multi-language moves, we quote after a scoping call rather than publish a number we'd have to renegotiate. Faceted ecommerce and hreflang clusters are genuinely different work.
• The 60-day cover window starts at launch and is included in all three. It's 60 rather than 30 because Google typically takes four to eight weeks to reprocess a mid-size site — a 30-day window would close just before the honest read arrives.
• If you're already on an SEO retainer with us, migration cover is folded into the retainer rather than billed separately.

What we guarantee on a migration — and the caveat we say out loud

Before launch we freeze a baseline: organic sessions, organic qualified leads, indexed page count, and ranking positions for your tracked keyword set, all averaged over the 90 days before the move.

We commit to parity against that baseline within 60 days of launch. If we're short, we keep working free until we get there. As always, we never promise a specific ranking position — nobody controls Google's index, and an agency promising position one during a replatform is guessing loudly.

Now the caveat, because it decides whether the guarantee means anything. Parity is only measurable if the migration is a migration. If the same release also removes 200 pages and rewrites the copy on every service page, we're no longer measuring a technical move — we're measuring a content decision wearing a migration's clothes.

When that happens we say so before launch, document which changes carry ranking risk, and scope the guarantee to the URLs whose content genuinely carries over. It's a narrower promise, and it's the only version that's true. You can check the arithmetic against your own baseline at any point.