Building the SEO architecture for a complex multi-market Shopware migration.

Case Study · Technical SEO · International SEO · Migration Architecture

Large website migrations rarely fail because of a single technical issue.

They fail when hundreds of interconnected decisions around URLs, redirects, internationalization, templates, indexation and internal linking stop working as one system.

This project involved two interconnected e-commerce migration environments:

• a German shop moving to a new Shopware 6 architecture
• an international .com environment serving multiple markets and locales

The challenge was not simply to move URLs from one system to another.

It was to establish an SEO architecture capable of preserving valuable signals while avoiding the technical debt accumulated in the legacy environments.

---

Project Scope

CLIENT TYPE
International E-Commerce

PLATFORM
Shopware 6

ROLE
Senior SEO Consultant

SCOPE
Technical SEO · International SEO · Migration Strategy · QA

SCALE
~33,000 redirects · Multiple markets and locales · DE + international commerce environments

CONTEXT
Agency consulting engagement

---

The Challenge

The existing environment had grown over several years.

Its technical footprint included legacy redirects, inconsistent URL behavior, international routing dependencies and historical indexation issues.

At the same time, the target architecture was still evolving during migration preparation.

This created two different requirements.

Existing search signals had to be preserved.

But existing technical debt should not simply be transferred into the new system.

The migration therefore required an architectural approach rather than a conventional URL mapping exercise.

A migration should preserve valuable signals, not reproduce technical debt.

---

From Legacy System to Target Architecture

The first step was understanding the existing environment.

Crawl data, existing URLs, redirects, Search Console data and Shopware exports were used to reconstruct the relevant search footprint.

The analysis covered relationships between:

• URLs
• redirects
• indexability
• canonicals
• internal links
• international variants
• hreflang
• templates
• parameters

These findings were translated into requirements for the target architecture.

The objective was not to recreate the old system.

It was to determine which relationships needed to survive the migration.

---

International Search Architecture

International e-commerce adds another layer of complexity.

URLs cannot be considered independently from markets, languages and domains.

The target model therefore treated internationalization as a connected system:

Domain → Locale → URL → Canonical → hreflang → Sitemap → Internal Links

Language-country structures allowed individual markets to be represented explicitly while maintaining a coherent international architecture.

This was particularly important because routing decisions could affect much more than the visible URL.

A change at locale level could influence canonicalization, hreflang relationships, internal linking and ultimately indexation.

International SEO therefore became part of the architecture rather than an annotation added after development.

---

Building the Redirect Model

Redirect migration represented one of the largest operational components of the project.

The historical URL footprint could not be reconstructed from a sitemap alone.

Multiple data sources were combined:

Live Crawl

↓

Existing URLs & Redirects

↓

Shopware Exports

↓

Google Search Console

↓

Target URLs

↓

Mapping & Classification

↓

Deduplication

↓

Redirect QA

The consolidated migration set contained approximately 33,000 redirects.

The underlying principle was straightforward:

Old URL → one permanent redirect → correct new entity

But achieving that consistently across tens of thousands of URLs, changing target structures and multiple international environments required considerably more than producing a spreadsheet.

---

Migration Architecture Under Moving Conditions

Real migrations rarely follow the textbook sequence:

Final Architecture → Final URLs → Mapping → QA → Launch

In this project, development and SEO preparation progressed simultaneously.

Target URLs changed.

Architectural decisions evolved.

New findings appeared during QA.

The migration model therefore had to remain adaptable without losing control.

Instead of treating an earlier redirect mapping as unquestionable truth, mappings were continuously evaluated against the actual target architecture.

The relevant question was not simply:

Does the URL match the spreadsheet?

It was:

Does the migration preserve the correct relationship between the old and new entity?

That distinction became central to the QA process.

---

Building a Migration QA System

QA was designed as a sequence rather than a launch-day event.

Architecture Review

↓

Pre-Go-Live QA

↓

Go-Live Validation

↓

Post-Launch QA

↓

Stabilization

Checks covered the technical relationships most likely to affect migration performance, including:

• redirect behavior
• status codes
• indexability
• canonicalization
• international routing
• hreflang
• internal linking
• templates
• parameters
• XML sitemaps

Issues were prioritized according to migration risk rather than treated as an undifferentiated technical backlog.

This created an important distinction between:

what could endanger the migration

and

what could safely be improved during stabilization.

---

Monitoring as a Diagnostic System

The migration did not end at launch.

Search performance and technical signals were monitored across multiple sources to distinguish actual organic problems from temporary tool fluctuations or expected migration effects.

This changed the purpose of monitoring.

It was not simply reporting.

It became part of the QA architecture:

Detect → Compare → Diagnose → Prioritize → Escalate → Validate

That feedback loop allowed technical anomalies to be identified and assessed within the context of the broader migration rather than interpreted from isolated metrics.

---

What This Case Demonstrates

Technical SEO at Scale

Managing redirects, indexation, canonicalization, crawling and migration QA across tens of thousands of URLs.

International Search Architecture

Treating domains, locales, URLs, hreflang and internal routing as an interconnected architecture.

Migration Governance

Creating reliable decision and QA systems while the underlying technical environment continues to evolve.

Cross-Functional Consulting

Working between business stakeholders, SEO, agency teams and development to translate technical complexity into priorities and decisions.

---

Strategic Implication

Large migrations are often described as technical implementation projects.

From a search perspective, they are better understood as signal-preservation systems.

URLs change.

Platforms change.

Templates change.

Information architecture may change.

But search systems still need to understand the relationship between what existed before and what exists afterwards.

The job of migration SEO is therefore not simply to redirect old URLs.

It is to preserve meaning and relevance while the technical system underneath them changes.

---

Closing Thesis

Complex migrations cannot eliminate uncertainty.

They can make uncertainty manageable.

That requires architecture before implementation, prioritization before perfection and validation long after the redirect matrix has been created.

At scale, successful migration SEO is therefore not a checklist.

It is a system of architecture, risk management and continuous validation.

---