Move your website walkthrough

1. List every URL that exists today — search Google for site:yourdomain.com to see what is actually indexed.
2. Paste that list above to generate a redirect map you can fill in.
3. Export what your old platform allows. Download every image at full size regardless.
4. Build the new site completely on a temporary address. Do not switch anything until it is finished.
5. Set up a permanent redirect from every old URL to its closest equivalent.
6. Screenshot your DNS records and protect the MX and TXT entries before changing anything.
7. Point the domain at the new site early in the day, early in the week.
8. Verify everything, submit the new sitemap, and keep the old hosting alive for a month.

Do not cancel the old hosting on switch day. Give it a month. The cost of a month's hosting is nothing next to discovering something you needed was only on the old site.

When a page moves, a permanent redirect tells search engines that the old address has become the new one, and the accumulated authority of the old URL transfers. Without it, the old page returns an error and the new page is treated as brand new — with none of the history that made it rank.

This is why the inventory step comes first. You cannot redirect URLs you have forgotten, and people reliably forget the same ones: old blog posts, service pages from a previous version of the business, a landing page from a campaign three years ago. Those are frequently the pages carrying links from other sites, which is precisely what you are trying not to lose.

Where a page has no equivalent on the new site, send it to the most relevant page you do have — the service category, the nearest topic. Do not bulk-redirect everything to the homepage: search engines treat mass homepage redirects as soft errors and pass little or nothing through them.

Watch for chains too. Old → interim → new loses a little at each hop and is easy to create accidentally if you have migrated before. Always point the oldest URL directly at the final destination.

• WordPress. Everything. Content, media, and with the right plugin the database. The catch is that the export contains absolute URLs pointing at the old domain — rewrite them or half your images will keep loading from a site you are about to switch off.
• Squarespace. A WordPress-format XML file covering pages, blog posts and text. It silently omits your product catalogue, album pages and most styling. Export products separately from the commerce panel before you cancel anything.
• Wix. No site export exists. You can download your media library and copy text by hand, and that is the entire toolkit. If the domain was bought through Wix, transferring it out has lock periods and needs an authorisation code from support — start that first.
• GoDaddy Website Builder. No export. Copy text by hand, download images individually. The bigger risk is that your domain, email and site are probably all on one account — move them one at a time and confirm email works after each change.
• A Facebook page only. Nothing to migrate, and no rankings to lose, which makes this the easiest move on the list. Download your photos from Facebook's data tools. Keep the page and add the site alongside it rather than replacing it.

Whatever the platform: download every image at full resolution before you cancel anything. Re-shooting photographs is by far the most expensive part of a migration nobody planned for.

Your website and your email are both routed by DNS records living in the same table. Change where the website points without care and the mail records can be lost — and nothing tells you. There is no bounce you see, no error, no notification. You find out days later when someone mentions you never replied to their enquiry.

Before changing anything, screenshot the entire DNS record table. Specifically preserve every record of type MX, every TXT record containing SPF or DKIM information, and any CNAME used by your mail provider.

If you are switching nameservers rather than editing individual records, this becomes critical: nameserver changes invalidate every existing record at once. Recreate the mail records at the new provider before you switch, not after.

Then test. Send yourself an email at your domain address after the switch, from an outside account. It takes thirty seconds and it is the only way to know.

The instinct is to point the domain at the new site early and finish building it live. It feels efficient and it guarantees a period where both customers and search engines see something unfinished.

Customers forgive that quickly. Search engines do not: a crawl that finds broken pages, missing content and errors during your migration window shapes how the new site is assessed for weeks afterwards.

So build completely on a temporary address — a staging URL or your new host's subdomain — and switch only when you would be happy for a customer to see the site exactly as it is. There is no partial-credit version of this step.

Then switch early in the day and early in the week. Not Friday afternoon. If something needs fixing you want to be awake, at a desk, and able to reach support.

Immediately after switching, walk the list: every redirect resolves in one hop, every form submits and the email arrives, every image loads, both www and the bare domain work over HTTPS, and your analytics is recording again. That last one catches a surprisingly large number of migrations that look catastrophic for two days purely because nobody re-added the tracking code.

Then submit the new sitemap in Google Search Console and watch the coverage report weekly for a month. A temporary dip in impressions after a migration is normal and recovers. A dip still present after six weeks is a redirect you missed, and the coverage report will tell you which URLs are returning errors.

Keep the old hosting paid for at least a month. The cost is trivial and the alternative is discovering that something you needed existed only there.

One honest caveat: a well-executed migration usually recovers within weeks, and Google is under no obligation to put you back exactly where you were. A site that was ranking on borrowed time will not be rescued by a clean move, and no amount of redirect discipline guarantees the previous position.