Image SEO on Squarespace, Wix and Webflow: What You Can Actually Control

Hosted site builders occupy an awkward position in image SEO advice. Most guidance assumes a self-hosted stack where you control the file, the URL, the markup and the delivery — and then gets applied, unmodified, to platforms where you control roughly half of that. The result is a lot of effort spent on levers that are not connected to anything.

The useful framing is not "how do I do image SEO on Squarespace" but "what does this platform decide for me, and what is left". Answering that takes about ten minutes per site and makes every subsequent decision obvious.

What the platform decides, and what you keep

Decision	Typically the platform's	Typically yours
Compression level	Yes	Rarely
Output format (WebP conversion)	Yes	Rarely
Responsive variants and srcset	Yes	No
Served URL and filename	Varies by platform	Sometimes, via the upload name
Lazy loading behaviour	Yes	Occasionally, per block
Alt text	No	Yes
Which image goes on which page	No	Yes
Surrounding copy and captions	No	Yes
Embedded file metadata	Usually stripped	Only if it survives

Read the right-hand column: the things you keep are the things that carry meaning. The things the platform takes are the things that are mechanical. That is not a bad trade — automatic compression and responsive delivery are precisely where self-hosted sites accumulate their worst technical debt — but it does mean that time spent trying to reclaim the left column is usually wasted.

The ten-minute diagnostic that answers everything

Rather than trusting any guide, including this one, on what your platform does — platforms change, and behaviour varies by plan — run this on your own live site.

1. Upload a distinctively named test image. Name it something no CDN would generate: zebra-test-image-diagnostic.jpg. Put it on a published page.

2. View the rendered page source and find the <img> tag. Not the editor — the published page, viewed as a visitor. Look at the src value.

• If it contains zebra-test-image-diagnostic, filenames survive. Name every file carefully from now on; it is one of the few textual signals attached to an image, and the rules for writing filenames that help apply exactly as they would anywhere.
• If it contains a hash or an opaque identifier, filenames do not survive. Stop optimising them and redirect that effort to alt text and captions.

3. Check the alt attribute in the same tag. Present and populated, or empty? Do this on a gallery block and a background image as well as a plain image — coverage usually differs by block type.

4. Check the format and dimensions actually served. Your browser's network panel shows the response type and the transferred size. If the platform is serving WebP at a sensible size without you asking, that is one whole category of work you do not need to do.

5. Download the published file and inspect its metadata. If the copyright, description and coordinate fields you wrote before upload are gone, the pipeline strips metadata and there is no point writing it for that platform.

6. Open the platform's published sitemap and search for an image URL to see whether images are included.

Six checks, one test image, and you now know which of the standard recommendations apply to you.

Squarespace, Wix and Webflow in general terms

Each of the three occupies a slightly different point on the control spectrum, and the differences are consistent enough to be worth naming even though specifics change.

Squarespace is the most opinionated: it processes and serves images through its own pipeline with automatic variants, and the editorial experience is built around blocks rather than raw markup. Alt text is available, and the recurring gap is gallery and background blocks where the field is easy to bypass.

Wix is similarly integrated, with a heavily processed asset pipeline and its own media CDN. Its interface exposes alt text clearly on standard image elements; as with Squarespace, decorative and background usage is where coverage slips.

Webflow sits closest to a self-hosted stack. You work with actual elements and classes, so the markup you build is broadly the markup that ships, and asset delivery is handled for you. This makes it the easiest of the three to reason about and the easiest to get wrong, since nothing prevents you from placing a 4,000-pixel-wide asset into a 400-pixel slot.

Do not take any of that as settled specification. Run the diagnostic; it takes less time than reading a changelog.

The four things that matter on every platform

Whatever the diagnostic returns, these do not change.

Relevance. An image that shows the thing the page is about outperforms a better-optimised image that shows a generic abstraction. This is not a search-engine subtlety; it is why the page has an image at all.

Alt text that describes the image. Written for a person using a screen reader, not for a keyword allocation. The judgement call people most often get wrong is when to leave it empty — decorative images should have alt="", not a keyword — and the rule for deciding takes about a minute to internalise.

Text near the image. Captions, headings and body copy adjacent to an image are how a search engine understands what it depicts. On builders that discard filenames this is the substitute signal, and it is a better one anyway.

Dimensions matched to the slot. Platforms compress, but they cannot decide that a hero image is three times larger than the space it occupies. On a template where the hero is the largest element, that choice determines the page's Largest Contentful Paint, which is a real user-experience metric rather than a theoretical one.

The metadata question, resolved

Most hosted builders strip embedded metadata during processing. That has a direct consequence for anyone using it deliberately: attribution, copyright strings and geo-coordinates written into files may not survive the upload.

This is not a reason to skip writing them. Two reasons:

Your originals keep it. A generated or shot image with correct copyright and description fields is a properly attributed asset in your own library, regardless of what the website's CDN serves. That matters when the file is reused in print, in ads, in a client handover, or when someone asks who owns it.

Not every distribution channel strips it. Direct downloads, email attachments, files shared with partners and assets handed to a client all preserve what the CMS discards.

What it does mean is that you should not expect embedded coordinates to influence a hosted site's local rankings, which is a fair expectation to give up — the honest assessment of what geo-tagging achieves already sets that bar low even where the metadata does survive.

Migrating between platforms without losing image traffic

The moment hosted-builder image decisions become expensive is a platform move, because every image URL changes at once. Each platform serves from its own asset host with its own path structure, so nothing carries over.

What that costs depends on whether the images were earning anything. If Search Console's Image search type shows meaningful impressions, those are attached to specific URLs that are about to stop existing. If it shows nothing, the migration costs you nothing on this axis and you can skip the rest of this section.

Where there is something to protect, three measures:

Inventory before you move. Export the image URLs currently earning impressions, and the pages they sit on. This takes ten minutes and is impossible to reconstruct afterwards.

Redirect the page, not just the image. You usually cannot redirect an old CDN asset path on a hosted platform, and that is generally acceptable — what matters most is that the page containing the image keeps its URL or redirects properly. An image on a page that still resolves gets re-crawled and re-associated; an image on a page that 404s loses both.

Re-upload with the names you want. A migration is the one occasion where renaming files costs nothing, because the URLs are changing regardless. If the destination platform preserves filenames, this is the cheapest opportunity you will ever get to fix a library full of camera defaults.

Expect image impressions to dip for several weeks after any migration and to recover as the new URLs are crawled. A dip that does not recover after a couple of months is a discovery problem worth investigating rather than an inevitability.

What actually differs from WordPress

For anyone weighing the comparison: WordPress gives you filename control, metadata retention (unless a plugin strips it), and total freedom to construct markup badly. The plugin ecosystem around WordPress image SEO exists largely to automate what hosted builders simply do for you.

The practical difference is not capability but failure mode. WordPress sites fail by omission — no compression, no responsive variants, 3MB hero images. Hosted builder sites fail by ceiling — everything mechanical is handled, and the descriptive work nobody automated is missing.

Which failure you are experiencing determines what to do next, and it is knowable in ten minutes.

Your actual to-do list on a hosted builder

1. Run the six-step diagnostic once, and write down the answers.
2. Fix alt text coverage everywhere, especially galleries and any image set as a background.
3. If filenames survive, rename files before upload — permanently, as a habit.
4. Right-size images before upload; the platform compresses but does not re-crop your judgement.
5. Write real captions and surrounding copy for images that carry meaning.
6. Stop worrying about compression, formats and srcset. That is what you are paying the platform for.

The last line is the one that saves the most time. If images on your site are genuinely absent from Google Images, the cause is nearly always discovery or duplication rather than delivery — work through the indexing causes in order before assuming the platform is at fault.

SEOpix produces images with descriptive filenames and metadata already written in, so the naming half is done before upload regardless of what your builder does with the file afterwards. See the plans, or read the FAQ for what lands in each file.