Seven years on BigCommerce.Including twenty-five storefronts for one group.
BigCommerce SEO for merchants who want the visibility, the leads and the conversions the platform was supposed to bring.
We are a small agency, not a development shop and not a platform. BigCommerce builds the features and your developer implements them. We work on whether buyers find the store and whether they buy.
Two jobs, and they are not the same job
BigCommerce provides the features
The storefronts, the catalog, the APIs, the B2B edition, the infrastructure and the release cycle. Functionality, built and maintained by a platform business.
They are good at it, and it is not our job.
We help you know how and when to use them
Which capabilities are worth turning on for your catalog, what the platform already handles, what it silently will not do, and the order to work in.
The documentation tells you how. Seven years tells you when.
How you can tell whether someone knows this platform
Six things worth knowing before someone audits your store
None of these are faults. They are how the platform behaves, and every one has changed what a recommendation should say.
- BigCommerce does not serve 410 Gone. So any plan that depends on telling search engines a URL is permanently dead is not available to you. Your real options are redirect or leave it as a 404, and choosing between those is a judgement call rather than a best practice.
- URL slugs drop accented characters instead of transliterating them. On a non-English catalog that quietly mangles product and category URLs, and the damage is invisible until you compare the old and new paths side by side.
- The sitemap index escapes ampersands. Any tool that reads the raw entity instead of decoding it will fetch URLs that do not exist and report a problem that is not there.
- The analytics data layer is not the same as anyone else’s. Event names, parameters and how the product identifier is populated all differ, so a store that keeps the same analytics property through a migration produces a before and after comparison that looks valid and is not.
- Conversion counts can move dramatically with no change in the business. If an event was marked as a key event on the old setup and is not on the new one, reported conversions fall overnight, purely from configuration.
- The catalog API is the right instrument for catalog questions. Crawling the storefront to answer questions about products is slower, less complete and often wrong, and prelaunch stores are gated in a way that defeats automated checks entirely.
If you are mid-migration, items one to five are the ones that cost money. That work has its own page: website migration SEO.
Twenty-five storefronts is a different problem
Where the platform gets genuinely difficult
One group runs twenty-five BigCommerce storefronts, sixteen in the US and nine in Europe, across sixteen brands.
They are separate standalone stores, not one multi-storefront installation. Not a design choice: the platform’s multi-storefront edition did not exist when those stores were built. We were running them as separate installations before there was any way to run them together.
That distinction decides everything about how the work is done. There is no shared catalog to change once, no settings inherited from a parent, and no single place to fix anything. A decision about how a product is described is twenty-five decisions, or it is inconsistent.
The failure we see is a fix applied properly to the flagship brand and never propagated. That leaves the group teaching search engines and AI assistants twenty-five slightly different stories about the same company, which is worse than telling one imperfect story well.
At this scale the work is mostly sequencing and consistency, plus deciding honestly what is worth doing twenty-five times and what is not.
None of this is particular to BigCommerce. BigCommerce, Commercebuild, WooCommerce and Shopify are all software as a service, and running several stores of the same platform is how most multi-brand groups end up on any of them. The reasons are usually historical: brands acquired at different times, stores built before a shared option existed, regional entities that needed their own.
What differs between platforms is how much is shared. Some let several stores sit on one platform with common foundations, and we run groups like that too. Others, including this one at the time these were built, mean fully separate installations with nothing in common. The second is harder, and the question underneath both is the same: what should be identical across your stores, and what must genuinely differ? Answering that badly is expensive either way.
If you are migrating, this is where the traffic goes
What a migration plan usually covers
Products, categories, customers, orders, design, checkout. The things that would obviously break if they were missed.
All of it necessary, and none of it is where the traffic goes.
What it usually misses
URL-level continuity for pages nobody owns: product manuals, leaflets, PDFs that rank and earn clicks on paths the new platform will never reproduce.
Analytics continuity, so the before and after can actually be compared. Slug handling for non-English catalogs. And a redirect map built from what earns traffic rather than from what exists.
The pattern is consistent. The migration plan protects what would obviously break, and the traffic leaves through the things nobody owns. A redirect map built from the sitemap is not the same as one built from what earns clicks, and the difference only shows up eight weeks later when it is expensive to unpick.
What we work on
Catalog structure and taxonomy
How categories divide, how products are assigned, and whether that matches how buyers search rather than how the warehouse is organised.
Category and product pages
The largest block of unused surface area on most stores, and the place where a product information system earns its cost or does not.
Structured data and entity clarity
Product and organization markup that agrees with the feed and identifies the business consistently across every storefront you run.
Feeds and shopping surfaces
What you send to Merchant Center and AI shopping surfaces, and whether it agrees with the page. Disagreement is a suspension risk, and we have seen what that costs.
Migrations
Redirect mapping built from what earns traffic, analytics continuity so the comparison survives, and the assets nobody remembers until they are gone.
Measurement
Configured to answer a question, including whether any of the work above actually reached the index.
Some of this belongs to the platform, some to your developer, and most of it sits in between. Capability the platform provides, filled in by people who have other work to do, against a catalog that keeps changing. That middle is where we are useful.
Who this is for, and who it is not
It fits merchants on BigCommerce who suspect they are not getting what they paid for, groups running several storefronts, businesses mid-migration or about to start one, and teams who would rather learn to run it than hand it over permanently.
We will say no when:
- You need development work. We are not a build shop. We will work alongside yours, and if you do not have one we will say that first.
- The catalog is the problem, not the platform. Then platform work is a distraction and we will point you at the actual issue.
- You want us to run it forever. We would rather train your team and step back.
- You want a guarantee we can overrule a platform constraint. Some of them are real. We will tell you which.
Where this sits beside the rest
Platform knowledge is how the work gets done, not what the work is. The catalog itself is ecommerce SEO, crawling and rendering are technical SEO, and whether assistants can quote your product pages is answer engine optimization.
We do the same platform-specific work on Commercebuild, and the broader picture is on the SEO consultant page.
Questions we get asked
Q. How long have you worked on BigCommerce?
About seven years, and the deepest of it is a group running twenty-five storefronts on the platform, sixteen in the US and nine in Europe, across sixteen brands, with a single product information system feeding all of them. They are standalone stores rather than one multi-storefront installation, because the multi-storefront edition did not exist when those stores were built. That makes the work harder rather than easier: nothing is shared, so every decision is either repeated twenty-five times or it is inconsistent. It is also a reasonable measure of how long we have been on the platform, since we predate one of its significant features.
Q. Does this overlap with what BigCommerce or our developer already does?
No. BigCommerce provides the platform and your developer builds on it. We work on whether buyers find the store, whether the pages persuade them, and whether that becomes orders. A platform company builds features and a developer implements them. Deciding which features are worth your time this quarter, and in what order, is a third job that usually belongs to nobody.
Q. We are migrating to BigCommerce. When should we involve you?
Before the redirect map is written, which is earlier than most people ask. The expensive mistakes are made in planning: a redirect map built from the page list rather than from what actually earns traffic, analytics that silently stops being comparable, and assets like product manuals and PDFs that rank today and live on paths the new platform will not reproduce. Every one of those is cheap to prevent and expensive to discover afterwards.
Q. Our traffic dropped after we replatformed. Can you find out why?
Usually, and the first thing to establish is whether it dropped at all. A migration frequently changes how conversions and events are recorded, so reported performance can fall sharply while the business is unchanged. We separate the measurement artifacts from the real losses first, because chasing a reporting change is an expensive way to spend three months.
Q. We run several storefronts. Is that harder?
Yes, and mostly in ways that are not obvious. The individual store work is the same. What changes is that every decision is now a decision across all of them, and the common failure is a fix applied properly to the flagship brand and never propagated. It matters a great deal whether your stores are separate installations or one shared setup, because separate installations share nothing and consistency becomes something you impose deliberately rather than something the platform provides. That situation is common on every ecommerce platform, usually for historical reasons: brands acquired at different times, stores built before a shared option existed, regional entities that needed their own. The group we know best runs twenty-five separate installations across two regions, and almost all of the difficulty lives in that one fact.
Q. Can you work with our BigCommerce developer or agency?
Yes, and we frequently do. Our work is usually the part they do not cover: catalog structure, content at scale, structured data, feeds and measurement. We write findings so a developer can act on them without translation, and we verify afterwards rather than assuming a closed ticket means a fixed problem.
Q. Do you recommend BigCommerce over other platforms?
We recommend not replatforming unless there is a reason that survives scrutiny, which is a different answer. BigCommerce is a capable platform and we have worked on it for years. It also has constraints, some of which are on this page, and you should know them before committing rather than after. If you are already on it, the useful question is not whether it was the right choice but what it is capable of that you are not using.
Q. What do you need from us to start?
Backoffice access, catalog API access, Search Console and analytics. With those we can tell you what the store is doing, what it is not doing, and which of the two is worth money, usually within a bounded piece of work rather than a retainer.
Start with a conversation
Thirty minutes on what your store is doing well, what it is not doing at all, and which of the two is worth money. If you are planning a migration, have the call before the redirect map is written. That is the point where advice is cheapest and most useful.