commercetools SEO: what to sort out before you migrate

Here’s what we’ve learned running SEO through these migrations, including an 18-month move to commercetools for Chemist Warehouse.

commercetools is a composable commerce platform. It gives you APIs for the product catalogue, pricing, cart, checkout and order management. That is the scope.

It doesn’t render pages. It has no opinion on your URL structure, no meta title field waiting to be filled in, no sitemap, no canonical logic and no robots directives. Those decisions live in the frontend, whether that’s commercetools Frontend (the product formerly known as Frontastic), a custom Next.js build, or a headless CMS like Contentful or Contentstack driving the templates.

Whoever owns that frontend owns your SEO fundamentals by default, whether they’ve agreed to it or not.

That is the most useful thing to know before you start. On a templated platform, a bad SEO outcome is usually something someone did. On commercetools, a bad SEO outcome is usually something nobody did.

It’s neutral, and that’s the honest answer.

The platform can support a better technical setup than Shopify or BigCommerce will ever allow, because nothing is fixed. You can build the URL hierarchy your catalogue actually needs, set crawl rules per market, and control rendering properly. You can also ship a site with no canonical tags at all, because nothing stops you.

Capability is not configuration. commercetools gives you the first and none of the second.

The biggest factor in whether a migration keeps its rankings is whether someone wrote down who’s responsible for what before development started.

We split it three ways on every migration:

• What SEO owns outright: URL structure, canonical decisions, the redirect map, structured data, and the pre-migration benchmark.
• What’s shared with the dev team: what content gets kept, merged or binned, internal linking, and how search engines and AI crawlers can access the site.
• What SEO signs off at checkpoints: page templates, metadata, the pre-launch crawl, and post-launch monitoring.

Skip this and SEO becomes something someone remembers to loop in near the end. On a composable build, with several different systems each owning a different part of the site, near the end is too late without a scramble.

None of them is better. They put the effort in different places.

• Shopify decides the fundamentals for you. Canonicals, sitemaps, meta fields, crawl setup, all of it ships working without a developer. The trade-off is that you’re inside someone else’s decisions: collections sit under /collections/, nested paths aren’t supported, faceting runs on tags. If your taxonomy fits those rules you’ll barely notice. If it doesn’t, you’ll pay to build workarounds.
• BigCommerce is similar in shape. A lot is already decided for you, which is good for speed and bad for control.
• Adobe Commerce (Magento) gives you more control, at the cost of requiring someone senior to handle the technical setup. It can do almost anything, which is exactly why it needs oversight rather than a template.
• commercetools sits at the far end of that scale. Nothing is decided, so nothing is in your way, and nothing exists.
• SAP Commerce Cloud and Salesforce Commerce Cloud turn up on the same shortlists. The question doesn’t change: how much is decided for you, and who is responsible for everything that isn’t.

None of this makes commercetools the “best” platform. It’s the right one when you’ve genuinely outgrown what a templated platform can do, not before. Woolworths Group and Nespresso are both commercetools customers, alongside Chemist Warehouse. That’s the class of retailer it’s built for: high SKU count, multiple markets, enough scale that a templated platform starts working against you rather than for you.

Rarely the platform. In our experience it’s these three, in this order.

A PIM (usually Akeneo, Salsify or inriver on builds this size) is great for consistency and bad for content depth. The same efficiency that keeps everything in sync tends to make every product description read the same.

Budget product and category content as its own line item. It won’t come free with the new platform.

A JavaScript frontend can render perfectly for a customer and badly for a crawler, and the AI crawlers are less forgiving than Googlebot. Decide the rendering approach, whether that’s server-side, static or hybrid, as a build decision with SEO in the room. Not as a performance tweak after launch.

We can’t give you a number without seeing the build, but these four things decide most of it.

• Fixed fee beats hourly: migration scope moves constantly as build decisions change, so hourly billing on SEO during a migration is effectively a blank cheque. A fixed-fee structure tied to build milestones keeps budget certain and ties invoices to actual deliverables.
• Budget the weeks after launch, not just the build: most of the budget conversation goes into getting to launch. The four to eight weeks after go-live is when issues actually surface, and if there’s no time or budget set aside to fix them, they sit there while traffic drops.
• More vendors means more coordination, and that’s a real cost: a composable build means separate relationships with a platform partner, a search vendor, a CMS vendor, a PIM vendor and an SEO partner. Someone on your side needs to own pulling that together, and that’s time, not just invoices.
• Fixing it after is more expensive than building it right: we’ve recovered a fashion retailer’s migration that went wrong elsewhere, and it took two months of focused work to get back to growth. That’s two months you don’t get back, on top of whatever the fix cost.

If you’re planning a move

The platform is rarely what costs a commercetools migration its rankings. The cost comes from treating SEO as a final check when it should have been part of the design brief.

Agree ownership early, understand what you’re trading up from and why, and protect budget for the weeks after go-live as well as for the build. Then keep SEO in the room week to week, not only at the milestones.