Deciding Whether To Change A URL

How much a keyword in the path is worth is genuinely argued in the industry. What is not argued is that changing a URL costs something: a redirect hop, link value that recovers slowly or not fully, and deep links in emails, documents and ad platforms that nobody on the team controls. Tidying slugs during a content refresh is where this usually goes wrong, because the cost is invisible at the time and the gain was never measured. This is the test for when the change pays and what has to ship alongside it.

The skill file

---
name: url-slug-change-decision
description: Use when someone proposes renaming a URL for keyword or tidiness reasons and you have to decide whether it is worth the redirect.
---

# Deciding Whether To Change A URL

How much a keyword in the path is worth is genuinely argued in the industry. What is not argued is that changing a URL costs something: a redirect hop, link value that recovers slowly or not fully, and deep links in emails, documents and ad platforms that nobody on the team controls. Tidying slugs during a content refresh is where this usually goes wrong, because the cost is invisible at the time and the gain was never measured. This is the test for when the change pays and what has to ship alongside it.

## What you need first

- The current URL with its external referring domains and its clicks over 12 months
- The proposed URL and the specific reason for the change, written down
- Every place the URL is hardcoded outside the site: ad destinations, email templates, docs, app deep links, print

## Method

1. Write the reason in one sentence. If the reason is a keyword in the path, the change is very unlikely to pay; if the path is wrong or misleading and shows in results, it may.
2. Check external links to the current URL. A page with earned links is the strongest argument for leaving the path exactly as it is, whatever the slug says.
3. Find hardcoded uses outside the site. Ad destination URLs, tracking rules and app deep links often do not follow a redirect the way a browser does.
4. If the page belongs to a set, decide for the whole set in one go. Half a directory on the old pattern is worse than either pattern applied consistently.
5. Where you proceed, ship the 301 in the same deploy as the new URL, and update every internal link to point at the new URL directly instead of relying on the redirect.
6. Update the sitemap and any canonical or hreflang references in the same deploy, then watch the old URL leave the index over the following weeks rather than assuming it has.
7. Flatten any chain: if the old URL was already a redirect target from a previous migration, point the oldest URL at the final destination too.
8. Keep the redirects permanently. Redirect maps cleaned up after a year are how sites quietly lose link value long after anyone remembers the rename.

## What this produces

A written decision per URL, with the redirect, internal-link and external-reference tasks listed for those that go ahead.

## Where this goes wrong

- Renaming during a content refresh, so any ranking movement cannot be attributed to either change
- Leaving internal links pointing at the old URL and relying on the redirect, which slows crawling and makes every later audit noisy
- Chaining the new redirect onto an older one instead of flattening to a single hop
- Changing the URL of a page that has external links purely to insert a keyword, which trades a real signal for a weak one

---

From the QuQi skill library - https://www.quqi.io/skills/url-slug-change-decision

What you need first

• The current URL with its external referring domains and its clicks over 12 months
• The proposed URL and the specific reason for the change, written down
• Every place the URL is hardcoded outside the site: ad destinations, email templates, docs, app deep links, print

Method

1. 01 Write the reason in one sentence. If the reason is a keyword in the path, the change is very unlikely to pay; if the path is wrong or misleading and shows in results, it may.
2. 02 Check external links to the current URL. A page with earned links is the strongest argument for leaving the path exactly as it is, whatever the slug says.
3. 03 Find hardcoded uses outside the site. Ad destination URLs, tracking rules and app deep links often do not follow a redirect the way a browser does.
4. 04 If the page belongs to a set, decide for the whole set in one go. Half a directory on the old pattern is worse than either pattern applied consistently.
5. 05 Where you proceed, ship the 301 in the same deploy as the new URL, and update every internal link to point at the new URL directly instead of relying on the redirect.
6. 06 Update the sitemap and any canonical or hreflang references in the same deploy, then watch the old URL leave the index over the following weeks rather than assuming it has.
7. 07 Flatten any chain: if the old URL was already a redirect target from a previous migration, point the oldest URL at the final destination too.
8. 08 Keep the redirects permanently. Redirect maps cleaned up after a year are how sites quietly lose link value long after anyone remembers the rename.

What this produces

A written decision per URL, with the redirect, internal-link and external-reference tasks listed for those that go ahead.

Where this goes wrong

• Renaming during a content refresh, so any ranking movement cannot be attributed to either change
• Leaving internal links pointing at the old URL and relying on the redirect, which slows crawling and makes every later audit noisy
• Chaining the new redirect onto an older one instead of flattening to a single hop
• Changing the URL of a page that has external links purely to insert a keyword, which trades a real signal for a weak one

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Questions about this skill

More in On-page SEO