What Website Builders Do to Your URLs

URL structure is the one technical decision on a hosted builder that you make exactly once and then live with for the life of the site. Everything else can be revisited — you can rewrite a title, change a description, redo a schema block. Addresses are different, because by the time you want to change them other people have linked to them, and the cost of the change is the sum of all those links.

Which makes it odd that URL structure is the thing builders explain least. The forced segments are rarely mentioned during signup. You discover them the first time you publish something and look at the address bar.

The three layers, and who controls each

Every builder's URL handling breaks into three layers, and confusing them is what makes this topic feel messier than it is.

The domain is yours everywhere. No hosted builder in ordinary use prevents you from putting a site on a custom domain, and the ones that do are free tiers signalling that they are free tiers.

The slug — the last segment, the bit that names the page — is editable on every platform covered here. This is the layer people think URL control means, and it is the layer that is never really in dispute.

The path — everything between the domain and the slug — is where the actual variation lives. Whether your blog post sits at /thing/, /blog/thing/ or /post/thing/ is usually not your decision, and on several platforms it is not a decision at all.

The forced segments, platform by platform

Wix appends a /post/ segment to blog post URLs and documents that it cannot be removed. Every article you publish will carry it. That is a permanent characteristic of the site, decided the day you chose the platform.

Squarespace derives paths from collections. A blog post lives under its blog collection's URL, a product under its shop's, an event under its events page's. You can rename the collection, which changes the segment, but you cannot lift an item out of its collection's path — the hierarchy is how the content model works rather than a setting layered on top of it.

Shopify is the most opinionated of the set. Products live at /products/<handle>, collections at /collections/<handle>, blog posts under /blogs/<blog>/<article>, pages at /pages/<handle>. None of those prefixes is removable, and the same product is additionally reachable at /collections/<collection>/products/<handle> whenever it sits inside a collection. Shopify canonicalises those variants back to the /products/ form, which is the correct behaviour — but a canonical is a recommendation, and the alternative paths stay crawlable.

Webflow and Duda are the outliers. Both let you decide the structure. Webflow's static pages sit wherever you put them and CMS collections take a slug prefix you configure; Duda's page paths are similarly yours. This is the practical difference between a builder and a design tool that happens to host, and it is one of the reasons those two sit at the top of the seven-builder control audit.

GoDaddy's builder exposes less and documents less. Independent testers have reported a behaviour worth knowing about before you commit: that changing a page's title can cause the builder to regenerate that page's URL, which breaks any link already pointing at it. That report comes from third-party testing rather than from GoDaddy, so treat it as a flag to verify on your own site rather than a settled fact — but verify it, because an address that changes itself is a category of problem most platforms do not have.

Does any of this actually affect rankings?

Directly, barely at all, and anyone telling you /post/ is costing you traffic is inventing a mechanism. Google's guidance on URL structure is about crawlability and human legibility, not about keyword placement in a path. A descriptive slug helps a person decide whether to click a result. That is most of the benefit and it is a real one.

Indirectly, the structure matters a great deal, for a reason that has nothing to do with the algorithm. URL structure determines how expensive it is to reorganise your site. If your blog is at /blog/, moving an article between categories is free. If your platform bakes the category into the path, the same move is a redirect — and if your platform has no redirect manager, the same move is a broken link. Structure is not a ranking factor. It is a constraint on your future options, which is quietly more consequential.

Slug rules nobody documents

A handful of behaviours that surprise people, none of which are in anybody's marketing copy.

Most builders generate the slug from the page title at creation and then stop syncing. Rename the page afterwards and the slug usually stays as it was — which is the safe behaviour, and the opposite of what people expect.

Uppercase characters and spaces get normalised, usually to lowercase and hyphens, but the normalisation happens at save time and is not always reversible if you then edit by hand.

Trailing-slash behaviour is set by the platform and is not configurable anywhere in this category. It does not matter, provided the platform is internally consistent and canonicalises one form to the other — all the hosted builders here are.

Non-Latin characters are usually accepted and percent-encoded, which works fine and looks alarming when pasted into a spreadsheet.

What to decide before you publish anything

Three decisions, all cheap now and expensive later.

Decide the top-level shape first — the handful of sections everything will live under — and accept that on Squarespace and Shopify this is a content-model decision rather than a URL decision, so it has to be made in the right place.

Write the slugs by hand for anything that matters. Auto-generated slugs from long titles produce addresses with seven words and a date in them, and they are ugly forever.

Find out, before you commit, whether the platform can redirect. That single capability is what converts every URL decision from permanent to revisable, and it is covered in the note on redirect managers. A platform with good redirects forgives a bad structure. A platform without them does not forgive anything.

If the structure is already wrong

Most people arrive at this subject after the fact, with a site whose addresses they dislike. The honest advice is to leave them alone unless a specific thing is broken.

Changing a URL costs you whatever links point at it, and buys you an address that reads slightly better. That trade is rarely worth taking on its own. It becomes worth taking when the current address is actively misleading — a page about one service sitting at the slug of a service you no longer offer — or when you are consolidating two pages into one anyway and the URL change comes free with a redirect you were going to write regardless.

When you do change one, do it once. Write the redirect at the moment you change the slug, not the following week. Check the old address in a private browser window rather than the tab you have been working in, because a cached response is the most common reason somebody believes a redirect works when it does not. And update your own internal links to point at the new address directly, so that visitors are not routed through a hop that exists only because you did not finish the job.

The one structural decision that outlives everything

If you take a single thing from this: decide the top-level sections before you publish anything, and make them broad enough to survive a change of business.

Sections named after what you sell today become wrong the first time the offering shifts, and then you are choosing between a misleading structure and a restructure. Sections named after what a visitor is trying to do tend to survive, because the things people come to a site to do change far more slowly than the things a company sells. This is not an SEO tactic. It is the reason some sites can be reorganised in an afternoon and others cannot be reorganised at all.