Broken external link
broken_external_linkShort answer
Your page links to an external URL that returns 404/410, whose domain no longer resolves, or that has answered 5xx in two consecutive checks. Readers who click land on an error. Update the link to the resource's new address, link to its web.archive.org copy, or remove it.
Why it matters
Broken outbound links are a readability and trust problem more than a ranking one, but on reference content they are the single most visible sign of neglect — and the 2026 helpful-content guidance weighs whether a page is maintained. A page citing a dead source also loses the credibility the citation was meant to give.
How Glimana detects it
External link targets are checked periodically, not on every crawl. A target is reported when it returned 404 or 410, its domain failed DNS resolution definitively, or it returned 5xx twice in a row (a single 5xx is treated as transient). Each affected page lists the broken URLs with their status; a dead link in a template (menu, footer) is reported once with the number of pages it appears on.
How to fix it
- Find the affected pages in Glimana. Open Issues › Broken external link. 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.
For each link: find the content's new address (the site's search, or a web search for the title), link to the Wayback Machine copy (
https://web.archive.org/web/2024/https://…) if the source is gone, or remove the link and keep the text.Edit the post; the broken URL is listed in the task. The Broken Link Checker plugin can bulk-edit, but it is heavy — run it once, then deactivate.
Edit the page, blog post or product description containing the link.
Edit the content; consider a link-check step in your publishing workflow.
-
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 broken targets remain on them. 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 affected pages are re-crawled and their external targets re-checked; the task closes when no broken targets remain on them.