SEO Migration Shopware 6: Maintaining Organic Visibility When Switching to Odoo
Switching ERP systems doesn't negatively impact rankings as long as the visible frontend remains unchanged. Odoo doesn't serve any public URLs in this architecture. Google continues to crawl only Shopware.
One aspect remains critical: SEO URLs are generated from product titles. Once Odoo takes control of these titles and product names are cleaned up during migration, the resulting slugs will change. This is precisely where the losses occur, not in the ERP migration itself.
This article is aimed at SEO managers who need to assess an upcoming migration, and at 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 nor metadata, canonical tags, or XML sitemaps are changed by the ERP migration, as long as Shopware 6 remains the sole public frontend. Search engines continue to crawl only the Shopware layer – thus preventing duplicate content and ensuring that the crawl budget remains efficiently utilized.
The SEO risk of such a migration is therefore not automatic, but rather a function of what actually changes at the visible frontend level. Structured data (JSON-LD), internal links, breadcrumbs, and customer reviews continue to be fully generated and managed by Shopware in this architecture – they are technically unaffected by the ERP migration as long as the data source for the underlying product and category information has been migrated correctly.
The underestimated pitfall: Maintaining SEO URLs is a task, not an automatic process.
Herein lies the truly critical point, which is often overlooked in many migration projects: As soon as Odoo takes control of product names and category structures, Shopware generates its SEO URLs from precisely this data. Any normalization, standardization, or cleaning of product names performed during the migration – often technically sound and therefore particularly insidious – consequently alters the derived URL slugs.
Maintaining visibility is therefore not an automatic consequence of the architecture, but rather the result of a conscious migration decision: The existing entries of the SEO URL structure are treated as an independent dataset to be migrated. Before the cutover, the complete set of canonical URLs is exported, and after import, it is compared against the newly generated slugs. Any discrepancies are resolved either by fixing the original URL or by implementing a 301 redirect. Only this comparison justifies the claim that a migration proceeds without any 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 mass import and only rebuilt shortly before the final go-live. This significantly speeds up the import process, but should be factored into the timeline: The search index must be completely rebuilt before the shop is reactivated, 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 titles change as part of a data cleanup – a seamless redirect mapping must be in place before the cutover takes place:
- Complete URL matrix: old to new URLs
- Only direct 301 redirects, no redirect chains
- Completeness check before go-live, not afterwards
Redirect chains (one redirect pointing to another redirect) not only slow down the user experience but also dilute the signal passed to search engines. Therefore, every redirect should point as directly as possible to the final target URL.
A practical approach for completeness testing: The complete list of existing, indexed URLs is extracted from Google Search Console and the existing sitemap export before migration. After a dry run, each of these URLs is automatically checked against the new system – either it delivers the same content as before, or it has a correct 301 redirect. Any URL that returns a 404 error must be resolved before going live.
Canonicals
Canonical structures remain unchanged after a properly implemented migration, as they are technically managed by Shopware and are not affected by the ERP change. Nevertheless, it is essential that any changes to product data that indirectly affect generated URLs are checked against the existing canonical entries before going live – a blanket statement like "canonicals will automatically remain correct" is not reliable without this check.
Protect metadata and structured data
In this architecture, structured data (JSON-LD), internal links, breadcrumbs, and customer reviews will continue to be fully generated and managed by Shopware. Titles, descriptions, canonical tags, and JSON-LD markup must not be overwritten uncontrollably during migration—especially if product names or category names, from which these metadata are partially generated automatically, are modified as part of data cleansing.
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 jointly coordinate the migration plan – including a joint QA phase before the cutover, in which URL mapping, canonicals, and structured data are checked on a sample basis. How this check is integrated into the larger cutover process is shown in [reference to relevant document/document]. 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-selling products, important landing pages) that are manually checked on a random sample basis after go-live. The technical team ensures that automated redirect and canonical checks have already been performed as part of the dry run before the actual switchover. This combination of automated breadth checks and manual in-depth checks of business-critical pages covers most practically relevant error scenarios.
Maintaining SEO is one of several checkpoints. Our overview describes the complete migration process with all its phases. Migration from PlentyONE to Odoo.
Frequently asked questions about maintaining SEO during ERP migration
Should we expect a temporary drop in rankings during the migration?
With a well-planned migration that leaves Shopware unchanged as the sole frontend, a drop in rankings is not to be expected. Risks arise specifically where URLs or metadata change due to data cleansing during the migration – these are precisely the areas that are identified in advance during the described alignment process.
How long before go-live should URL synchronization 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 enough time to react properly to discrepancies between old and newly generated URLs, instead of having to make compromises under time pressure.
Does this risk also affect companies that do not want to change their product names?
The risk is significantly lower if no cleanup takes place, but it’s not automatically zero: Technical migration steps, such as a change in character encoding or different handling of special characters, can also unintentionally affect URL slugs. Therefore, a check before going live is 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 with its own verification process before go-live. Any URL that is no longer identical after import is either fixed or resolved via a 301 redirect – before the switchover, not after.
Sources
The statements regarding permanent redirects, canonical tags, 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-safe 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 mitigate SEO risks early on through a controlled comparison of URLs, redirects, canonicals, and metadata. This is precisely what we examine as part of our service. free, non-binding e-commerce audits.
✔ Free of charge ✔ No obligation ✔ Dedicated URL/metadata matching ✔ 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.
