Most corporate sites are not first sites. Yours already ranks for something, already collects links from places
you have forgotten about, and already has pages a customer has bookmarked. A relaunch that ignores that can undo
years of accumulated traffic in an afternoon, so the migration is designed as part of the build rather than
improvised on launch day.
01 An inventory before anything is designed
We list every URL the current site publishes, taken from its sitemap, its internal links, its server or CDN
logs, and its Search Console history where you have it. Every URL then gets a decision: kept at the same
address, moved, merged into a stronger page, rewritten, or deliberately retired.
The pages that already earn attention are protected first. If a thin, unloved page is quietly the reason half
your enquiries arrive, that shows up in the inventory rather than after it has been deleted.
02 Content moved with its meaning intact
Copy, images, documents and downloads come across page by page. Where the volume justifies it we script the
import, and then still read the result: an automated migration that mangles a table, loses a heading level or
drops alternative text costs more to repair than it saved. Where the words still work we keep them, because a
relaunch is not a licence to rewrite everything for its own sake.
The work is platform independent. Whether the current site runs on WordPress, a hosted site builder, a
bespoke content system nobody maintains any more, or hand-written HTML from a decade ago, the content is
treated as content and rebuilt into the new structure on its own terms.
03 A redirect map, written down and testable
Every address that changes gets a permanent redirect to its closest equivalent page. Never a blanket redirect
to the home page, which search engines read as a soft deletion of everything you had. Merged pages point at
the page that absorbed them, and a retired page points at the nearest parent that is genuinely useful to the
person who followed the old link.
The map is a reviewable file in the repository, so you can read it before the switch instead of trusting that
it exists. After cutover we request every old URL and confirm both its status code and its destination, and
the redirects stay in place permanently rather than for a season.
04 What carries over, and what we drop on purpose
Carried over: the domain, the content that still works, imagery you own, your brand system, the address your
form mail goes to, the analytics or advertising accounts you actually use, and every URL we can keep without
bending the new structure around it.
Dropped on purpose: duplicate pages competing with each other for the same search, pages nobody has opened in
a year, embeds and tracking scripts whose reports you no longer read, and plugins whose only job was patching
the old platform. Every removal is a line on the inventory with a reason beside it, so nothing disappears by
accident and you can veto any of it.
05 The cutover, and the weeks after it
The new site is live on a preview address long before the switch, so nothing is seen for the first time on
launch day. At cutover we move the DNS, leave the old host reachable until the change has propagated
everywhere, verify the redirect map, confirm form mail is arriving, submit the new sitemap, and ping the
instant-indexing endpoints so engines re-crawl within days instead of whenever they next visit.
Then we watch. Search results move for a few weeks after any relaunch while engines re-crawl and re-evaluate
the site: some queries settle higher, some dip before they recover. We track the fundamentals with you,
meaning indexed pages, redirect health, Core Web Vitals and the queries that actually matter to the business,
and we tell you what we see, including when the honest answer is that nothing needs doing.
What we will not do is promise a number. A careful migration protects what you have already earned and gives
better content a fair chance to compete. Anyone who guarantees the outcome of a relaunch is guessing with
your traffic.