Fixing Broken Internal Links at the Source

What counts as a broken internal link

Any link from one of your pages to another address on your own domain that does not end in a working page. That covers more than the familiar 404.

Links to other websites that no longer work are a separate subject, as are pages that other sites link to on your domain. This guide stays with links you publish between your own pages, and in particular with where in your site those links are generated.

Why one mistake becomes hundreds of broken links

The Internal Link Analysis finds broken links across your crawled pages and lists which pages contain them. When you first open that list, look at two numbers side by side: the number of broken link occurrences and the number of different broken destinations.

If there are 800 occurrences but only 6 destinations, you do not have 800 problems. You have 6, each repeated by something that appears on many pages. Typical multipliers are:

• The main menu or footer. One wrong item appears on every page of the site.
• A sidebar or widget. "Popular posts", "Our services" or a promo block that shows on every post.
• A theme template. A hard-coded link to /contact-us/ when the page is now /contact/, sitting in the header, the product template or the article footer.
• A reusable content block. WordPress synced patterns, page builder global sections and Shopify theme sections store content once and show it in many places.
• Tag or category links. A deleted tag still referenced by old posts produces a broken link from every one of them.

Content links, the ones typed into individual paragraphs, usually produce long lists of different destinations with one or two occurrences each. They are slower to fix, so sort them by the importance of the page they sit on.

Common causes and where they live

The relative path trap

A link written as href="pricing" means "pricing, relative to the current folder". On /services/ it resolves to /services/pricing; on /blog/2026/winter-tips/ it resolves to /blog/2026/winter-tips/pricing. The same template therefore produces a different broken address on every page. Use root-relative links that start with a slash, such as /pricing/, in templates and menus.

Finding the exact element that creates a link

Knowing which page contains a broken link is only half the job. You need to know which part of the page wrote it. Open one of the source pages, then open developer tools and paste this into the Console, replacing the path with the broken destination:

const bad = '/old-services/boiler-repair/';
document.querySelectorAll('a[href]').forEach(a => {
  if (a.pathname === bad) {
    console.log(a.closest('header, nav, footer, aside, main, [class]'), a);
  }
});

Each result shows the nearest landmark or classed element, which usually tells you straight away whether the link is in the header, a menu, a sidebar widget or the main content. Click the logged element to jump to it in the Elements panel.

Use your server logs too

Your access logs record the page the visitor came from in the referrer field. Filtering 404 responses where the referrer is your own domain gives you a live list of broken internal links that real people are clicking, which is a good way to prioritise. On a typical Linux server:

grep ' 404 ' access.log | grep 'example.co.uk' | awk '{print $7, $11}' | sort | uniq -c | sort -rn | head -30

Field positions vary with the log format, so adjust the column numbers if your output looks wrong.

Check the status yourself

Before editing, confirm what the destination really returns. curl -sI https://example.co.uk/old-services/boiler-repair/ shows the status line and any Location header. A page that loads in your browser may still return a 404 status, and a page that looks missing may be a temporary server error.

Where to fix it on each platform

WordPress

• Menus: Appearance, Menus in classic themes, or the Navigation block in the Site Editor for block themes. Custom links store a typed address and do not update when a page slug changes, whereas menu items added as pages follow the page.
• Widgets and template parts: check sidebar widgets, footer template parts and synced patterns, which are stored once and shown everywhere.
• Content in bulk: WP-CLI can search and replace across the database, including serialised data, which a raw SQL replace would corrupt. Always run a dry run first and take a backup:

wp search-replace '/old-services/boiler-repair/' '/services/boiler-repair/' --dry-run
wp search-replace '/old-services/boiler-repair/' '/services/boiler-repair/'

• Page builders: global sections, headers and footers built in a page builder are edited in the builder's template library, not in Appearance, Menus.

Shopify

• Menus: edited in the admin under the online store's navigation settings. Menu items that point at a product, collection or page by selection follow that resource; typed web addresses do not.
• Theme settings: banners, slideshows and featured sections often store a link in the theme editor. A deleted collection leaves those links pointing nowhere.
• Descriptions: product, collection and blog content may contain typed links. The bulk editor or an export and re-import helps for large catalogues.
• URL redirects: Shopify lets you add redirects for changed handles, and offers to create one when you edit a handle. That keeps old links working, but you should still update the links themselves.

Static sites and frameworks

• Link components: in Next.js, Nuxt, Astro and similar frameworks, check the configured base path, trailing slash setting and locale prefix. A mismatch breaks every link the component writes.
• Hard-coded paths in layouts: search the source for the broken path with your editor or grep -rn.
• Case sensitivity: Linux servers treat /About.html and /about.html as different files, while your laptop may not. Keep filenames and links lower case.

The fix, step by step

Redirect or update the link?

A redirect and a corrected link solve different problems, and a tidy site usually needs both.

• Add a redirect when a page's address changes and people outside your control may still use the old one: bookmarks, emails you have already sent, printed material and links from other websites. The redirect catches them.
• Update your own links in every case. You control them, so there is no reason to make visitors and crawlers go through a hop. Internal links that point at redirects also make your link reports harder to read, because the destination shown is not the page that loads.
• Do not redirect everything to the homepage. When a page is gone and nothing replaces it, a redirect to the homepage confuses visitors and search engines tend to treat it as a soft 404 anyway. A proper 404 or 410 page with helpful navigation is the honest answer; then remove the internal links that pointed there.

If your redirects have built up into chains, where A redirects to B and B to C, the redirect chains guide covers flattening them. Fixing your internal links first reduces how often those chains are used at all.

Stopping broken links coming back

Broken internal links are nearly always created by a change: a page renamed, a product removed, a menu edited, a site moved. Catching them at the moment of change is far cheaper than finding them months later.

1. Link to pages by selection, not by typing. CMS menu items and link pickers that reference a page by its ID update when the slug changes.
2. Check incoming links before deleting. Make it a habit to look up what links to a page before removing it, and repoint those links in the same session.
3. Test links in the build. For static and framework sites, a link checker in continuous integration catches mistakes before they go live. For example, lychee --offline ./public checks links between local files only, without making network requests, and fails with a non-zero exit code if any are broken.
4. Re-crawl after migrations and redesigns. These are the moments when template links change most. Run the Internal Link Analysis on staging if you can, and again on the live site immediately after launch.
5. Keep a friendly 404 page. It will not fix links, but it gives anyone who hits a dead end a search box and links to your main sections.

Pages that have lost every internal link after a clean-up are a related but different problem; the orphan pages guide covers deciding whether to link them back in.