Broken Link Scanner

How this check works

Scanaris collects every <a href> link in your page's HTML and keeps the internal ones: those that resolve to your same origin (domain, protocol and port). It discards mailto:, tel:, javascript:, anchors starting with #, links to the page itself and duplicates, and caps the list at 25 so as not to hammer your server. It visits each one and counts it as broken only if it responds 404, 410 or a 5xx error. Redirects are not a failure, nor are 401 or 403 (it may be a deliberately private area), and if the request fails at the network level it is not counted, to avoid false positives. With three or more broken links the finding is medium severity; with one or two, low. It lists up to ten with their status codes.

Why it matters

A broken link is a dead end for the user and for Google. For the user, an error page where they expected the product, the article or the form, and a reason to leave. For Google, wasted crawl budget and a signal of a neglected site; on top of that, the authority that link passed to the destination page is lost. Broken links on the home page are the worst, because it is the most crawled page and the one most people see, which is why this check starts there.

Why it happens

Pages that were renamed or deleted without updating the menus or the content that linked to them. CMS or domain migrations that change the URL structure. Hand-typed links with a typo. A deploy that removed a route the footer kept linking to. And on AI-generated sites, links to pages the AI invented in the menu ("/pricing", "/docs") that never came to exist.

How to fix it

• If the page moved, a 301 redirect from the old URL to the new one. That fixes every link pointing there at once, including those from other sites. In Nuxt, routeRules; in Next.js, redirects(); on Vercel and Netlify, the redirects file; in WordPress, a redirects plugin.
• If the page no longer exists and has no replacement, remove the link. If you want Google to forget it quickly, respond 410 instead of 404.
• If it is a typo, fix the href. Frameworks with typed routes (Nuxt with typedPages, Next.js with typedRoutes) turn these mistakes into build errors.
• 5xx errors are not misspelled links but pages that fail to load. Check the logs for that route: usually a query that crashes or a resource that no longer exists.
• Add a link checker to CI (lychee, linkinator) so the next broken route never reaches production.

Check it is fixed

curl -s https://yourdomain.com | grep -oE 'href="/[^"#]*"' | cut -d'"' -f2 | sort -u | while read p; do
  printf "%s " "$(curl -s -o /dev/null -w '%{http_code}' "https://yourdomain.com$p")"; echo "$p"
done | grep -E "^(404|410|5)"

No line should come out. Repeat on your most important pages besides the home: each page has its own links.

Frequently asked questions

My site is a SPA and non-existent routes return 200 with the app.

Then this check cannot detect your broken links, because everything responds 200. But Google does detect them as "soft 404s" and treats them as errors. Configure your server or framework so that unknown routes respond with a real 404.

What about links to other sites?

They are not checked: many sites block bots and would produce false positives. Review them yourself from time to time with a desktop tool or with the CI checker, which you can configure to visit them more patiently.

I only have one broken link and it is low severity. Should I fix it?

Yes: it takes a minute and the next scan confirms it. The other development leftovers that usually accompany a broken link, such as URLs to localhost, are looked for by internal references; and whether Google has the correct list of your pages is checked by robots and sitemap.