Crawl before design
The pages that earn the traffic are rarely the pages a redesign brief mentions. Sorting URLs by impressions and links first changes what gets built.
Services / Website migration
Move the site. Keep the rankings it already earned.
Most of the risk in a replatform sits in URLs, canonicals, and structured data rather than in the design. This engagement handles all three before launch, not after. 5 live client sites across the UK and UAE.
What the engagement covers
A focused scope with visible decisions.
The work is organized around outcomes and operating constraints, not a long list of disconnected features.
01
Full crawl of the existing site, joined against Search Console impressions and inbound links
02
A written redirect map: one row per indexed URL, with destination, status code, and resolved canonical
03
Next.js build with canonicals, titles, and structured data committed alongside each template
04
Staging dry-run that asserts every redirect row before go-live, plus staging noindex verification
05
Sitemap, robots, and Search Console property configured for the new host on launch day
06
Coverage and ranking checks at 48 hours, two weeks, and six weeks after launch
Quality criteria
What gets decided before the details multiply.
No blanket redirects
Sweeping every retired URL to the homepage is the fastest way to lose its value. Each row gets a real destination or a documented reason for retiring.
Metadata is not a follow-up sprint
Canonicals and structured data ship in the same commit as the template. Deferring them creates a live, unlabelled window, which is exactly when rankings move.
Delivery path
5 checkpoints from context to release.
- 01
Crawl and inventory
Full crawl of the existing site, joined against Search Console and analytics. Every URL is sorted by impressions, inbound links, and conversions, so the pages carrying the business are known before anyone opens a design file.
- 02
Write the redirect map
One row per old URL: destination, status code, resolved canonical. Pages that merge get a decision and a reason. Pages that retire get checked for inbound links first. The map is reviewed and signed off before template work begins.
- 03
Build with metadata attached
Templates ship with their canonicals, titles, and structured data in the same commit. There is never a window where the new site is live and unlabelled, because that window is when the damage happens.
- 04
Stage and dry-run
The redirect map runs against staging and every row is asserted. Robots and canonicals on staging are checked so the staging host cannot be indexed and cannot leak into production canonical tags.
- 05
Launch and recheck
Go live, submit the new sitemap, and verify coverage at 48 hours, two weeks, and six weeks. Recrawl noise in the first fortnight is expected; anything still wrong at six weeks is treated as a defect in the migration.
Where migrations go wrong
Five failures that account for most lost traffic.
None of these are exotic. They are the ones that turn up again and again on sites that lost traffic on launch day, and every one of them is checkable before you go live.
- 01
Redirect chains
The old URL redirects to an interim URL which redirects again. Each hop costs crawl budget and some link value, and long chains get abandoned by crawlers entirely.
- 02
Canonicals pointing at staging
The most common cause of a site vanishing after launch. The staging host stays in the canonical tag, so every page tells Google the real version lives somewhere it cannot reach.
- 03
Faceted URLs left uncontrolled
Filter and sort parameters generate near-duplicate pages by the thousand. Without canonical or robots rules they eat the crawl budget that should be reaching real product pages.
- 04
Structured data left behind
Product, breadcrumb, and FAQ markup lived in the old templates and never got ported, so rich results disappear from the results page even where rankings hold.
- 05
Sitemap still describing the old site
A sitemap full of URLs that now 301 or 404 slows recrawl and buries the new URLs, delaying recovery by weeks for no reason.
Questions
Useful answers before the first call.
Why do redesigns lose search traffic?
Almost always because of URLs, not design. The new CMS generates different paths, the old ones return 404 or get swept into a single redirect to the homepage, and the pages that earned the links stop resolving. Add canonicals still pointing at the staging host and structured data that never made it out of the old templates, and a site can shed most of its non-brand traffic in the first fortnight.
What does the redirect map actually contain?
One row per indexed URL on the old site: the old path, the new destination, the status code, and the canonical the destination should resolve to. No chains, no blanket rule to the homepage, and no page with inbound links quietly retired. On a mid-size B2B catalogue that is usually several hundred rows, and it is written before any template work starts.
How long does a migration take?
Four to eight weeks for a typical B2B or e-commerce site, depending on catalogue size and how much content needs restructuring rather than moving. The crawl and redirect map take the first week and are worth doing properly, because every later decision depends on them.
Can you migrate without changing the design?
Yes, and sometimes that is the right call. Replatforming and redesigning at the same time makes it hard to tell which change caused a traffic movement. Moving the stack first on the existing design, then redesigning once the new platform is stable, is slower but far easier to diagnose.
What happens if traffic drops after launch?
There is a check at 48 hours, two weeks, and six weeks: coverage in Search Console, redirect resolution across the whole map, and rankings for the terms that mattered before. A dip in the first fortnight during recrawl is normal. A drop still there at six weeks is a fault, and diagnosing it is part of the engagement rather than a new quote.
Do you work with WordPress, Shopify, or a custom legacy stack?
All three. The source platform matters less than whether its URLs and content export cleanly. Legacy PHP and ASP sites with query-string URLs take more mapping work than a modern CMS, and that shows up in the estimate after the crawl rather than as a surprise later.
Bring the current situation