Changing a page address without breaking links

Change a website page's address while keeping old bookmarks, shared links, and search results useful. You will update the page's route, send its old address to the new one, and update links you control.

For example, you might move a service page from /consulting to /services/consulting. The new address should open the page directly, while the old address should send visitors to that same page.

Before you change the address

Use this guide for a website page you can edit under Site → Pages, moving to another path on the same site. A route is the part after your domain: in https://example.com/services/consulting, the route is /services/consulting.

Changing the page title or a menu label does not require changing its address. Keep a working address unless the move serves a clear purpose.

You need permission to edit and publish the page, plus permission to manage redirects. Check that you can open Settings → Site → SEO → Redirects and use Add redirect before starting. If you cannot, arrange for your site administrator to complete that part of the move.

Prepare the following:

• The exact current public path and intended new path.
• A new path that is not already used by another page or an installed feature.
• A list of links to update: header, footer, buttons, other pages, shared layouts, emails, ads, and external profiles.
• Any section anchors or campaign parameters people use with the old address.
• A record of the original route and any existing redirect rules affecting either path.

Do not use this procedure to rename a checkout, sign-in callback, API endpoint, or other extension-controlled route. Use the owning feature's settings or ask your administrator. For a domain change, see Choosing or changing your primary domain instead.

Treat a route change on a published page as a live change. In the visual builder, Save publishes an already-published page. Do not use a route edit as an experiment you expect to remain private. Page changes and redirect changes are separate saves, so plan to complete and verify them together.

If an interruption to this page would affect an active campaign or important customer journey, arrange a quieter time or ask your site maintainer to coordinate the move.

Check the destination and existing redirects

Open Site → Pages and check that the new path is available. Drafts and pages outside the currently visible list may also use an address. Do not delete or overwrite another page to clear a conflict without understanding what it serves.

Then open Settings → Site → SEO and find Redirects. Review rules whose source or destination is the old or new path. A whole-section rule may also affect the page, even when its exact address is not listed.

For the example move:

• Current page: /consulting
• New page: /services/consulting
• Redirect to add after the new page works: /consulting → /services/consulting

The new path must not redirect back to the old one. Avoid creating a chain through several retired addresses; point old addresses at the final intended page.

Cedros can report route conflicts and reject redirect loops, but these checks do not prove that the destination contains the right content or is accessible to your customers.

Change the page's route

1. Open Site → Pages and edit the intended page. Confirm its title, current route, and publication state.
2. In Visual Builder, choose Page from the builder views. Find Route under Page settings.
3. Replace the old path with the intended new path, such as /services/consulting. Enter a site path, not a complete domain address. A leading slash is optional in the field; using one makes the intended path clear.
4. Leave the page's content and publication state as intended. Review any unrelated unsaved edits before proceeding, because saving publishes the page revision as a whole.
5. Open Preview and check the content. Resolve any address-conflict or validation message.
6. For an already-published visual page, choose Save. For a draft page, use Save draft, review it, and then Publish when it is ready.
7. Open the new public address in a separate tab and verify that the expected page loads. Confirm it is accessible to the intended visitor before pointing the old address at it.

The field normalizes leading and trailing slashes; do not create separate plans for /consulting and /consulting/ as though they were unrelated pages. Use a readable, stable path and keep the exact old-to-new mapping.

A preview is not proof that the public address works. If saving or publishing fails, read the error and check both public addresses before continuing. Do not assume that every part of a failed operation was rolled back.

The route edit does not create the redirect described below. Complete the redirect promptly after confirming the new destination.

Redirect the old address to the new page

1. Open Settings → Site → SEO and scroll to Redirects.
2. Choose Add redirect.
3. Leave Redirect type set to Exact redirect for a single page.
4. Set From URL to the old path, such as /consulting.
5. Set Send visitors to to the new path, such as /services/consulting. Use paths on this site rather than pasting a different domain.
6. Add an Internal note (optional) that explains the move, such as “Consulting page moved into Services.”
7. Under Advanced, confirm Redirect code → Permanent (301) — recommended for a lasting address change.
8. Choose Save. Wait for Changes saved. and confirm the rule appears in the Redirects list.
9. Open the old public address in a fresh tab or private window. Check that the browser reaches the new address and displays the correct page.

Redirect Save takes effect independently of page publication. There is no separate Publish step for the rule. Do not save it while the destination is still unavailable.

For a genuinely temporary move, choose Temporary (302) under Advanced instead. The strict 307 and 308 options are for cases where preserving the original request method matters; ask your site maintainer before applying them to forms or application endpoints.

For a permanent page move, Google recommends a permanent server-side redirect and updating internal links to the new address. See Google's URL-change guidance.

Use whole-section redirects only for a whole-section move

An exact rule for /consulting does not also move every page below it.

Choose Whole section (wildcard) only when the entire group should follow a consistent mapping. For example, a move from /guides/* to /resources/* with Keep the rest of the URL enabled sends /guides/setup to /resources/setup.

The wildcard also covers the section's root path. Confirm that the new root and all affected child pages exist before saving.

Without Keep the rest of the URL, matched addresses go to the same destination. That is appropriate only when those pages have intentionally been consolidated into that destination. Sending unrelated pages to one generic page does not preserve what visitors were looking for.

For one renamed page, keep Exact redirect. A broad wildcard can affect pages you did not intend to move, including routes used by other features.

Update the links you control

The redirect protects old links; new links should point directly to the final page.

Check and update:

• Header menus: both signed-out and signed-in destinations where applicable.
• Footer links: every relevant column.
• Page content: buttons, text links, linked images, and repeated content in shared layouts.
• Customer communications: email templates, future campaigns, confirmations, and messages that include the address.
• Other destinations: social profiles, ads, and external sites you can edit.

Follow Editing desktop and mobile navigation and Updating your footer and site-wide links for those controls. Save or publish the changes in each place you edit.

Do not assume a manually entered path changes when the page moves. Also check whether an external service expects an exact return or destination URL before changing a page involved in its workflow.

Keep the old redirect for links you cannot update, such as previously sent emails, printed QR codes, or someone else's bookmark. Do not reuse the old path for unrelated content while those links still matter.

Verify old and new addresses

Test from the public site, not just the admin preview:

1. Enter the new address directly. It should show the intended page without returning to the old path.
2. Enter the old address. It should reach the new page rather than a missing-page screen, a loop, or an unrelated destination.
3. Follow an updated menu or page link. Confirm it points directly to the new address.
4. Repeat while signed out and, for restricted content, with an eligible customer account.
5. Check on a phone as well as a computer, including the page's main button, form, booking link, or other intended next step.

Test meaningful variations of the old link too:

• A link with a section anchor, such as /consulting#pricing. The destination still needs the matching section; a route redirect does not rename headings or create anchors.
• A campaign link with a query string, such as /consulting?utm_source=newsletter. Confirm the expected parameters survive and the page behaves correctly.
• Language-specific links if the page is part of a multilingual site. Do not assume one exact rule covers every language-prefixed path.

For a technical confirmation, ask your site maintainer to verify that the old URL returns the chosen redirect status and the final destination returns the expected page response. Seeing the right address in the browser is a useful visitor check, but it does not by itself identify the redirect's HTTP status.

Check search visibility after the move

If the page should appear in search, confirm that it is published and remains eligible for indexing. Review any custom canonical URL or search-exclusion settings so they do not point at the retired address or hide the new page unintentionally.

In Settings → Site → SEO, review Sitemap and check that the intended public address is represented. If you use Google Search Console, inspect the new URL and monitor indexing or redirect errors.

Search results may continue to show the old address while search engines process the change. Keep the redirect working and update links instead of repeatedly renaming the page.

Google advises retaining redirects for at least a year in a URL move, and longer can remain useful for visitors with old links. Its Change of Address tool is for domain or subdomain moves, not a path change within the same domain. See Google's move checklist.

Correct a mistake or reverse the move

If only the redirect destination is wrong, open the rule from its Actions → Open menu, correct Send visitors to, and save. Test both addresses again.

If you need to restore the page's previous address, review the existing redirects before changing it back. A rule sending the restored path away would prevent it from behaving as intended. Coordinate the page route and redirect changes, then test every address that customers may have received.

Do not add a reverse rule while leaving the original rule in place: /old → /new and /new → /old form a loop. If a rule must be removed, record its values first, use Actions → Delete, read the confirmation, and understand that old links will stop forwarding through that rule.

Permanent redirects may be remembered by browsers. After correcting one, test in a fresh browser context as well as your usual session. If results still differ, ask your site maintainer to inspect the live response before making further changes.

Fix common address-change problems

The route is already used. Search the Pages list, including drafts, and check extension-owned pages. Choose another route or coordinate a deliberate replacement; do not delete the conflicting page just to make the message disappear.

The old address shows a missing page. Confirm an exact redirect exists for the path visitors actually use, the save succeeded, and the new destination is public. Check language prefixes and spelling.

The new address shows a missing page. Check the saved Route, publication state, intended domain, and access settings. Resolve the destination before pointing more links at it.

You see a redirect loop or the old page reappears. Inspect exact and whole-section rules affecting both paths. Remove the circular mapping or correct the destination rather than adding another rule on top.

A menu still sends visitors through the old address. Update its Destination and save that menu. The page move does not rewrite every stored link.

A section link no longer jumps to the right place. Confirm the anchor still exists on the destination page. Preserve it where appropriate or update the links that use it.

Add redirect or Save is unavailable. Check redirect-editing permission and whether the form has changed. Page-editing access alone does not necessarily include redirect access.

Search results still show the old URL. First verify the public redirect and destination. Then use Search Console, if configured, to inspect the new URL; search updates are not immediate.

If you need help, follow Getting help and reporting a problem. Include the old and new public paths, the redirect type and code, the exact error, and what happens when each address is opened.