Wix and Squarespace SEO: where the platform stops helping

When a business hands us a site built on Wix or Squarespace, the first thing we do is go through the search settings. And they're almost always fine. Titles written, descriptions written, alt text present more often than not, sitemap generating, HTTPS on, redirects in place from the last time someone changed a page name.

That surprised me the first few times. The received wisdom is that these platforms are bad at SEO, and if that were still true you'd expect the settings panel to be empty or missing. It isn't. Both platforms have spent years closing that gap, and the version of the complaint that was fair in about 2016 isn't the one to repeat now.

So the ceiling is real, but it isn't where most people point. Here's where we actually run into it.

Weight you can't take off

The clearest limit is speed on a phone, and it's a limit of a particular kind: you can't remove what you didn't add.

A builder template arrives carrying the machinery that makes the editor work. Animation libraries, layout scripts, font loading, the drag-and-drop plumbing. Most of it runs whether your page uses it or not, and none of it is yours to delete. You can compress your images and trim your sections and you should, but there's a floor underneath that, and on a mid-range Android phone on patchy reception that floor is where a lot of sites sit.

Google's Core Web Vitals are the measurement, and they're not the deciding factor in ranking that people sometimes claim. They matter more for the person deciding whether to wait, which we went through in what a slow site costs you. Either way, if the slow part of your page is the template rather than your content, you've found something you can't fix from inside the platform.

Addresses that don't want to move

Builders make some decisions early and hold onto them. Collection and blog URLs tend to sit under a fixed prefix. Changing a page's address later is possible on both platforms, but it comes with the usual cost of moving anything on the web, and the tooling for handling that at scale is thinner than it looks.

For a fifteen page business site this never comes up. For a site trying to build out service pages crossed with locations, where you want a structure that reads sensibly and links properly, it becomes a daily irritation. The structure ends up shaped by what the platform allows rather than what your business actually sells, and that's the sort of constraint you only notice a year in.

Markup beyond the built-in types

Both platforms output structured data for the obvious things: articles, products, events, local business details. That covers most of what most sites need.

Past that you're relying on code injection, which is supported but sits outside the editor, and which nobody else in the business can maintain. We've picked up a couple of sites where a previous developer had bolted extra markup on that way, and it had drifted out of sync with the visible page months earlier. Markup that contradicts the page is worse than no markup. Google's guidance on JavaScript and search is the polite version of the same point: anything injected after the fact is one more thing that has to survive a render.

The labour of many similar pages

This is the one that decides it for most of the businesses we work with.

If your search strategy needs forty pages that share a structure but differ in content, a builder makes you assemble each one by hand in a visual editor. It's not that you can't. It's that you won't, not consistently, not at eleven at night, and the pages that don't get made are the ones that would have earned the enquiries.

On a custom build those pages come from content files with a shared layout, so making the forty-first is a five minute job. That difference sounds technical and is entirely practical: it changes how much you actually publish.

When the builder is the right answer

Plenty of times, honestly.

If you've got a handful of pages, you're not fighting anyone for search traffic, most of your work comes through referrals or your Google Business Profile, and you want to change your own opening hours on a Sunday, a builder does that job well and you should keep it. Moving off one costs money and time, and if search isn't where your customers come from, you'd be buying something you don't need. We've told people exactly that and left them where they were.

What tips the balance is usually one of three things. Search has become a real channel and you're stuck behind competitors who publish more. The site has grown past what the editor handles comfortably. Or the mobile speed has become embarrassing enough that you can feel it in the enquiry numbers.

Two things people blame on the platform that aren't the platform

Not being in Google at all is almost never a builder limitation. It's usually a setting or a page that never earned its place, which is the whole of that other post and worth ruling out before you conclude anything about your platform.

And thin content is thin content anywhere. Moving five short pages onto a faster stack gives you five short pages that load quickly. The rebuild raises your ceiling, it doesn't write your service pages for you, and anyone selling it as a ranking fix on its own is overpromising.

This week

Take the page that brings you the most enquiries, run it through PageSpeed Insights on the mobile setting, and look at what's actually loading. If the heavy items are your photos and your text, that's yours to fix and you can do it inside the platform this afternoon. If the bulk of it is scripts you never chose, that's the ceiling, and now you know where it sits.

If you'd rather have someone go through it properly, what a site audit covers explains the full check, and we'll do one for free whatever you're built on.