SEO Migration Service for Ecommerce and Website Moves

An SEO migration service protects the search visibility of a website while it changes platform, domain, design or URL structure. I provide it for ecommerce and content sites that are about to move and want the old URLs, redirects, indexing signals and tracking checked before and after launch.

Discuss your projectSee selected work

I am an independent designer and developer based in Manchester, working across the UK, and you work with me directly. My background is in ecommerce builds, 3D product configurators and technical SEO, so I can read the build as well as the crawl. The scope is agreed around your actual move, whether that is a replatform, a domain change or a combination. How we agree scope and payment is set out in my terms of business.

What the service covers

The starting point is an inventory of what already matters. I combine a crawl with sitemaps, search landing-page data and known linked URLs. Priority pages are identified before the new templates or routes are finalised, not after.

From there the work covers URL mapping, redirect specification and testing, canonical and indexing checks, internal links, sitemap checks and production verification. Content and operations owners stay involved. An SEO decision about a discontinued product should agree with the catalogue decision, rather than silently redirecting it somewhere irrelevant.

Types of migration, and the risk in each

Different moves fail in different ways. The checks below are the ones I apply first.

Platform replatform

Examples are WooCommerce to Shopify, or Magento to Shopify. The new platform usually imposes its own URL patterns, so almost every product and category URL changes. The risk is a large set of old URLs with no equivalent. The check is a full old-to-new mapping built from the crawl and from landing-page data, tested against the staging site. If Shopify is the destination, see migrating to Shopify and Shopify development.

Redesign on the same domain

The domain stays, but templates, navigation and sometimes URLs change. The risk is lost internal links, removed content and changed headings or metadata on pages that already rank. The check is a before-and-after template comparison of titles, headings, canonicals, structured data and link counts. See also website redesign.

Domain change

Moving from one domain to another, including a rebrand. The risk is that signals do not transfer cleanly if redirects are partial or the old domain is dropped too early. The check is page-level redirects from every mapped URL, a verified new Search Console property, and the old domain kept live and redirecting for as long as practical. Google’s site move with URL changes guidance and the Change of Address tool apply here.

HTTP to HTTPS, and subdomain or subfolder moves

Moving a blog from a subdomain into a subfolder, or enabling HTTPS, looks simple. The risk is mixed protocols, canonicals still pointing at the old version, and hard-coded internal links. The check is a crawl of the live site for any internal link, canonical, sitemap entry or image that still uses the old form.

Merging sites

Combining two stores or a store and a separate blog. The risk is duplicate or competing pages and a redirect map that sends unlike content together. The check is a combined inventory where each overlapping topic gets one deliberate destination.

URL structure changes

Changing category paths, removing dates from articles or renaming slugs. The risk is redirect chains built up over several changes. The check is a redirect test that follows each old URL to its final destination and flags any path longer than one hop.

Ecommerce-specific risks

Shops carry more URLs than most sites, and many of them are generated rather than written. See my ecommerce SEO work for the wider approach. For Shopify moves with thousands of URLs, see Shopify redirects at scale.

• Product and variant URLs. Some platforms give each variant its own URL, others use a parameter or none at all. I decide which variant URLs need redirects and which should resolve to the parent product.
• Collection and category paths. Shopify fixes the paths at /products/ and /collections/, so a custom category hierarchy cannot be carried across unchanged. The map must say where each old category lands and how nested categories are flattened.
• Faceted navigation. Filter and sort URLs can create thousands of near-duplicates. I check which filtered pages have search demand, which should be blocked or canonicalised, and that the new platform does not expose a new set.
• Out-of-stock and discontinued products. A page for a product you will never restock should redirect to the closest relevant category or replacement, or return a 410 if nothing fits. Sending it to the homepage is not a decision.
• Image URLs. Product images often earn traffic and links. If image paths change, I check whether old image URLs need to redirect and that new images carry meaningful file names and alt text.
• Structured data. Product, offer, review and breadcrumb markup often comes from a plugin or theme. I compare the markup before and after, so price, availability and review data are not lost.
• Hreflang. Where you have regional or language versions, I check that return tags, canonicals and the redirect rules agree.
• Internal search pages. Internal search results should normally stay out of the index. I confirm the new platform does not publish them, and that old search URLs are not left in the sitemap.
• Pagination. I check that paginated category pages are crawlable, self-canonical and still link to the products that sat on later pages, so deep products are not orphaned.

A scope worksheet for your move

Use this worksheet to describe the project before asking for a proposal. It makes the boundaries and responsibilities reviewable. To compare suppliers, use my guide to choosing an SEO consultant.

How the work proceeds

1. Assess the move. Identify the changes, high-value routes and limitations of the available data.
2. Map and review. Assign an intended destination or deliberate removal decision to important old URLs. Review exceptions with the business.
3. Test the build. Check the new templates, links and search signals on staging, while keeping staging appropriately protected.
4. Verify production. Repeat the checks on the released site. A staging pass is not proof that production matches.
5. Monitor and investigate. Compare page groups and queries against the saved baseline, recording tracking or campaign changes that affect interpretation.

What I hand over

Each deliverable is a working document your team can act on. A list of crawler warnings is an input to the work, not the handover.

• URL inventory. Every indexable URL from the crawl, sitemaps and search data, with status code, canonical, template type, and traffic or link evidence where available.
• Redirect map. Old URL, new URL, redirect type and the reason for each destination. Deliberate removals are listed separately with their status code.
• Pre-launch staging report. Findings from the staging crawl: indexing directives, canonicals, internal links, structured data, templates and redirect tests. Each issue has an affected URL or template, observed and expected behaviour, an owner and a retest result.
• Launch-day verification log. A timestamped record of the checks run on production: robots and noindex status, redirect sample and full-map results, sitemap contents, canonicals, analytics firing and Search Console access.
• 2, 4 and 8-week post-launch reports. Each compares page groups and queries against the saved baseline, lists new crawl errors and coverage changes, and records tracking or campaign changes that affect interpretation. Monitoring typically runs 8 to 12 weeks, and I will say if it needs to run longer.

The website migration SEO checklist includes a launch acceptance register, so you can see this approach before commissioning a project.

Common migration failures, and how I catch them

Redirects should be permanent and one hop. Google’s redirect documentation explains the options. For a full pre-move review of an existing site, see my technical SEO audit.

When you might not need a migration specialist

Not every move needs this. If you have a small site, the URLs are not changing and the new design only affects layout, a careful developer and a basic checklist may be enough.

You do need more help when URLs change, the catalogue is large, the domain moves, or search is a meaningful source of revenue. If you are unsure, send me the details and I will tell you which side of that line you are on.

I do not guarantee rankings or indexing. Search results depend on more than the migration. The aim is to remove avoidable technical problems and make the transition measurable.

Questions about SEO migrations

How long does an SEO migration take?

It depends on the number of URLs, how much changes and how quickly decisions are made. Planning usually starts several weeks before launch. Post-launch monitoring typically runs 8 to 12 weeks.

When should SEO be involved?

As early as possible, ideally before the new site structure and templates are designed. URL structure and navigation are much cheaper to change in planning than after the build.

What access do you need?

Read access to Google Search Console and analytics for the current site, a way to crawl or export the existing URLs, and access to the staging site. For implementation, I also need to know who can edit redirects and server settings.

Can you work with my developer or agency?

Yes. I can act as the SEO check on someone else’s build, or work with your platform specialists, including WooCommerce developers.

Next step

Send me the current URL, the intended platform and your launch window through the contact page, and I will identify the dependencies and propose a defined piece of work. If the site is live and you want to understand its current state first, start with a technical SEO audit.

For a worked example of the mapping and tests, see the website migration case study. It shows how each old URL gets a clear decision, and how a test catches loops and blanket homepage redirects.