Redirect Managers in Website Builders, Compared

If you get one capability check right before choosing a hosted builder, make it this one. A redirect manager is what turns every other decision on your site from permanent into revisable. Without one, the first URL you name badly is named badly forever, and the first restructure you attempt sheds every inbound link to every page that moved.

It is also the capability with the widest spread across this category. Four platforms here ship tooling a developer would recognise. One ships something workable with a catch. Two do not document the capability at all. That spread is wider than the spread on any other control in the seven-builder control audit, and it is why redirects carry so much weight in that scoring.

What a redirect manager needs to do

Four things, and it is worth naming them before comparing products, because "supports redirects" covers a wide range of usefulness.

It needs to issue a real 301 — a permanent redirect — rather than a meta refresh or a JavaScript hop. It needs to accept rules in bulk, because restructures are never one page. It needs to catch chains and loops, since a redirect pointing at a redirect pointing at the first one is a self-inflicted outage. And it needs to survive the thing that caused it: deleting a page should not silently delete the rule that was covering the page's old address.

The platforms with real tooling

Webflow handles 301 and 302 internally from site settings, by hand or by CSV upload, with no server configuration and no external service. It is the developer-grade implementation in this set, and it is one of the two reasons Webflow scores where it does.

Duda does the same — 301 and 302, native, bulk CSV — and adds a behaviour nobody else in this comparison offers: it raises an alert when a change you have just made to the site probably warrants a redirect. Most builders let you break a URL in complete silence and leave you to notice weeks later in a crawl report. Being told at the moment of breakage is worth more than any bulk-import feature.

Wix ships a URL Redirect Manager in the dashboard under Marketing & SEO. It handles 301s, accepts bulk imports rather than demanding one rule at a time, and checks submitted rules for errors and loops before they take effect. That loop check is the part that matters; it is the difference between a redirect feature and a redirect text box.

Shopify has URL Redirects in the admin with CSV import. For a catalogue that is constantly gaining and losing products, this is not optional tooling and Shopify treats it accordingly — it is one of the least caveated parts of Shopify's whole SEO surface.

Squarespace: one text box, one precondition

Squarespace handles all redirects through URL Mappings, in Settings → Advanced. It is a plain text field taking lines in the form /old-path -> /new-path 301. You can paste many lines at once, which makes a large restructure tolerable, and the syntax is simple enough to generate from a spreadsheet formula.

Then there is the precondition, and it catches practically everyone the first time. The redirect only works once the old URL no longer exists. You have to delete the old page, disable it, or change its URL before the rule does anything. A mapping that points away from a page still live on the site does nothing at all, and Squarespace does not raise an error to tell you so — the rule sits there looking correct while the old page keeps serving.

The sequence that works is therefore: change or remove the old page first, then add the mapping, then test the old address in a private browser window. Testing in the window you built the site in is how people convince themselves a redirect works when it does not. There is no .htaccess here, no server configuration, and no plug-in that extends any of this. URL Mappings is not the easiest route on Squarespace; it is the only one.

The platforms that do not document it

Neither Hostinger's website builder nor GoDaddy's builder documents redirect management anywhere this desk could find. That is recorded as not documented rather than absent, and the distinction is real — it is entirely possible a control exists and is simply unwritten.

Practically, though, plan as if it is not there. If a capability cannot be found in a vendor's own documentation, you cannot rely on it being there when you need it, and you certainly cannot build a restructure plan around it. The common workaround people reach for is putting the site behind a proxy or CDN that can issue redirects at the edge, which works and which is a strange amount of infrastructure to bolt onto a product bought for its simplicity.

The rules that stop redirects being useful

Three failure modes account for most of the trouble, and all three are self-inflicted.

Chains. Page A redirects to B, B later redirects to C. It resolves, but every hop is latency and every hop is a chance for one link in the chain to be deleted. When you move a page a second time, update the original rule rather than adding a second one.

Redirecting everything to the homepage. The standard move when a page is retired, and the wrong one. A redirect says this content is now here. Pointing forty retired product pages at the homepage tells a search engine forty times that the homepage is not what the person asked for. Redirect to the closest genuine equivalent, or let the page return a clean 404, which is an honest answer and not a problem.

Forgetting the non-obvious variants. The old address may exist with and without a trailing slash, with tracking parameters attached, and in an uppercase form somebody typed into a print advert. Check each variant after the restructure.

How to test one properly

A redirect that has not been tested from outside the session you built it in has not been tested. Three steps, in this order.

Open the old address in a private browser window, or a different browser entirely. The window you built the site in holds cached responses and a logged-in session, and both will lie to you.

Confirm you land on the new address and that the address bar shows the new address rather than the old one still displaying new content. A rule that serves the new page at the old URL is not a redirect — it is a duplicate, and it is the failure mode that produces two indexed copies of one page.

Then check the status code rather than trusting the browser, using any of the free header-checking tools. You are looking for a single 301, not a 302, and not a 301 followed by another 301. A permanent redirect tells a search engine to transfer its understanding of the old address; a temporary one tells it to keep the old address and check back later, which is not what you meant if the old page is gone for good.

Keep the map

Whatever platform you are on, keep a plain spreadsheet of every redirect you have ever created: old address, new address, the date, and one line saying why. Nothing in this category is auditable from inside the products — none of the builders here will show you a tidy history of what was changed and when — and the map is the only artefact that survives a change of person maintaining the site. It costs a minute per rule and it is the single most useful document a small site can keep about itself.

The five-minute check before you commit

Open the platform's own documentation — not a review, not a forum thread — and search it for "redirect". If you find a manager with bulk import, you have a platform you can reorganise. If you find a text field with a precondition, you have a platform you can reorganise carefully. If you find nothing, you are buying a site whose structure is final, and that should be a conscious decision rather than a discovery. The broader picture of what each platform hands over is in the seven-builder control audit, and the structural decisions this capability protects you from are in the note on URL structure.