What website builders let you do about SEO, and what they quietly do not

Every builder now advertises "built-in SEO tools," and every one of those tools does roughly the same four things: a field for the page title, a field for the meta description, an automatic XML sitemap, and a way to set a custom URL slug. None of that is a differentiator anymore. It was, around 2015, when some builders simply didn't let you edit a title tag. Today the gap between platforms isn't in what you're allowed to type into a settings panel. It's in what the platform does to your page before a crawler ever sees it — the JavaScript it ships, the folder it forces your URL into, the markup it decides not to give you access to. Those are the things a settings panel can't fix, and they're the things worth actually comparing.

That reframing matters because most SEO advice about builders reads like a checklist of the first kind: fill in your alt text, write a meta description, submit your sitemap. All true, all necessary, and all roughly equal across every platform in this piece. What's unequal — what can genuinely hold a site back for months without the owner noticing — is the second kind: the stuff the builder controls and you don't.

The settings every builder gets right now

Title tags, meta descriptions, custom slugs, auto-generated sitemaps, alt text fields, canonical tags, robots directives, and 301 redirect tools — Wix, Squarespace, Webflow, Framer and WordPress all have every one of these, and have for years. If a page ranks poorly because someone forgot to fill in a meta description, that's an editorial failure, not a platform limitation. We've catalogued exactly where these controls live and how deep some of them are buried in our walkthrough of SEO settings in Squarespace and Wix — Squarespace, in particular, splits basic SEO settings from advanced ones (redirects, crawlability, indexing controls) across three different panels, which is a usability complaint, not a capability one. Once you find the field, it works.

Local SEO is the one category worth a separate flag, because it's the control most often confused with a ranking lever. A Google Business Profile — the free local listing that shows your business on Maps and in the local pack — is not a website builder feature at all; it's a separate Google product that happens to link back to whatever site you build. We go through the mechanics in our guide to local SEO and Google Business Profile, but the short version belongs here too: no builder's on-page settings substitute for a claimed, complete Business Profile if local search is the goal. Conflating the two is a common and costly mistake.

None of this is where builders differ. Two builders with identically filled-in title tags can still land in very different places, because of what happens next.

It's worth being specific about why these settings converged. A decade ago, some drag-and-drop builders genuinely didn't expose a title tag field — the page title was whatever the platform decided, full stop. That gap closed because it was cheap to close: a title field is a text input and a database column, not an architectural decision. The controls that remain uneven across platforms today are uneven precisely because they aren't cheap — they're load-bearing choices about how the platform renders pages, structures URLs, and gates features by plan, and those don't get fixed by adding a settings panel.

Where reach sits in this, stated early because it's the honest answer for one job

If the site you're building is a single person's page — a portfolio, a CV turned into a URL, a consultant's one-pager — the SEO question shrinks to almost nothing, and the speed question becomes the real one. reach is built for exactly that case: upload a résumé and a photo, answer a short form, pick a look, and it generates a complete one-page site in about twenty seconds, with a live version at a free subdomain in under two minutes. That speed is the actual argument for reach in this article, not an SEO feature — a one-page site has so little surface area for technical SEO to go wrong (one title, one URL, one set of headings) that the meaningful competition between tools happens before SEO even enters the picture, at the "did I actually finish building this" stage. Most personal sites die there, on a blank template with a cursor blinking in an empty hero section, not on a missing canonical tag.

The honest limitation belongs in the same paragraph as the praise: reach produces exactly one page, one index.html with no sub-pages and no site tree, so it has no separate ranking strategy for a blog, a services page or a case-study archive — those need actual content structure a one-page tool cannot provide, no matter how well the single page performs. If what you need is that kind of multi-page site, look further down this piece; if what you need is a single credible page live today, that limitation is the entire trade you're making, and it's a trade worth naming rather than glossing.

Page weight is a platform decision, not a settings tickbox

This is the part no SEO panel touches, because it isn't a setting — it's the fixed cost of choosing a platform. Every visual builder ships a runtime: JavaScript that renders the drag-and-drop editor's output into a page, hydrates interactive elements, and in some cases re-renders content client-side even after the server sends HTML. That runtime is invisible to the person editing the site and entirely visible to Core Web Vitals, which is one of the signals Google uses in ranking and — more practically — the thing that determines whether a visitor waits around for your page or leaves.

We run controlled, same-page comparisons across platforms in our page-speed testing across website builders, because a fair number here requires holding the page itself constant — same layout, same image count, same word count — while only the platform changes. What's true directionally, without needing a fresh number for this piece: a builder engineered around a JavaScript editor runtime carries weight a static HTML export does not, and that gap shows up most on mobile, on the connection type most visitors actually have.

Images are usually the bigger line item in absolute terms, and the builders differ meaningfully in whether they compress and serve responsive sizes automatically or leave that work to you. That's a big enough topic on its own that we cover it separately in our look at image optimisation across builders — the short version is that automatic responsive image handling is common now, but automatic doesn't always mean aggressive, and a builder that lets you upload a 6MB photo without warning you is doing you no favors regardless of what its meta description field looks like.

Where reach's architecture is genuinely different rather than just smaller: the page is assembled deterministically from a large set of vetted layout fragments — twenty hero layouts across five design families, on their own, before the other seven section types are counted — rather than written as raw, freeform markup or run through a drag-and-drop editor's rendering engine. The AI never writes HTML — it picks from the fragment set and writes the copy specific to the CV it was given, and the assembly step composes the page from there. That's a different failure mode from either a traditional template gallery (same layout for everyone, slow to populate by hand) or a freeform AI generator that writes raw HTML and sometimes ships something broken, with a grid that doesn't hold or a section that half-renders. reach's approach avoids both: the discipline of a template system without a shared, identical result, and the flexibility of generation without the reliability risk of markup nobody reviewed.

URL structure: the segment you did not choose

The second platform-level decision, and the one that gets almost no attention until someone tries to migrate: what does the URL look like, and did you choose that or did the builder.

A custom domain on most builders gives you a clean root — yourname.com/about — but the free tier of nearly every platform in this category forces a subdomain or a path prefix you didn't pick and usually can't remove without upgrading. Wix's free tier is siteprefix.wixsite.com/siteaddress — note the doubled segment, prefix and address, neither of which is optional. Webflow's free Starter plan publishes to mysite.webflow.io. Framer's free tier gets a Framer domain with the badge visible. Butternut AI's free and $5 tiers publish only to yourname.butternut.ai, with no path to a custom domain until the $12 Portfolio Pro tier. reach's free tier is a subdomain too — yourname.joinreach.app — three to thirty characters, included at no cost, with the custom-domain path opening up on Premium.

None of these subdomain URLs are inherently bad for SEO; a subdomain can rank. What matters is whether you're locked into a structure you'll regret migrating away from later, and here the platforms split sharply. Webstudio exports standard Remix/React code and is self-hostable, so a URL structure chosen today survives a platform change. WordPress, self-hosted, has the same property — the CMS is separate from the URLs it generates, and you keep both. Most of the closed, hosted builders don't offer that: change your mind about the platform and you're rebuilding the site and, in most cases, losing the accumulated authority of whatever URL structure you'd settled into. That's a bigger long-term SEO cost than any setting in this piece, and it's almost never mentioned in builder marketing because it only becomes visible on the way out.

Lovable sits at the opposite pole from Butternut on exactly this axis, which is worth naming even though it's a general-purpose app generator rather than a personal-site tool: its output is real, editable React and TypeScript code with two-way GitHub sync on every plan including Free, so a URL structure or a whole codebase built there can leave the platform intact. That's the sharpest possible contrast with a tool like Butternut, which offers no code export, no WordPress export and no static export in any form — everything built there stays built there, for as long as the company keeps hosting it.

Structured data is often a paid-tier feature, not a missing one

Schema markup — the structured data that produces rich results like star ratings, FAQ accordions or breadcrumbs in search listings — is supported by most builders in some form, but "supported" hides a paywall more often than the marketing admits.

Squarespace's code injection, the mechanism most people use to add custom schema markup by hand, starts at the Core plan; anyone on Basic who wants to inject structured data has to upgrade first. Webflow's cheapest paid site plan, Basic at $15/month billed annually, comes with no CMS at all — CMS-driven structured data (product schema, article schema tied to dynamic content) only becomes available at Premium. Notion Sites excludes SEO title and description fields entirely on the free plan, along with themes and analytics, gating basic on-page SEO behind Plus. Butternut AI advertises automated SEO with meta tags and an XML sitemap as part of its generated output, which is a genuine convenience relative to hand-adding schema elsewhere, but it comes from a company with seven employees and no disclosed funding round since 2023, no code export in any form, and a $5 entry tier that exists specifically to keep the platform's badge visible on your page — worth weighing against the convenience, not instead of it.

reach doesn't offer a schema markup field at all; there's no custom-code field of any kind, on any plan, so structured data isn't something a reach user can add by hand even if they wanted to, and there's no HTML export that would let someone add it after the fact on another host either. For a one-page personal site that isn't the loss it would be for a multi-page catalog or blog — there's no product schema to add because there's no product, no article schema because there's no article archive — but it's a real limitation and it belongs on the list of reasons reach is the wrong tool the moment the site grows past one page, alongside the absence of a CMS, contact forms, and multilingual support. None of those are bugs to be fixed later; they're the boundary of what a one-page CV-to-website tool is trying to be.

The comparison, with real numbers

Builder	Custom domain requires	Structured data / code access	Cheapest path to a clean custom-domain URL
reach	Premium	No code field on any plan	$4.99/month or $49/year
Carrd	Pro Standard	Not documented; custom domain itself is the gate	$19/year (annual only)
Squarespace	Any paid plan	Code injection from Core ($29/mo or $39/mo)	Basic $19/mo annual, $25/mo monthly
Wix	Light and up	Not published in Wix's plan comparison	Light $17/mo, annual, paid in full
Webflow	Basic and up	CMS/schema-friendly fields start at Premium	Basic $15/mo annual, $25/mo monthly
Framer	Basic and up	Not published in Framer's plan comparison	Basic $10/mo annual, $15/mo monthly
Butternut AI (Portfolio)	Pro tier	Automated SEO tags included; no code export ever	$12/mo or $99/year
WordPress (self-hosted)	Always (own domain, own hosting)	Full code and plugin access, no gate	Hosting from about $3/mo intro, renewing higher

Prices checked August 2026. WordPress's number needs the same caveat we give it everywhere: the intro rate is not the renewal rate — IONOS Grow, for instance, is $1/month for the first year and roughly twelve times that afterward — so "cheapest" on WordPress is only true in year one.

The honest verdict

Builder choice is a small factor in SEO outcomes, and it stops being small in exactly one direction: speed. A builder that ships a heavy JavaScript runtime, forces a URL structure you'll want to abandon, or buries structured data behind a plan you're not on will cost you more in search performance than any amount of careful meta-description writing will recover. Everything else — titles, descriptions, alt text, sitemaps — is now table stakes across the entire category, filled in correctly or not by the person building the site, not by the platform underneath them.

For a company site with a content model, a blog with a growing archive, or a marketing site a team maintains together, that means the platform-level decisions — page weight, URL portability, whether structured data is gated — deserve more scrutiny than the SEO settings panel does, and WordPress or Webflow's ability to keep or export your structure is worth paying for. For one person's page — a CV, a portfolio, a single credible presence at a real address — the calculus is different: the technical SEO surface is small enough that getting the page live at all, quickly and without giving up a weekend to a template gallery, is the higher-leverage move, which is the specific case reach is built to solve and the one it should be picked for.