SEO by Platform
The same SEO recommendation is trivial on one platform and impossible on another, which is why the platform gets named first. Ivan Sp implements SEO on WordPress, Shopify, Squarespace, and Wix, and each platform genuinely trades some technical control for something else. Naming that tradeoff plainly, instead of pretending every platform behaves the same way, is what decides whether a recommended fix is actually achievable.
Why Platform Matters Before a Fix Gets Recommended
I establish the constraint set before recommending anything. A technical fix that works on an open platform sometimes does not exist as an option on a hosted one. Recommending it anyway wastes a client’s time chasing a setting that is not there. Every audit starts with the platform’s real capabilities, not a generic checklist written for the most flexible platform and applied to all four.
Four Platforms, Four Different Tradeoffs
- WordPress SEO and its direct database access
- Shopify SEO within a hosted catalogue structure
- Squarespace SEO on a design-first platform
- Wix SEO after its major SEO tooling improvements
WordPress trades a simpler hosted experience for full database and template access. Shopify and Squarespace trade some of that access for a maintained, reliable hosted platform. Wix carried genuine limitations in its earlier years and has closed most of them, a fact most consultants never bother rechecking.
A Note on BigCommerce
BigCommerce is not currently covered as a supported implementation platform on this site. Where a project needs BigCommerce-specific work, that gets scoped and confirmed directly on the initial call rather than assumed from this page.
Content and Strategy Work Transfers Across Platforms
Topical mapping, keyword research, and content strategy work the same way regardless of which CMS a site runs on, since none of it depends on template-level access. Platform constraints mainly affect implementation: how a fix gets applied, not whether the underlying strategy is sound.
Where the Standard Platform Advice Breaks Down
- The usual advice
- Pick the platform with the strongest SEO, since some platforms are simply better for search.
- What holds up in practice
- Platform choice decides which fixes are cheap, not whether a site can rank. Google has stated publicly that sites on hosted platforms rank perfectly well. The real variable is what a given fix costs on that stack.
Picture a business advised to migrate from a hosted platform to WordPress for SEO reasons. The migration takes four months and consumes the year’s budget.
The original problem was an empty services list, thin category copy, and no internal linking. All three were fixable on the original platform in a fortnight.
I establish what the platform actually prevents before recommending a move. Very few genuine SEO problems are platform problems.
A migration carries redirect risk, template risk, and a rankings dip that is normal and still frightening. Spending that risk on a problem the old platform could have solved is the expensive error.
Four Things Commonly Assumed About Platforms
Do you know what your platform actually prevents, rather than what you have been told about it?
Ivan Sp meets these four assumptions whenever a migration is proposed for SEO reasons.
| Commonly assumed | What actually holds |
|---|---|
| Some platforms are simply better for SEO. | Platform choice decides which fixes are cheap. Google has stated that sites on hosted platforms rank perfectly well. |
| Migrating to WordPress solves platform limitations. | A migration carries redirect risk and a temporary ranking dip. Most genuine SEO problems are not platform problems. |
| Hosted platforms give you no SEO control. | Titles, descriptions, headings, slugs, redirects, and structured data are editable on all four platforms covered here. |
| No raw logs means no technical SEO. | Log access changes verification rather than delivery. Crawls and Search Console cover the same ground more slowly. |
| A platform’s reputation reflects its current version. | Most platform criticism describes behaviour that was retired years ago. The current product needs auditing on its own terms. |
A migration undertaken to fix thin content will spend your budget and your risk, then deliver the same thin content on a new stack.
What Each Platform Controls
- WordPress
- Full file and database access, so nearly any technical change is possible.
- Shopify
- Fixed URL prefixes for products, collections, and pages. Liquid templates are editable.
- Squarespace
- Editable slugs and code injection, with no server access and no raw logs.
- Wix
- Editable robots.txt, canonicals, redirects, and structured data, with no server access.
- Common to all four
- Title tags, meta descriptions, headings, internal links, and content.
- Available only with server access
- Raw log file analysis, X-Robots-Tag headers, and server-level redirects.
- What never transfers
- A recommendation written without checking what the platform permits.
A Worked Example: One Fix, Four Platforms
Consider the same recommendation given to four sites: consolidate duplicate product URLs. The comparison below is illustrative, written to show how cost varies. No client engagement is described here.
| Platform | How the fix is delivered | Relative effort |
|---|---|---|
| WordPress | Template edit plus a server-level redirect rule | Low |
| Shopify | Liquid template canonical, since the URL prefixes cannot be changed | Low |
| Squarespace | URL mappings in the built-in redirect manager | Low |
| Wix | Redirect manager plus canonical settings in the SEO panel | Low |
| Any of the four, without log access | Verification by crawl and Search Console instead of logs | Adds a week |
I write the recommendation against the platform rather than against a general principle. The last row is the real difference, and it changes verification rather than the fix.
Platform constraints are like the plumbing in a building. The kitchen can go almost anywhere, and where the pipes already run decides what it costs.
Three of these platforms have no raw logs at all. The absence blocks no fix, and it changes how each fix gets confirmed.
How Platform Work Is Approached
I establish the constraint set before writing a single recommendation.
- Identify the platform and its version, since major versions differ in what they permit.
- List which URL segments are fixed by the platform and which are editable.
- Check whether robots.txt is editable, generated, or partially controllable.
- Check whether redirects are available, and whether they are server-level or application-level.
- Confirm whether raw access logs exist, since three of the four platforms do not expose them.
- Establish how structured data is injected, whether by theme, app, plugin, or a built-in panel.
- Test one small change end to end before planning a template-wide rollout.
- Write every recommendation as a platform-specific instruction rather than a general principle.
- Verify with a crawl and Search Console where log verification is unavailable.
- Record the constraint set, so future work does not rediscover the same limits.
How This Engagement Is Scoped
I scope platform work against the constraint set rather than against page count.
- What arrives
- A documented constraint set, plus recommendations written as platform-specific instructions.
- Typical duration
- One week for the constraint audit, then as scoped for the work itself.
- What the client supplies
- Admin access to the platform, and theme or template edit permission.
- Included
- Constraint audit, platform-specific recommendations, and a tested example change.
- Not included
- Platform migration, theme development, and paid app or plugin licences.
- What changes the estimate
- A heavily customised theme, several apps injecting markup, or a headless front end.
- How it is quoted
- After a short scoping call, once the platform and version are confirmed.
Tools and Primary Sources
The references below are each platform’s own documentation. Each opens in a new tab.
- WordPress developer documentation documents post types, hooks, and the template behaviour SEO plugins depend on.
- Shopify SEO documentation sets out which URL structures are fixed and which files are editable.
- Squarespace SEO documentation covers slug editing, URL mappings, and code injection.
- Wix SEO documentation documents the SEO panel, robots.txt editing, and redirect management.
- Google guidance on site moves sets out what a platform migration actually requires to avoid losing rankings.
Establish Your Own Constraints
I suggest four checks that map what your platform will and will not allow.
- Try to edit the URL slug of one product or service page, and note whether the prefix is fixed.
- Open your platform’s SEO settings and check whether robots.txt is editable.
- Look for a redirect manager, and note whether it handles wildcards or only single URLs.
- Ask your host or platform whether raw access logs are available for download.
A fixed URL prefix and no raw logs are the two constraints that change the most advice. Neither prevents good SEO, and both change how the work is done and verified.
Common Questions
Does moving to a different platform improve SEO on its own?
No. A migration changes which fixes are cheap, and it carries redirect risk plus a temporary ranking dip. Google’s own site move guidance treats a platform change as a project to survive rather than as an optimisation.
Discuss a Platform-Specific Audit
An audit gets scoped around the platform in question from the first call, so recommendations stay realistic from the start. The first call is a free 30-minute consultation with no pitch attached.