When a page’s URL slug changes, every internal link on your site still pointing to the old slug breaks, even if you’ve correctly redirected the old URL externally — internal links pointing at a redirect chain, rather than directly at the current page, is inefficient and easy to overlook.
Check a page you know recently changed slug for internal links still pointing at the old one
Use your browser’s “find in page” or a site search feature to look for internal links referencing the old slug across your content. Finding several confirms this is worth a systematic repair rather than a one-off, isolated link.
Internal link repair after slug changes
Internal links still pointing at an old slug, updated to the current URL directly.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| A page’s slug changed and internal links across the site still point to the old version | This fix covers it |
| You want a broader broken link scan, not specifically slug-related internal links | The relevant broken link scan & repair tier for your site’s size |
| You’re planning a full permalink structure change, not a single slug update | Permalink structure change with redirect safety |
| The old URL isn’t redirecting at all, not just internal links being outdated | 404 mapping & redirect implementation, or Single redirect setup |
What you are seeing
- Internal links across the site still pointing to a page’s old slug rather than its current one
- These links working via redirect, but not pointing directly at the current, correct URL
- The issue possibly affecting many pages if the changed content was widely linked internally
- Search Console potentially flagging the pattern as an inefficiency, even if not an outright error
Common causes
- A slug changed manually without a corresponding update to every internal link referencing it
- Content edited or migrated in a way that didn’t account for internal cross-references
- A bulk content import or migration carrying forward outdated internal link references
- Internal links hardcoded rather than using a method that would automatically update with a slug change
What we do
- Identify every internal link still referencing the old slug
- Confirm the current, correct destination for the changed page
- Update each internal link to point directly at the current URL
- Verify the redirect from the old slug still exists as a safety net for any remaining external references
- Check for the same pattern following any other recent slug changes
- Provide a written summary of what was updated
What is included
- Internal links updated to point directly at current URLs
- Verification that redirects remain in place as a safety net
- A check for the same pattern from other recent slug changes
- The pre-fix backup, kept for 30 days
Not included
- A broader broken link scan beyond slug-related internal links specifically, a separate fix
- Setting up the original redirect from the old slug, if that’s not already in place — a separate, related fix
- External links pointing at the old slug, outside our control
- Ongoing repair as future slug changes occur, unless flagged to us each time
Questions about this fix
Does it really matter if the old links still work through a redirect?
It's not broken in the sense of an error, but every redirect hop adds a small, unnecessary delay and slightly dilutes ranking signal compared to a direct link — worth cleaning up, especially if it affects many pages.
How would I know how many internal links are actually affected?
A systematic scan is the reliable way to know the true count — checking a page or two manually, as the self-check suggests, gives you a rough sense of whether this is worth addressing systematically.
Will this remove the redirect from the old slug entirely?
No, we'd keep the redirect in place as a safety net for anything outside our control still referencing the old URL (an external link, a bookmark), while updating your own internal links to point directly at the current version.
Could this happen again after future slug changes?
Yes, unless internal links are managed in a way that updates automatically — a manual process for changing slugs carries this same risk each time unless deliberately checked for afterward.
Is this worth doing for just one or two internal links?
For a very small number, the practical benefit is modest — this is most worth doing when a slug change affected content that's widely linked internally across many pages.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.