Commercebuild SEO

Independently. We are a small agency that has worked on this platform for about ten years across multiple merchants, and Commercebuild has introduced clients to us. That relationship means we know the platform and the people, and it does not mean we will tell you the platform is right for everything. Where a limitation is real we will say so, because you will find out anyway and we would rather you heard it from us.

No, and the division is clean. Commercebuild is software as a service, the same model as BigCommerce or Shopify, and it provides the functionality: the storefront, the ERP integration, the infrastructure and the support that keeps it running. We help you understand how and when to use it. Their documentation can tell you how a feature works. It cannot tell you whether that feature is worth your time on your catalog this quarter, or which of three options to do first, because that depends on your products, your buyers and what is already broken upstream. Every merchant needs both, and they are genuinely different jobs.

Know what is actually possible before recommending it. A large share of standard SEO advice is either already handled by this platform or impossible on it, and telling those apart takes experience rather than intelligence. We have watched competent consultants recommend adding JSON-LD to a site whose markup is microdata and already working, or propose files the platform does not serve. Every one of those recommendations costs a client money and produces nothing.

Information architecture and taxonomy, navigation, category and product pages, marketing and content pages, schema, data feeds and the measurement that tells you whether any of it worked. Some engagements are all of it in sequence, most are two or three of them, and the diagnostic exists to work out which. The one thing we will not do is start at the end: rewriting product pages on a catalog whose taxonomy is wrong means doing the work twice.

Usually quite a lot. The fields tend to get completed once at launch and then never revisited, so they describe a catalog that has since changed. The more common gap is that the markup already in your template is incomplete: present and valid but missing the fields that make it eligible for rich results, which is a filling-in job rather than a rebuild and is considerably cheaper than it sounds.

It changes the most important decision on the account, which is what should be identical across your stores and what must differ. Pricing and terms usually differ. Product facts usually should not. Category structure is a judgement call and depends on whether the same buyer shops both. Get that line wrong in one direction and you maintain everything twice; get it wrong in the other and the same product is described two ways, which teaches search engines and AI assistants that you are two companies. Three of the groups we work with run several stores on one platform, from a B2B site alongside a B2C one to a second brand brought in after an acquisition, and in every case that line was the work.

That is the preferred outcome and it is what ten years on one platform is actually for. The difference between knowing something and being able to teach it is most of the value here. Your team learns which fields matter, what each does, what the platform does automatically, and the order to work in. Then they run it, and we stay available for the decisions rather than the tasks.

By testing the right way, which on this platform is not obvious. Prices, stock and cart are rendered after the page loads, so a command-line check reads placeholders and produces confident, wrong conclusions. We also know which behaviours are normal for the platform and which are not, so we do not raise a template feature as a fault. On one account we traced a problem beyond the merchant entirely: a platform-level calculation fault that had caused a twenty-six month Merchant Center suspension, which we escalated and had corrected at source.

Almost never, and we will usually argue against it. Replatforming is expensive, puts existing traffic at risk, and most problems we are called in for are configuration and content problems that follow you to the next platform. If your catalog is invisible here, the same catalog will usually be invisible there.

One bounded piece of work first: a review of what the platform is doing, what it is not doing, and what is worth changing in order. It ends with something your team could act on without us. If it makes sense to continue afterwards it usually looks like catalog work or a training rhythm rather than a monthly retainer with a report attached.

Yes, with the relationship stated plainly: Commercebuild refers clients to us, so we are not neutral in the way a paid advisor with no ties would be, and you should weigh that. What we can give you is accurate: what it genuinely does well, what it does not support, and what running it properly takes. We would rather you chose it knowing the constraints than chose it on a demonstration.