Technology
SEO on Salesforce Commerce Cloud
We know the platform well enough not to learn at your expense: what can change, who has to change it and which release it lands in.
Let's talk about your project- 9
- ecommerce projects worked on SFCC
- 10
- years inside the platform, since Demandware
- 48 h
- to reply, at most
Brands that have trusted Laika
Do any of these situations sound familiar?
On an enterprise platform the problem is rarely a lack of ideas: it's that the ideas don't fit what the platform allows or the calendar of whoever maintains it.
An SEO change takes three releases to reach production
Every request joins a queue shared with business and product, and what was asked for in January ships in April with nobody remembering why.
Nobody knows if the problem is the template, the catalog or Page Designer
The symptom shows in Search Console, but the cause is split across Business Manager, the cartridge and whatever each content team assembles.
Refinements generate thousands of URLs nobody decided on
Facets create endless combinations, crawling drifts to variants with no demand and the categories that sell lose strength.
Every new market repeats the previous one's mistakes
Sites get cloned with the same locale, hreflang and URL setup, so the problem multiplies with every country you open.
The previous agency asked for things the platform doesn't allow
Recommendations copied from a WordPress site: impossible to implement on SFCC, rejected by development, and trust burned along the way.
A version or headless migration is coming and it's scary
There's a date, there's budget and nobody who can say what breaks in SEO if rendering or the URL structure changes.
Where SFCC's real limits are
It's not a site with a flexible CMS: it's an ecommerce where the catalog, the configuration and the publishing cycle decide what's possible. This is what shapes any strategy.
- 01
What you touch in Business Manager and what you don't
A good part of SEO lives in configuration, not code: URL rules, catalog aliases, sitemaps, redirects. Knowing where each lever sits saves tickets.
- 02
The catalog rules the architecture
Category structure, variation products and masters decide which pages exist. Changing the site without touching the catalog rarely works.
- 03
Refinements, sorting and pagination
Every refinable attribute multiplies URLs. The decision isn't technical: it's which combinations have enough demand to deserve an indexable page.
- 04
Multi-site, locales and hreflang
One site per market, shared locales and different domains: the setup decides whether markets help or cannibalise each other.
- 05
Rendering: SFRA, Page Designer and headless
What ends up in the HTML changes with how the page is built. On headless with SCAPI you must decide what renders server-side before building.
- 06
The release calendar
Nothing reaches production outside the cycle. Prioritising on SFCC means choosing what fits the next window and what can wait at no cost.
What we work on inside the platform
The weight changes with your version, your markets and who maintains the instance, but these four fronts get reviewed in every project.
Catalog and facet architecture
Decide which pages should exist, which get indexed and which stay filters without their own URL.
- Category map against real demand per market
- Indexing rules by refinement type and combination
- Handling of sorting, pagination and product variants
- Criteria for landing pages that do deserve their own content
International and multi-site
So opening a new market doesn't repeat the previous one's mistakes or take from the one already working.
- Review of site, locale and domain configuration
- hreflang, canonicals and URLs per language and country
- Market priority based on demand and business capacity
- Translation and catalog adaptation criteria per country
Rendering and performance
So what matters is in the HTML and the template doesn't cost you positions on mobile.
- What renders server-side and what depends on JavaScript
- Review of SFRA templates and Page Designer modules
- Listing and product page performance on mobile, business first
- Structured data for products, availability and ratings
Specification and validation
So every recommendation arrives in a format development can estimate and ship without translation.
- Specs written for the platform, not generic ones
- Separating what is configuration from what is code
- Validation on sandbox or staging before the release
- Post-deploy checks and tracking of the effect
How we work with your development team
We bring the judgement and the spec; your team or your partner implements. We validate before shipping and measure afterwards.
- 01
Understand the instance, not the website
We review configuration, catalog, templates and how you publish. Without that, any recommendation is a hypothesis.
Output a diagnosis tied to your instance
- 02
Separate configuration from development
Whatever can be solved in Business Manager leaves the development queue and moves in days, not quarters.
Output two lists with different owners
- 03
Write the spec in their language
Each item is documented with the exact object, template or setting to touch and what is expected afterwards.
Output tickets ready to estimate
- 04
Validate before the release
We check on sandbox or staging that what's implemented does what was asked, before it reaches production.
Output a sign-off or a fix in time
- 05
Measure the effect of that window
Every release is reviewed against expectations: what moved, what didn't and what goes into the next one.
Output the priority for the next cycle
What's in and what isn't
We don't touch your code or replace your partner. We bring the decision and the spec, which is where most time gets lost.
What's in
- Diagnosis and strategy within the platform's rules
- Technical specs ready for your team or your implementation partner
- Architecture, facet and market decisions
- Pre-production validation and support on each release
What's out
- Cartridge development or changes to your codebase
- Catalog management or product uploads
- Replacing your implementation partner
- Promising timelines that depend on your release calendar
Why Laika on SFCC?
Because on this platform judgement is worth more than a task list.
Every release is a narrow window. Getting right what goes in — and dropping what the platform won't allow — is the difference between gaining a quarter or losing it.
We don't learn at your expense
We've spent years inside SFCC across fashion, optics, sport and food retail. We know what can be asked for and what will be rejected.
We talk to development without an interpreter
Recommendations arrive with the exact object and setting. That cuts meetings, avoids misunderstandings and shortens time to production.
We know the Spanish and LATAM market
Most enterprise SFCC projects are run from abroad. We understand local demand and how people buy here.
We prioritise by business, not by checklist
On a platform with closed windows, what matters is choosing well the three things that make it into the next release.
Who does it?
Senior profiles with years of enterprise ecommerce behind them. Whoever reviews your instance signs the recommendation.
Services included
Frequently asked questions
Do you need to touch our code?
No. We diagnose, decide and specify; your team or your partner implements. We validate before and after the release.
We work with an implementation partner, do you overlap?
No. The partner builds and we bring the SEO judgement. We work in their ticket format and their calendar.
Does it work the same on SFRA and headless?
The judgement is the same, the levers aren't. On headless many decisions happen before building, so it pays to get involved early.
Can you support us through a version migration?
Yes, it's one of the moments where most is won or lost. We work it with a dedicated migration plan.
How long until the effect shows?
It depends on your release calendar more than on us. That's why we always separate configuration from what needs development.
Tell us how your instance is set up
With your version, open markets and who maintains the platform, we can tell you what can move now and what depends on the next release.
Do you run an ecommerce on Salesforce?
We look at your instance before proposing anything and tell you where we'd start.
We look at your project before proposing anything. Reply within two working days at most.
Talk to us about your instance