From F&B to fintech, clinics to law firms, startups to enterprise. If your customers search on Google, we make sure they find you first, not your competitors.
One specialist team, focused only on the organic rankings that put you in front of ready-to-buy Singapore customers.
A clear, sequenced path from audit to rankings. You always know what we’re doing and why it matters for your leads.
Quick answer: The best seo for ecommerce sites is the same strategy routed through different machinery. Shopify constrains URLs and robots control, WooCommerce hands you full control plus performance and plugin risk, and custom builds can do anything but often ship without rendering, sitemaps or canonicals specified at all.
Platform is the question buyers ask most often and the one most badly answered, usually with a version of “it does not matter, good SEO is good SEO”. That is half right in a way that is actively unhelpful. The objectives are identical on every build: fewer, better URLs, a strong category layer, differentiated product data and a guide layer that earns what a marketplace cannot. What changes completely is the route to each of those, how many hours it costs, who has to touch it, and which failures happen silently. This post is the technical comparison rather than a vendor discussion. It covers what actually differs on a hosted storefront, on a self-hosted WordPress store and on a custom or headless build, with the specific constraints named. For the commercial framing of catalogue work, our e-commerce SEO page covers that separately.
Start with the constant, because it saves a lot of platform argument.
The index plan is platform-independent. Every store needs a written decision per URL template: crawl, canonical, internal link rule, sitemap inclusion. Home, category, subcategory, product, variant, each filter type, sort, pagination, search results and any legacy patterns. That document looks the same whether you are on a hosted platform or a bespoke build. Only the enforcement column changes.
The category layer carries the non-branded demand everywhere. Type-level queries resolve to listings. This is true on every platform and it is under-built on most stores regardless of build.
Product pages compete against the same manufacturer text everywhere. If you stock a third-party brand, your description is probably identical to every other local stockist and to the marketplace listing. No platform solves that.
Stock lifecycle rules are required everywhere. Temporarily out of stock, discontinued with a successor, discontinued without one, and seasonal. Four scenarios, four handlings, and every platform gets at least two of them wrong by default.
What genuinely differs is three things: how much of the index plan you can enforce, how much performance work is yours versus the platform’s, and whether a template change is a settings toggle, a theme edit or a sprint. That is the whole comparison, and everything below is a detailed version of it.
Conventional wisdom says you should pick the platform with the best SEO reputation and the problem largely goes away. We would push back on that firmly. Reputation is a summary of defaults, and defaults are the part you are going to override anyway once the index plan exists. In our experience the platform that suits your merchandising and your team is the one that produces the best search outcome, because it is the one that will actually get maintained.
The trade is explicit. You get infrastructure you will never have to think about and a URL structure you will never be able to change.
Path structure is fixed. Products live under a products path, listings under a collections path, editorial under pages and blogs. You cannot flatten or nest them differently. In practice this matters less than people expect, because path depth is a weak signal, but it does mean any migration onto the platform is a full redirect mapping exercise rather than a URL-preserving move.
The duplicate product path is the classic issue. The same product is reachable both at its canonical product URL and at a collection-scoped path, which means every product can have several addresses depending on how it was linked. Well-built themes emit a canonical to the clean product URL. Theme edits, older themes and some apps break that quietly, and nothing on the front end looks wrong when they do.
Filtering has two eras and they behave differently. Older tag-based filtering produces path-style filtered URLs that are crawlable and frequently indexed. The newer filter mechanism produces query parameters instead. Both need a demand-tested rule per facet type, and the rule has to be enforced in your own navigation as well, because a filtered URL you have disowned but still link to is a contradictory instruction.
Robots control exists now but is templated. The platform allows the robots file to be edited through a template, which is enough for most facet rules but is not the same as arbitrary server control. There is also no server log access on standard plans, so crawl diagnosis leans on Search Console crawl stats rather than raw logs.
The sitemap is generated for you and not editable. That is fine once your canonicals and noindex rules are right, because the generated file follows them, and it is a problem when they are wrong, because you cannot manually correct the output.
Template change is genuinely cheap. This is the platform’s strongest SEO characteristic. Title patterns, heading logic, structured data fields, breadcrumbs and related-product rules are theme-level edits that apply across the whole catalogue in an afternoon. On a store with 3,000 products that leverage is enormous, and it is the reason hosted stores often make faster early progress than better-resourced custom builds.
App accumulation is the quiet performance tax. Every app injects scripts, and a store that has collected fifteen over three years is usually carrying several it no longer uses. We have removed six or seven unused apps from a single mature store and recovered more loading time than a month of image work would have, which is why auditing installed apps against actual use sits squarely inside technical SEO rather than in merchandising.
The inverse trade. Nothing is off limits and nothing is guaranteed.
You own the URL structure and the server. Permalink bases, redirect rules at server level, a real robots file, and full control of headers and status codes. Everything in an index plan is enforceable. The constraint is that enforcement is your responsibility, including when a plugin update quietly changes it.
Attribute archives are the most common uninvited index problem. Product attributes can generate their own archive pages for every value you have ever used. Colour, size, material and capacity archives appear as crawlable URLs that nobody chose to publish and that duplicate category listings. These should almost always be excluded, and on most stores they are not, because the setting is buried and the pages are invisible in the admin.
Layered navigation adds parameters on top of that. Filter parameters, price range parameters and sort parameters combine freely, which is where the combinatorial explosion comes from. The parameters are easy to control precisely because you have full robots and canonical access, so this is a solved problem on a well-run store and an unbounded one on a neglected store.
Variable products behave better than most people assume. Variations usually sit on the parent URL with parameters rather than separate addresses, which avoids the variant duplication problem. The trap is themes and plugins that create standalone variation pages for merchandising reasons.
Performance is the real workload. Cart fragment requests firing on non-cart pages, uncached admin-side requests, plugin script bloat, oversized product imagery and slow database queries on large catalogues all hit time to first byte and interaction responsiveness. Full-page caching with correct exclusions for cart and checkout, object caching, and an image pipeline are not optional at catalogue scale. Crawlers slow down on slow hosts, so on a large store this is not just a user experience issue, it directly reduces how much of your catalogue gets seen.
Plugin conflict is a category of risk with no hosted equivalent. Two plugins emitting structured data, a caching layer serving a stale canonical, a security plugin blocking a crawler user agent, a redirect plugin fighting server-level rules. Most of these are invisible until a crawl finds them, which is why a scheduled crawl is a maintenance task on a self-hosted store rather than a one-off project. When we run a standalone SEO audit and consulting engagement on a self-hosted catalogue, conflicts of this kind account for a large share of what the crawl surfaces.
Bespoke storefronts and decoupled front ends give complete freedom and remove every safety net that the packaged platforms provide.
Rendering is the first and largest question. If your product grid, filter links or pagination only exist after JavaScript executes, discovery depends on a rendering step that is queued rather than guaranteed. Server-side rendering for listings, with real anchor elements rather than click handlers, remains the reliable choice on large catalogues whatever the framework documentation promises. This is the single most common cause of large custom stores under-indexing.
Status codes have to be implemented deliberately. A single-page application returning a 200 response with an error view for a removed product is a soft 404, and at catalogue scale it teaches the crawler to distrust that whole URL pattern. Every removal, redirect and not-found case needs a real status code from the server.
Canonicals, pagination and hreflang are code, not settings. They are also easy to get subtly wrong, such as a canonical rendered client-side, or a paginated series where every page canonicalises to page one and deeper products stop being discoverable.
The sitemap has to be built and maintained. Generated from the canonical set, split by type, with honest last-modified dates. Custom builds frequently ship with either no sitemap or one that lists every route the router can produce.
Parameter handling is whatever your API layer emits. Filters implemented as query parameters against a search service can produce an unbounded URL space very quickly, and because it is generated at the edge rather than in a CMS, nobody notices until the crawl does.
The real timeline is the engineering queue. On a custom build almost every index plan row becomes a ticket, and ticket throughput, not search expertise, sets the pace of the programme. The practical consequence is that specifications have to be written the way a developer can accept them: acceptance criteria, example URLs, expected status codes and a test. Scoping this correctly is a large part of why catalogue engagements on custom builds are priced differently, as set out on our e-commerce SEO services in Singapore page.
The compensating advantage is real. When you do have engineering capacity, a custom build can implement things the packaged platforms cannot: programmatic category generation from demand data, edge-cached listing pages, precise internal link rules, and structured data assembled from the source of truth rather than from a theme.
| Job | Hosted storefront | Self-hosted WordPress store | Custom or headless build |
|---|---|---|---|
| Change a title pattern across all products | Theme template edit, under an hour | Plugin setting or template filter, under an hour | Code change, a ticket and a release |
| Control which filter URLs are crawlable | Robots template plus facet rules, partial control | Full robots and parameter control | Whatever the router and API emit, must be specified |
| Set a non-default canonical | Theme edit, possible but easy to break | Fully controllable, watch plugin conflicts | Must be rendered server-side, easy to get wrong |
| Remove uninvited archive pages | Rarely an issue | Common and important, attribute archives | Only exists if someone built it |
| Improve time to first byte | Platform handles it | Your responsibility, caching and hosting | Your responsibility, usually edge caching |
| Extend product structured data | Metafields plus theme edit | Plugin fields or a code snippet | Built from source data, most accurate of the three |
| Guarantee listing pages are crawlable | Default, server rendered | Default, server rendered | Must be designed for, most common failure point |
| Recover from a bad release | Rare, platform stability | Staging plus backups, your process | Full rollback needed, highest blast radius |
Read that table as effort, not as quality. None of these platforms is better at SEO. Hosted builds make template leverage cheap and index control partial. Self-hosted builds make index control total and performance your problem. Custom builds make everything possible and nothing automatic. The strategy is identical across all three. Our e-commerce SEO results case study covers a WooCommerce store, but the order of decisions it describes, index repair first, then schema, category pages and content, holds whatever the store was built on.
The three-way comparison covers most of the market, but not all of it.
Enterprise commerce platforms appear on larger local catalogues and on B2B suppliers with complex pricing and account-specific catalogues. They combine deep configurability with heavy infrastructure requirements, and the SEO work skews towards index segmentation, faceted search governance and making sure that account-gated pricing does not accidentally produce either cloaked content or empty pages for crawlers. The B2B pattern, where trade buyers need specifications, minimum order quantities and lead times on public category pages before they will enquire, is the situation covered in our B2B e-commerce results write-up.
Regional and local website builders are common among smaller Singapore merchants, often bundled with payment and delivery integrations that suit the local market. They vary widely. The questions to ask are the same five every time: can you control the robots file, can you set canonicals, can you edit title patterns at template level, can you extend product structured data, and can you export a clean redirect map if you leave. If two or more answers are no, plan the eventual migration into the budget rather than pretending it will not happen.
Marketplace-first businesses with a thin owned storefront are a distinct case. Here the platform question is premature. The prior question is whether the owned domain has a job that Shopee and Lazada cannot do, and if the answer is currently no, the right move is to build that job before rebuilding the site.
Some of the differences that matter locally are not in any platform comparison chart.
Hosting geography is a live variable on self-hosted and custom stores. A store serving mainly Singapore shoppers from a distant origin with no edge caching pays that latency on every request, users and crawlers alike. Hosted platforms remove this decision entirely, which is a genuine advantage for smaller merchants without technical staff.
Currency and tax display must match the markup. Prices in SGD on the page, in the structured data and in the feed, with tax handling consistent between them. Mismatches are the most frequent cause of lost rich results we encounter on local stores, and they almost always appear after a promotion, a tax display change or a currency switcher is added post-launch.
Local checkout expectations shape the product template. Shoppers here expect to see delivery windows, self-collection options where relevant, and familiar payment methods. These live in the template rather than in individual pages, which means they are a one-afternoon change on a hosted or self-hosted build and a ticket on a custom one.
Cross-border needs deciding rather than drifting. If you ship to Malaysia, Indonesia or Australia, choose deliberately between one site with clear shipping and currency information and properly annotated localised versions. Half-implemented setups where prices switch by geolocation but URLs do not produce confused indexing and confused customers at the same time. Hosted platforms have opinionated tooling for this, self-hosted stores have plugins of varying quality, and custom builds have whatever was specified.
Our ecommerce case study shows how long migration debris can linger. The WooCommerce home and lifestyle store had been through two prior platform migrations, and they had left more than 200 redirect chains that were silently leaking PageRank. Resolving those chains was part of the crawl and index repair in Months 1 to 2, alongside a clean XML sitemap and robots.txt rules for faceted navigation, and product indexation moved from 34% to 79% in that period. The lesson for any move between builds is that the redirect map deserves as much care as the new store itself: build it from a full crawl plus your analytics entrance list, not from the sitemap alone, and check for chains after launch rather than assuming the old ones were cleaned up.
Replatforming is the moment where platform choice becomes a search risk rather than a preference.
Build the redirect map from three sources. A full crawl of the old site, the list of URLs with organic entrances over the last twelve months, and the backlink profile. Sitemap-derived maps miss exactly the legacy URLs that still carry value.
Preserve the category layer above everything else. Product URLs are usually mapped mechanically. Categories are where structures diverge between platforms and where the non-branded demand sits, so map them by hand.
Recreate structured data before launch, not after. Product markup, breadcrumbs and availability need to exist on day one, because the gap is measured in weeks of lost rich results.
Keep the old crawl for comparison. Post-launch, crawl the new store and compare template counts. Categories missing, product count down, or a new parameter pattern appearing are all visible in an hour and expensive to find in month three.
Price it as a project. Migration is intensive, time-boxed and carries the highest risk of any work on a store, and folding it into a normal retainer month means something else silently stops happening. Our pricing page separates project work from ongoing work for exactly that reason.
Field notes: In our ecommerce case study, the store was a self-hosted WooCommerce catalogue, and its faults were the textbook ones for that build type. Three years of accumulated faceted navigation URLs had created thousands of duplicate pages, there was no XML sitemap, no robots.txt rules blocking faceted navigation parameters, no structured data of any kind, and Core Web Vitals were failing on all three metrics. Only 34% of product pages, 68 of 200, were indexed. The fixes were equally build-specific: robots.txt rules for 14 parameter combinations, Product schema through WooCommerce structured data plugins with custom overrides for edge cases, and redirect chains resolved. Indexation reached 95% by Month 9 and Core Web Vitals moved to passing. A hosted or custom build would have needed a different list, which is why we diagnose by build type before writing any plan.
The best seo for ecommerce sites is not a platform recommendation. It is the same ordered set of decisions delivered through whichever machinery you already own, with the effort redistributed according to what that machinery makes easy and what it makes dangerous.
If you are on a hosted platform, exploit the template leverage hard and spend your technical attention on canonical integrity, facet rules and app bloat. If you are self-hosted, your wins are in the uninvited archives, the parameter space and time to first byte, and your recurring risk is plugin conflict, so crawl on a schedule. If you are on a custom build, settle rendering and status codes before anything else, write specifications a developer can accept, and accept that the engineering queue is your real timeline.
The contrarian point is that platform is a far weaker predictor of organic performance than almost any buyer expects. We have seen strong catalogues on every one of these builds and neglected ones on all three, and the difference has consistently been whether an index plan existed and was enforced, not what the store was built with. Choose the platform that fits your team and your merchandising, then do the work. If you want to know which of these failure patterns your build is carrying, that is what the technical side of our SEO services is for.
None of them, and treating it as a platform question usually wastes a decision. Hosted platforms give you fast infrastructure and cheap template-level changes while constraining URL structure and robots control. Self-hosted WordPress stores give you complete control and hand you performance and plugin conflict as ongoing work. Custom builds can do anything and frequently ship without rendering, canonicals or sitemaps specified. Pick on merchandising needs, team capability and budget, then apply the same index plan whichever you choose.
Two real ones and one overstated one. The real constraints are the fixed URL path structure, which matters mainly at migration, and partial robots control through a template rather than a server file. The genuine ongoing risk is collection-scoped product paths producing multiple addresses for the same item when a theme or app breaks the canonical. The overstated concern is path depth, which has very little practical effect. The platform’s big advantage is that template changes reach the whole catalogue quickly.
Uninvited URLs, in two forms. Product attribute archives generate crawlable pages for every colour, size and material value ever used, duplicating category listings and usually going unnoticed because they are invisible in the admin. Layered navigation then adds filter, price and sort parameters that combine freely. Both are fully controllable because you own the robots file and canonicals, so this is a solved problem on a maintained store. The second issue is time to first byte, which needs caching and hosting attention.
Not inherently, but they fail differently and more silently. The dominant issue is discovery: if listing pages, filter links or pagination require JavaScript, indexing depends on a rendering step that is queued rather than guaranteed. The second is status codes, where a single-page application returns 200 with an error view instead of a genuine 404. Settle server-side rendering for listings and real status codes before anything else, and a custom build can outperform the packaged platforms because structured data and internal links can be generated from source data.
Rarely, and almost never as the primary reason. Migration is the highest-risk work you can do on a store and it routinely costs a quarter of recovery even when handled well. Switch when merchandising, operations or total cost of ownership demand it, and treat the SEO work as a risk to be managed during the move rather than a benefit to be gained from it. If the current platform genuinely cannot control robots, canonicals or title templates, that is one of the few cases where the search argument carries weight.
The rule is identical everywhere and only the mechanism differs. Decide per facet type: index it as a real page when there is search demand for that combination, canonical it to the parent when there is not, and block crawling for price ranges, sort orders, availability toggles and multi-facet combinations. On a hosted platform this runs through the robots template and theme canonicals. On WordPress it runs through the robots file, an SEO plugin and parameter rules. On a custom build it is specified in the router. Enforce it in your own internal links too.
The work differs, the requirement does not. Hosted platforms handle infrastructure, so your speed work is mostly app and script auditing plus image discipline. Self-hosted stores need full-page caching with correct cart and checkout exclusions, object caching, an image pipeline and appropriate hosting, and this is where the largest gains usually sit. Custom builds need edge caching and bundle discipline. On large catalogues speed also affects how much of your site gets crawled, because crawlers slow down on slow hosts.
On self-hosted and custom builds it is worth deliberate attention. A store serving mainly local shoppers from a distant origin with no edge caching pays that latency on every request. A content delivery network with regional presence usually solves the asset side, but time to first byte still depends on where the application responds from. Hosted platforms remove the decision entirely, which is a genuine advantage for smaller merchants without technical support. Test with real local measurements rather than assuming.
Treat it as a strategy question rather than a duplication problem. Your product descriptions will be similar or identical across your site and the marketplace listings, and the marketplace domain is far stronger, so competing head-on for generic product queries is the least winnable fight available. Put original effort into category pages and explanatory guides covering what a listing cannot carry: compatibility, local sizing, warranty, servicing and bundles. That layer is platform-independent and it is where owned-domain growth comes from locally.
Crawl the new store within days and compare template counts against a crawl of the old one. Look for categories missing, product counts down, new parameter patterns appearing, and any page returning 200 where it should return 404 or 301. Then check indexation coverage by template weekly for the first two months, and structured data validity across a sample of products. Build the redirect map from a crawl plus the analytics entrance list rather than from the old sitemap, because sitemaps omit the legacy URLs that still carry links.
If you want to know which of these platform failure patterns your store is carrying right now, we will run a free initial review of your build and send back the specific issues we find, ordered by revenue impact rather than by severity score. You keep the findings whether or not you work with us. Get in touch with your store URL, your platform and your rough product count, and we will tell you what your build is doing by default that you did not choose.
Natalie leads SEO strategy at Singapore SEO Agency, helping local and regional businesses build organic search programmes that drive qualified leads. She specialises in technical SEO and content-led authority building for Singapore SMEs.
Get a free SEO audit for your Singapore website — we'll show you exactly where you stand, what's holding you back, and what it would take to rank on page 1.
Get Your Free SEO Audit →
Google analytics consulting services for Singapore SMEs: what consultants do, indicative SGD costs, deliverables to demand and red flags. Buy the right scope.
Bounce rate in GA4 is not the old Universal Analytics number. Learn what it measures now, why old benchmarks fail and how to judge each page by its job.
Yoast SEO helps most when its site-wide settings are right. See which settings to choose, what the traffic lights really mean and the mistakes to avoid.
Which free keyword research tool should a Singapore clinic, firm, contractor or tutor use? Combine five free tools to find your first 30-50 keywords. See how.
SEO vs SEM is usually the wrong question. Learn what the terms really mean and how to use ads and Search Console data to decide which searches to earn or buy.
Google Search Console login problems usually start with verification and ownership. Learn how to get in, fix access errors and offboard agencies safely.
Fast, no obligation. We reply within 24 hrs.
Singapore’s specialist SEO agency for SMEs. We rank your business on Google — and only Google. No distractions, just results.
© 2026 Singapore SEO Agency. All rights reserved.