How to Change a Page's URL Without Breaking Links

To change a page's URL without breaking links, give the page its new address and leave the old one in place as a forward. On SnapHost that happens on its own: change a page's link, file it into a folder, or change the folder's link, and the old address sends anyone who opens it to wherever the page is now. The link you emailed a client last month still opens the page today.

This post is about what that does and does not cover: what travels with a forwarded link, what happens when two pages want the same address, how to see and stop the old addresses, which plan it lives on, and the two cases where a link does break.

Why changing a page URL without breaking links is hard

You published a status page for a client at an address like acme.snaphost.ai/status and sent the link. Two weeks later you have five pages for that client and you want them in a folder, or the page is called "weekly update" now and the address should say so. On most hosting, the moment you rename the page the old address stops answering. The client's bookmark opens a not-found page, the link in the email thread is dead, and you find out when they message you.

The usual fix is a redirect, which someone has to set up by hand for each address that changed, and which nobody sets up for a page that was renamed in a hurry. So people stop renaming things, and the folder called "misc" keeps growing.

What happens on SnapHost when you change an address

A page on your workspace's own address, like acme.snaphost.ai/status, has a link you control. Change it with Edit beside the link on the page's Sharing card, and the old address keeps forwarding to the page's current one. The same is true when the page's address changes for another reason: you filed it into a folder, you changed that folder's link, you moved the folder, or you deleted the folder and the page landed somewhere else. Each address the page leaves behind forwards to where it is now, until another page takes that address or you stop it.

Two other links to the page are untouched by any of this. The random share link the page got when it was first published keeps working, whatever its readable address is now. And moving a page between folders or drives keeps its share link as well.

Who can open the page does not change either. The names on the list, the password, the end date, all stay with the page rather than with its address, so a reader following an old link gets exactly the same door they got before. Sharing and access control covers those controls, and none of them need a republish.

What travels with a forwarded link

The forward happens in the reader's browser, not on the server, and that is deliberate. A link to a deck often points at a slide, with something like #slide-4 on the end, and a link from a campaign often carries a query. The browser is the only thing that sees those parts, so the forward is done there, and the reader lands on the slide they were sent to rather than the first one. A reader without scripts is sent along by a refresh tag instead, and the old address does not sit in their history behind the page it led to.

One consequence worth knowing: because the forward is in the browser, a link preview or a search crawler following the old address does not see the page there. The old address is marked as moved and not indexed, and the page is seen only at its current address. For a link you posted somewhere public, update the address where you can. For a link in an email or a chat, the forward does the job.

When two pages want the same address

Forwards would be a mess if they could shadow a real page, so the rules put a live page first.

• A live page at an address always wins. A forward is only consulted when no page answers at that address.
• Publishing a new page with a slug that is another page's old address is refused. If you may open that page, the refusal tells you where it went, so you can update it instead of publishing a second one.
• Renaming a page onto an address that still forwards somewhere else asks you first. Agree, and the page takes the address and that forward ends.
• A page published by title, with no slug chosen, never takes an address that still forwards to another page. It gets a numbered address instead, and the page's own screen says why.
• Deleting a page frees every address it held. Nothing that forwarded there before comes back.

Where the old addresses are, and how to stop one

Open the page's Sharing card and the old addresses still forwarding to it are listed under Edit beside the link, each with a Stop forwarding button. Stop one and links to that address no longer open the page. The card also tells you at a glance how many old addresses still forward there, so a page that has been through three renames is not a mystery.

Stopping a forward is the right move when the old address was wrong, say it carried a client's name that should not have been public, or when you want the address free for something else. Leaving forwards in place costs nothing, so the default is to leave them.

Renaming a page is not the same as changing its address

This catches people. Rename, in the dashboard, changes what the page is called: the title readers and the dashboard see. It is cosmetic. The address, the share link and every existing link keep working exactly as they were. Changing the address is a separate action, Edit beside the link on the Sharing card.

So if the goal is "the client should see a better name at the top", rename the page. If the goal is "the link should read weekly-update instead of status", change the address, and let the old one forward. If you want both, do both. The address does not have to match the title, and an address that keeps the words it was created with costs nothing, while changing it costs every inbound link a forward has to cover.

Which plan this is on

Readable addresses on a workspace's own subdomain, acme.snaphost.ai/status or behind a folder's slug, are a Pro feature for a team workspace. On Free, pages live at sites.snaphost.ai with a small SnapHost mark in the corner, and the link you send is the page's share link, which never changes in the first place. Free is up to three pages at a time, each private to up to three people or public. Pro is 19 euros a month per member who can publish, and the people who read cost nothing. Pricing has the current plans.

On Pro you can also serve a page, or a whole workspace, on your own domain, and forwards resolve on a domain bound to the workspace as well. Using a custom domain for a private page covers that setup.

The two cases where a link does break

Changing your own handle re-addresses your personal drive without forwards. If your pages live under acme.snaphost.ai/~darri/ and you change the handle, links to them stop working. Treat a handle like a domain: pick it once.

And a stopped forward is stopped. Nothing warns the people holding the old link, because nothing knows who they are, so before you press Stop forwarding on an address a client has, send them the new one.

A deleted page is a third case of sorts: its addresses are freed and nothing forwards there any more. If a page is wrong, fix it or make it private rather than delete it. How to revoke access to a shared link walks through the levers that keep the address alive.

Doing it from your AI

If your AI publishes to SnapHost for you, it can change an address as well. The agent tool that does it reports the old addresses that now forward, and refuses to take an address that still forwards to another page until you have agreed. Asking "what are this page's old addresses?" gets the list, and "stop the old status address forwarding" ends one. The docs for the tools your AI uses list them by name.

A sensible way to reorganize

1. Decide the folder structure first, by client or by project, and create the folders.
2. Move the pages in. Each one's old address starts forwarding the moment it lands.
3. Rename the addresses that should read better now, from each page's Sharing card.
4. Open one old link yourself, the way a client would, and confirm it lands where you expect.
5. Where a link is posted somewhere public, update it to the new address, since crawlers follow only the current one.
6. Leave the forwards in place. Stop one only when the old address itself is a problem.

The workspace docs on drives, folders and the workspace subdomain have the full rules in one place.