Technical SEO after an e-commerce replatform

The move is done, the new shop is open, and this is where the most demanding part begins. The first weeks after the switch are the window in which a mistake is still cheap to find. After that it has time to show up in the rankings the site spent years building.

This piece picks up where our article on migrating an online store leaves off. The site is already live, traffic is already arriving, and every mistake costs money daily.

What you compare against after the switch

The baseline of the old store is captured before the switch, and how to do that is covered in the first part of our guide to e-commerce replatforming. What matters here is different. You need to turn what you captured into a working tool for daily checks.

Bring every address into one table with columns for the old URL, the new URL, the page type, organic sessions before the move and the check result. From then on the check runs row by row rather than “across the site”, and no group gets lost.

• Label the types. Categories, products, brands, articles, filters and utility pages. That way a check shows whether a whole group slipped rather than a single page.
• Sort by traffic. The check starts with the pages that were bringing people in, not at a random point in the list.
• Read it by group, not in aggregate. A whole product category falling away disappears easily behind steady brand traffic to the home page.
• Record the date of the last check. Three weeks in, nobody remembers which rows have been covered.
• Keep the navigation structure. How a page is reached matters as much as whether it is reachable. A category with no link from the menu stays accessible yet loses its context.

The sources for that table overlap deliberately: the sitemap, your own crawl, analytics, search console reports, the catalog database and a list of inbound links. A sitemap omits pages that were excluded by accident, and a crawl cannot see orphan URLs with no internal links. Together they give a fuller picture than any of them alone.

The redirect map and chains

Different systems build addresses differently: one uses numeric identifiers, another appends suffixes, a third puts the category directly after the domain. If an old address simply returns a 404, the signals that page accumulated have nowhere to go. A permanent redirect removes that problem, and the redirect itself loses no ranking weight, as the search engine states plainly.

• Every old address points at its exact equivalent. Category to category, product to product, article to article.
• No chains. A direct redirect answers faster, holds up better and maps addresses exactly. A long chain adds latency, spends crawl budget on intermediate steps and risks breaking in the middle.
• No blanket redirect to the home page. A redirect to an irrelevant page may be treated as a soft 404.
• Rules at the web server level. Server configuration handles redirects faster than the CMS does.

If you came off a closed hosted platform, its export has quirks of its own, covered in our article on how to move from a platform to your own website.

Metadata, headings and catalog structure

More than names and prices has to move. Losing metadata forces the algorithm to reassess the relevance of every page from scratch, and rankings dip even with perfect redirects.

Internal links after launch

Menus, related product blocks, banners and links inside articles often keep pointing at old addresses. Technically it works, because the redirect fires. In practice it is three problems at once.

• Extra load. Every visitor click travels through an additional step.
• Slower pages on a phone. Each unnecessary request is more noticeable there than on a desktop.
• Extra steps for the crawler. It processes intermediate addresses instead of new catalog pages, and on a large catalog that eats into the crawl budget.

Every internal link after release should point straight at an address that returns 200.

Verifying inbound links after launch

The link profile is exported before the switch, as part of preparing the move. After launch a different job remains: making sure each of those links actually delivers a visitor to a page.

• Go through the list of linking pages by hand. Click each link, since a status code alone is not enough. A redirect can be technically correct and still land on an empty category.
• Read the final code, not the first. A link can return a 301 that leads to another 301 that leads to a 404. In a report, that looks like a working link.
• Cross-check the logs. If people still arrive on a strongly linked address and hit an error, the log shows it the same day.

Language versions and hreflang

If the shop runs in several languages, changing the prefix structure breaks the link between page versions, and the wrong language starts appearing in regional results.

• A full set of tags on every page. Including a reference to itself, otherwise the cluster is incomplete.
• A default version, if you need one. The x-default tag signals to the search engine which page to show when a user’s language and region match none of your language versions.
• Absolute final addresses. Use full URLs that return 200 and make the references reciprocal. If two pages do not point to each other, Google ignores the tags.

Sitemap and robots.txt

After publication, search engines need current lists of addresses, otherwise they may take longer to find the new pages.

• A temporary map of old addresses. A file of the old addresses that now return 301 helps the search engine find those redirects sooner.
• The main map of new addresses. Canonical only, returning 200 only, with no redirects inside.
• A clean robots.txt. Every staging restriction is stripped from the new server, and only utility sections stay closed: the admin area, the cart, the checkout and internal search.
• Styles and scripts open. Block them and the crawler cannot judge how the page actually looks.

The routine for ongoing checks after launch is covered separately in our article on what website support includes.

Canonical URLs

A new system may treat a trailing slash, letter case and sort parameters differently. Without consistent rules, duplicates appear in the catalog within a week.

• One protocol. A forced redirect to HTTPS.
• One primary host. With www or without, but consistently across the whole site.
• One trailing slash convention. The alternative form returns a redirect rather than a second copy of the page.
• Lower case in addresses. Otherwise the same page exists in two spellings.

Discontinued products

What to do with product pages that no longer exist comes up in every move. The answer depends on whether the page brings traffic.

• There is a current equivalent. A redirect to the successor page, and the buyer lands where they intended.
• The product is gone but the traffic is not. The page stays live, clearly marked as unavailable, with links to similar products in stock.
• The product is gone for good. The server returns a 404 or a 410. Google treats both codes the same way and drops the URL from its index.

Structured data

If the old platform had product markup, the new one has to reproduce it in full. A syntax error costs you the rich result. The rating stars, the price and the availability disappear, and some of your clicks go with them.

What to check after a move is not whether the code is present but what the crawler sees. Run one sample of each page type through the official validator: a product, a category, an article. The two classic migration breakages are empty fields that the old engine filled from a template, and the staging domain left behind inside image URLs.

Verify the price and the availability in the markup against what the page itself shows. A search engine treats a mismatch between them as an error and drops the rich result entirely.

The full set of fields for a product page is covered in our article on product page blocks that sell.

Speed after the move

In the first days, do not launch a large advertising campaign, a full reindex and a heavy import at the same time. Background jobs need priorities. A purchase and a page response matter more than generating every thumbnail quickly.

A new platform can have a different architecture and a different response profile. If the new site is slower than the old one, rankings drift down even with a perfect redirect map.

Three things get watched: server response time, how quickly the main content appears and how stable the layout is while loading. Which improvements actually pay off is covered in our article on what actually speeds up a website.

Server logs and console errors

For the first four to six weeks the server logs show crawler behavior in real time, long before the data appears in the search console.

• Requests returning 404. Sort them by source and by what was at each address before. An old page that used to bring traffic means the redirect map is incomplete. A product that is gone for good is correctly answered with a 404 or a 410.
• Server errors on particular sections. A catalog can fall over under load precisely where nobody tested it.
• How often old addresses are requested. This shows how quickly the search engine is consolidating the old URLs into the new ones.
• Crawl depth on new product pages. If the crawler never reaches products, the cause is usually link structure rather than a budget limit.

What counts as normal during the transition

An owner should know in advance what a normal search engine reaction looks like, so decisions are not made in a panic.

A search engine usually picks up the main pages and categories within a few days, but crawling the whole catalog, updating its index and processing all the redirects is a much slower process. How long that takes depends on the number of URLs and the speed of the site. Google’s own guidance for a medium-sized site is a few weeks or more, longer for large sites, and swings across that period are expected. A sharp drop in organic sessions, though, is a reason to start investigating the same day rather than waiting for things to settle. There is no threshold announced in advance below which you can relax. Judge the size of the drop against your own normal level.

If the redirects are right, the metadata survived and speed did not drop, traffic usually comes back to its former level. Sometimes it grows afterwards, because the structure of the new catalog turns out to be more logical than the old one. There is no guaranteed timeframe, and Google gives only an estimate.

When to step down from daily checks

The intensive mode ends on evidence, not on the calendar.

• Response codes are stable. No new spikes of errors across a full week.
• New addresses are being crawled. The crawler reaches product pages, not only categories.
• The main groups are indexed. Categories, products and articles are in the index along with the home page.
• Conversions work. E-commerce events arrive end to end, from view to payment.
• Old addresses produce no new errors. Requests for them taper off naturally.

After that, checks move to a regular schedule. The redirect map stays part of the release checklist, canonicals and the sitemap are verified after updates, and new page types go through the same acceptance procedure.

A closing document records the deviations from the original plan, the rules now in force and the open items. It spares the next team from repeating the research and explains why a particular old address is still kept years later.

The acceptance checklist

Run it on switchover day and repeat it a week later.

• The home page returns 200. Along with top-level categories and a few product pages picked at random.
• Ten old addresses return 301. Taken from different types: a category, a product, a filter, an article.
• No chains anywhere. The jump from an old address happens in one step.
• No indexing block. Not in the meta tag, not in robots.txt, not in the response header.
• The sitemap was accepted. With no errors and only canonical addresses inside.
• Titles match. The pages you sampled carry the titles they used to.
• Markup validates. Product, price and availability parse without syntax errors.
• Analytics events fire. From product view to payment, on a test order.
• No internal redirects. Menus and copy link directly.
• The old site is still alive. And can be switched on if something goes wrong.

What it costs

The post-move check is a one-off piece of work that ends in a plan: what exactly broke and in what order to fix it. It runs as the starting audit, from $200.

Monitoring rankings over the following months is monthly work, and for an online store it is priced on its own tier, from $600/mo. A store with several language versions is on a higher tier, from $900/mo. We take on monthly work for at least three months.

If we take the project on monthly straight after the audit, the audit is included in that cost.

Conclusions

After a move, technical SEO means daily checks until the numbers settle. In our experience, that is most often the first four to six weeks. A search engine does not know the new site is the same shop until the redirects, the metadata and the structure prove it consistently.

The most expensive mistakes include an indexing block left over from staging, redirect chains, titles regenerated from templates, and internal links still pointing at old addresses. None of them is visible at a glance, and each one costs you rankings.

If you have just moved and cannot work out why traffic dropped, send us the shop address and the date of the switch. We will read the server logs, the redirect map and the console reports and name the specific causes, ordered by what to fix first. If the move is still ahead of you, it is cheaper to bring us in before launch, since building the baseline and the address map in advance costs less than recovering rankings afterwards. Either way we take it on as part of search engine optimization.