SEO Migration Shopware 6: Maintain Organic Visibility When Switching to Odoo
An ERP change does not cost rankings as long as nothing changes at the visible frontend level. Odoo does not serve any public URLs in this architecture. Google continues to crawl Shopware exclusively.
One point remains tricky: SEO URLs are generated from article descriptions. As soon as Odoo takes over the authority over these descriptions and product names are cleaned up during the migration, the derived slugs change. This is exactly where losses occur, not in the ERP change itself.
This article is aimed at SEO managers who need to assess an upcoming migration and technical project managers who want to know which checkpoints should be included in the migration plan.
Correctly assessing SEO risk
In the underlying target architecture, Odoo 19 operates exclusively in the background and does not serve any public URLs. Neither URLs, metadata, canonical tags, nor XML sitemaps are altered by the ERP migration, as long as Shopware 6 remains the sole public frontend. Search engines continue to crawl only the Shopware level, which prevents duplicate content and ensures that the crawl budget remains efficiently utilized.
The SEO risk of such a migration is therefore not an automatism, but a function of what actually changes at the visible frontend level. Structured data (JSON-LD), internal links, breadcrumbs, and customer reviews are also fully generated and managed by Shopware in this architecture – they are not technically affected by the ERP migration as long as the data source for the underlying article and category information has been migrated correctly.
The underestimated pitfall: maintaining seo_url is a task, not an automatism
Here lies the truly critical point that is overlooked in many migration projects: As soon as Odoo takes over the authority for item descriptions and category structures, Shopware generates its SEO URLs from precisely this data. Any normalization, standardization, or cleanup of product names carried out during the migration – often sensible from a technical perspective and therefore particularly tricky – thereby changes the derived URL slugs.
Maintaining visibility is therefore not an automatic consequence of the architecture, but the result of a conscious migration decision: The existing entries in the SEO URL structure are treated as an independent data set to be migrated. Before the cutover, the complete inventory of canonical URLs is exported, then compared against the newly generated slugs after the import, and any discrepancies are resolved either by fixing the original URL or by a 301 redirect. Only this comparison justifies the statement that a migration can proceed without loss of visibility.
An additional technical aspect concerns the search infrastructure itself: during migrations with extensive catalogs, resource-intensive search indexes on the Shopware side (Elasticsearch or OpenSearch) are often deliberately paused during the actual bulk import and only rebuilt shortly before the final go-live. This significantly speeds up the import process but should be taken into account in the time planning: the search index must be completely rebuilt before the shop is released again, otherwise product search and filter navigation in the frontend will deliver incomplete results.
URL and Redirect Mapping
Where changes to URLs are unavoidable – for example, because article designations change as part of data cleanup – complete redirect mapping must be in place before the cutover:
- Complete URL matrix from old to new URLs
- Exclusively direct 301 redirects, no redirect chains.
- Completeness check before go-live, not after.
Redirect chains (a redirect that points to another redirect) not only slow down the user experience but also dilute the signal transmission to search engines. Therefore, each redirect should point directly to the final target URL if possible.
A practical approach for the completeness check: The complete list of existing, indexed URLs is pulled from Google Search Console and from the existing sitemap export before the migration. After the dry run, each of these URLs is automatically checked against the new system – either it delivers the same content as before, or there is a correct 301 redirect. Any URL that instead responds with a 404 must be resolved before the productive go-live.
Canonical
Canonical structures remain unchanged in a cleanly implemented migration, as they are technically managed by Shopware and are not affected by the ERP change. Nevertheless, any change to product data that indirectly affects generated URLs should be checked against existing canonical entries before going live – a blanket statement like "canonicals automatically remain correct" is not reliable without this check.
Protecting metadata and structured data
Structured data (JSON-LD), internal links, breadcrumbs, and customer reviews are also fully generated and managed by Shopware in this architecture. Title, description, canonical tags, and JSON-LD markup must not be overwritten uncontrollably by the migration – especially not when product names or category names, from which this metadata is partially automatically generated, are adjusted as part of data cleanup.
Planning SEO and ERP architecture together
The most effective protection against SEO losses is organizational, not purely technical: SEO managers and the team responsible for the ERP/Shopware architecture should coordinate the migration plan together – including a joint QA phase before the cutover, in which URL mapping, canonicals, and structured data are checked on a random basis. How this check is embedded in the larger cutover process is shown in ERP migration without downtime.
A sensible division of tasks in this joint QA phase: Before the cutover, the SEO team defines a list of business-critical URLs (top categories, highest-revenue products, important landing pages) that will be manually checked on a random basis after going live. The technical team ensures that automated redirect and canonical checks have already been run as part of the dry run before the actual switchover. This combination of automated broad checks and manual in-depth checks of business-critical pages covers most practically relevant error cases.
SEO preservation is one of several checkpoints. Our overview of the migration from PlentyONE to Odoo describes the complete migration process with all its phases.
Frequently asked questions about maintaining SEO during ERP migration
Should we expect a temporary drop in rankings during the migration?
With a cleanly planned migration that leaves Shopware as the sole, unchanged frontend, a drop in ranking is not the expected consequence. Risks arise specifically where URLs or metadata change due to data cleansing during the migration – precisely these points are identified in advance in the described reconciliation process.
How long before go-live should the URL reconciliation begin?
Ideally, this should be done in parallel with the dry run, i.e., weeks before the actual cutover – not just in the last few days before. This is the only way to ensure there is enough time to react appropriately to discrepancies between old and newly generated URLs, rather than making compromises under time pressure.
Does this risk also apply to companies that do not want to clean up product names?
The risk is significantly smaller if no cleanup takes place, but it is not automatically zero: technical migration steps such as a changed character encoding or a different treatment of special characters can also unintentionally affect URL slugs. A comparison before going live is therefore always recommended.
We have invested in our rankings for years and do not want to take this risk.
Therefore, preserving your SEO URLs is a separate migration task for us, with its own reconciliation before going live. Any URL that is no longer identical after the import will either be fixed or resolved via a 301 redirect – before the switch, not after.
Sources
The statements on permanent redirects, canonicals, and their role in processing by Google Search are based on the official documentation from Google Search Central: Redirects and Google Search and How to Specify a Canonical with rel="canonical" and Other Methods.
Request an SEO-secured system migration
Whether and where your existing SEO structure is actually at risk during an ERP migration depends on your specific product data maintenance and planned cleanup steps. The goal is to identify and limit SEO risks early on through a controlled comparison of URLs, redirects, canonicals, and metadata. This is exactly what we check as part of our free, no-obligation e-commerce audit.
✔ Free ✔ Non-binding ✔ Dedicated URL/metadata comparison ✔ Response within 24 hours
Lukas Ehrenberg
Lukas Ehrenberg is HQ GmbH’s operational spearhead when it comes to complex, high-volume e-commerce infrastructures. Across numerous projects, he is responsible for the technical implementation of extensive ERP migrations — particularly the transition from legacy systems such as PlentyONE to modular platforms such as Odoo. Combined with his deep Shopware expertise, he builds scalable enterprise infrastructures. His extensive hands-on experience makes him the primary point of contact for brands seeking risk-free, data-secure and downtime-free replatforming.
As the technical administrator of a highly available enterprise Shopware cluster with more than 14 servers, he has mastered load balancing and system stability in high-frequency environments. His particular technical expertise lies in the architectural realignment of e-commerce ecosystems: He combines in-depth knowledge of secure data extraction from restrictive systems (such as the PlentyONE REST API with strict rate-limit optimization) with high-performance, asynchronous integration into modern ERP solutions such as Odoo. This enables him to ensure seamless system transitions even at the highest transaction volumes.
