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.
FORMAT
url-slug-change-decision.md
WHEN TO REACH FOR THIS
Use when someone proposes renaming a URL for keyword or tidiness reasons and you have to decide whether it is worth the redirect.
The skill file
url-slug-change-decision.md
---
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
Free to download · no account, no email
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
Claude Code
Save it as ~/.claude/skills/url-slug-change-decision/SKILL.md and Claude loads it on its own when what you are doing matches the trigger line. Put it in .claude/skills inside a project instead if the whole team should have it.
Claude
Upload the file in the skills section of your settings. Once it is there it applies itself in any conversation where the trigger fits, so you do not have to remember it exists.
ChatGPT
There is no skills format to install into, so paste the file contents into a Project instruction or a Custom GPT instead. It then applies to every chat in that project rather than only the one you paste it into.
Anything else
Paste the markdown into the chat before your question. It works in any assistant, it just has to be pasted again each time.
Questions about this skill
When is this decision worth making rather than just renaming the URL?
When someone proposes renaming a URL and the default answer is to do it because the new slug reads better. Whether a keyword in the path is worth anything is genuinely argued. What is not argued is the cost: a redirect hop, link value that recovers slowly, and deep links in ads, emails and documents nobody on the team controls.
What do I need in hand before starting?
The current URL with its referring domains and twelve months of clicks, the proposed URL with the reason written in one sentence, and every hardcoded use outside the site. Skip the hardcoded list and you find out later from an ad platform, where destination URLs and tracking rules often do not follow a redirect the way a browser does.
What do I end up with, and which part gets used?
A written keep-or-change decision per URL, with the redirect, internal-link and external-reference work listed for the ones that proceed. The written reason is what gets used months later, when someone asks why half a directory sits on the old pattern. Decide for a whole set at once: half-migrated patterns are worse than either pattern applied consistently.
What most often ruins this?
Renaming during a content refresh. Two changes ship together and no movement afterwards can be attributed to either, so you learn nothing and repeat it. Leaving internal links pointed at the old URL is the other one: the redirect works, so nobody notices, while crawling slows and every later audit is noisy with hops. Keep the redirects permanently.
More in On-page SEO