Media Canberra
Back to Work
SEO & Migration/E-commerce Client, CanberraIn Progress

6,863 URLs, One Cutover Day

A 3,200-product WordPress store is being rebuilt on a modern stack. The old site publishes 6,863 live URLs. Around 3,000 of those are near-empty pages WordPress creates on its own, one for every image ever uploaded, and they are not worth carrying into a new site. Only 670 are pages someone actually sat down and wrote. The job was telling the two apart before launch day rather than after it.

The number nobody had measured

The migration was scoped around 3,203 product URLs, because that is the size of the catalogue and it is the number everyone reaches for. We pulled the full inventory from the live sitemap and the store API instead of estimating, and the real figure was more than double that.

Two buckets accounted for ninety per cent of it. WordPress auto-generates a page for every uploaded image, and the catalogue holds 3,591 images, so roughly 3,000 of those URLs were thin attachment pages nobody wrote. Products made up another 3,204. Everything genuinely authored, the pages, categories, tags and posts, came to 670.

  • 6,863 live URLs published in the sitemap
  • 2,640 product URLs where the slug changes and a 301 is mandatory
  • 570 URLs with no destination at all in the new build
  • 1 redirect rule existing at the time of the audit, and it was unrelated

Why every product URL changed

WooCommerce builds permalinks from the product name. The new platform builds them from the SKU. Only 563 of 3,203 happened to coincide, so 2,640 product URLs were going to move.

That sounds fatal and was not, because every live product joined to a new one by SKU with zero orphans. A URL change you can map programmatically is an afternoon of work. A URL change you cannot map is a permanent loss of ranking.

The 570 with nowhere to go

This was the finding that was not in the original plan, and it mattered more than the product URLs. Seventy-two content pages had no equivalent in the new build, and they were the commercially valuable ones.

Eleven were custom-build portfolio pages, already indexed, already carrying the proof-of-craft signals a later SEO stage was going to try to create from scratch. Six were service pages with real buying intent. Fifteen were brand pages that already held URL equity for names the plan proposed building cold. Two were legal pages, and one of those exposed a compliance gap rather than an SEO one: the new build had no privacy page at all.

Not everything deserved rescuing. A handful of URLs were genuine junk left over from the site’s history, and those are better served a clean 410 than a redirect that tells search engines the content moved somewhere it did not.

What we built

The redirect layer runs in middleware rather than in the framework’s config. Config redirects execute first, which would have shadowed the per-product remap and quietly sent 2,640 URLs to the wrong place. That is the kind of detail that does not surface until traffic is already lost.

  • A 2,611-entry old-to-new product slug map, generated from the SKU join
  • Category URLs remapped to filtered shop views, with aliases for the two that did not match
  • Around 2,780 WordPress attachment pages cleared rather than left to 404
  • 60 curated page rules: static equivalents, portfolio and service pages folded into their nearest homes, junk retired
  • The privacy URL deliberately left failing, so the compliance gap could not be quietly forgotten

Two defects the audit surfaced

Auditing your own work is the point of an audit. The importer was decoding HTML entities in names and descriptions but not in the SKU before generating the slug, so 147 product URLs carried encoding garbage. Found before the redirect map was generated, that is a small fix. Found afterwards, it would have been baked into permanent 301s.

The second was in the client’s own data: a product carrying another product’s SKU, which had produced a mis-slugged page. Worth correcting at source rather than papering over in the migration.

Verification, and what is still open

We tested 120 randomly selected live product URLs against a local instance of the new build. All 120 resolved with a single 301 hop to a working product page, with zero failures. Category, page and attachment cases were confirmed by hand.

This is honest work in progress, not a finished result. The redirect layer is built and verified but sits behind a gate until the domain cuts over, and the pre-cutover ranking baseline still needs Search Console access, which cannot be captured retroactively. We will report what actually happened to traffic once it has happened.

Services Provided

SEO Site MigrationTechnical SEOURL Inventory & AuditRedirect MappingData Reconciliation

Rebuilding a site that already ranks?

The redirect map is the cheapest insurance in a rebuild, and it is the step most projects skip until the traffic drops. If you are replatforming, we can measure your real URL exposure before launch day rather than after it.

Let's Talk