Broken internal link (4xx/5xx target)
broken_internal_linkShort answer
A link on your site points to one of your own URLs that returns 404, 410 or a server error. Readers land on an error page; crawl budget is spent on dead ends; the link value is lost. Change the link to the right URL, or 301 the target to its replacement.
Why it matters
Internal 404s are the most direct crawl-waste there is: you are sending Googlebot, and your visitors, to nothing. They appear after slug changes, deleted products, category renames and migrations. A broken link in the navigation or footer is multiplied across every page. Google's helpful-content guidance also lists "pages with broken links" among signs of an unmaintained site.
How Glimana detects it
A site-level rule joining the link graph with crawl results: internal links whose target returned 404, 410 or a 5xx server error. Targets that answer 401, 403 or 429 (bot protection) or fail on the network are not counted as broken — the same rule as for external links. Each source page lists its broken targets and the status. A broken link that sits in a template (menu, footer, sidebar) is reported once, with the number of pages it appears on, instead of once per page.
How to fix it
- Find the affected pages in Glimana. Open Issues › Broken internal link (4xx/5xx target). This is a site-level check, so the single row carries the full evidence: the URLs, values or days involved. The task under Tasks shows the same list and the expected gain.
-
Apply the fix on your platform.
- Start with template links — one change fixes hundreds of pages.
- For content links, either edit the link to the correct URL or create a 301 from the dead URL to its replacement (do the redirect if external sites may link to the old address too).
- For targets that are truly gone, remove the link; do not redirect everything to the home page.
Appearance → Menus for template links; the Redirection plugin (or the SEO plugin's redirect manager) for 301s; the Broken Link Checker plugin to bulk-edit content links, then deactivate it.
Navigation for menus; URL redirects for deleted products and collections (Shopify creates one automatically when you change a handle, but not when you delete).
Generate internal links from route helpers rather than hard-coded paths, and add redirects when routes change.
-
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with
curl -s https://your-domain/page | grep -i '<title\|canonical\|robots'that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached. - Verify in Glimana. Open the task under Tasks and click Mark as done. The affected pages are queued for a verification crawl within a few hours, and the task closes when no internal link on them points to an error. If the check still fails, the task returns to New with a note; when it passes, the task is listed under Resolved technical issues on Impact reports. To check sooner, use Re-crawl affected pages on the issue.
How the fix is verified
The source pages and targets are re-fetched after you mark the task done; the task closes when no internal link on them points to an error.