AAdSense Approval Checker
Free Broken Link Checker · No signup

Broken Link CheckerFind dead links before Google does

Paste a URL — we crawl your pages and check every link, image, script, stylesheet and CSS background. Get a full breakdown of link types, hosts, redirects and broken links.

Crawls up to 20 pages and 700 links. Results are not stored.

Why Google cares about your dead links

A broken link is a promise you made and didn’t keep. Someone clicked it expecting something, and got a wall of nothing. Multiply that by twenty across your site and you have a pattern — not bad luck, but neglect.

Googlebot has a finite crawl budget for your domain, and every request it burns on a URL that returns 404 is a request it didn’t spend on the article you published yesterday. On a small site this barely registers. On a site with a few hundred pages and a sloppy internal link graph, it means your best content sits undiscovered while the crawler chases ghosts.

The AdSense angle is different and more direct. A human reviewer opens your site and clicks around for a few minutes. They are not running a crawler — they are forming an impression. If two of the six links they try are dead, the impression is that nobody is minding the store. Reviewers are trained to look for sites that are complete, maintained, and genuinely serving readers. Dead links argue against all three at once. Read our breakdown of why AdSense rejects sites and you’ll notice the same theme: rejections are rarely about one flaw, they’re about accumulated evidence that a site isn’t ready.

What this tool actually finds

“Broken link” is a lazy catch-all. The scan separates the failures because the fixes are completely different:

  • 404 Not Found — the server is fine, the URL isn’t there. Usually a typo, a deleted page, or a slug you changed without redirecting.
  • 5xx server errors — your server tried and failed. A 500 or 503 on a page that should exist points at your host, your PHP, or a plugin conflict. These are more urgent than 404s because they can hit your whole site at once.
  • Dead redirects and redirect chains — a 301 that points at another 301 that points at a 404. Each hop costs crawl budget and leaks a little link equity. Chains longer than two hops are a maintenance smell.
  • DNS failures and timeouts — the domain no longer resolves, or the server never answers. Almost always an external site that has gone away entirely.
  • Broken images — the loudest failure type, because readers see it. A page of alt-text boxes looks abandoned in a way a dead footer link never does.
  • Broken scripts and stylesheets — the most dangerous, because they can silently wreck your layout on a reviewer’s screen while looking fine in your cache.

How to fix each type

Work the list, don’t agonize over it:

  1. Internal 404s: fix the link or delete it. If the target page moved, add a 301 redirect from the old URL to the new one — not a 302, and not a redirect to your homepage. A homepage redirect is Google’s definition of a soft 404 and buys you nothing.
  2. 5xx errors: stop editing content and check your server logs. Deactivate plugins one at a time. If it’s your host throttling you under load, that’s a hosting problem, and it will also be hurting your page speed scores.
  3. Redirect chains: repoint the first link straight at the final destination. Then delete the intermediate hops if nothing else uses them.
  4. Broken assets: re-upload the image, fix the path, or remove the reference. Broken assets often come from a botched migration where the media library moved but the hardcoded URLs didn’t.
  5. Dead external links: the other site died and that isn’t your fault — but it is your problem, because the reader is on your page when it fails. Find a live equivalent source, link to the Wayback Machine snapshot, or strip the link and keep the sentence. Do not leave it.

Build the habit, not the panic

Run a full scan after anything structural: a migration, a redesign, an HTTPS switch, a permalink change, a theme swap. Those four events cause the overwhelming majority of mass link breakage, and they break things in bulk rather than one at a time.

Between those events, a monthly scan is plenty for most sites. When you get results, triage in this order: internal links before external links, because internal ones are entirely your fault and entirely under your control. Then highest-traffic pages first — a dead link on the post that pulls half your sessions costs you more than fifty dead links on pages nobody reads. Pull your top ten pages from Analytics and clean those completely before touching the long tail.

Broken links won’t reject you — alone

Be clear about the weight here. Nobody at Google has ever declined an application with the reason “seven broken links.” That is not a policy violation and it isn’t a rejection category.

What broken links do is compound. Six dead links plus 400-word posts plus a missing About page plus a stale copyright year add up to one conclusion in the reviewer’s head: this site is unfinished. That’s the impression that gets you the low value content response, and it’s an impression, not a checklist item — which is exactly why you fix the cheap things. Broken links are the cheapest signal on the entire list. Fixing them takes an afternoon; fixing thin content takes a month.

Clear this scan, then work through the rest of your gaps with the pre-application checklist before you hit submit.

How the crawler actually works

You paste in a URL and the crawler treats it as the front door. It fetches that page, reads the raw HTML, and pulls out every reference it can find: the <a> tags for links, <img> for images, <link> for things like stylesheets and canonical tags, and <script> for the files your page loads. Each of those references becomes a target it needs to check.

From there it works outward within limits. It will follow up to 20 pages on your own domain and test up to 400 unique links in total, which keeps a scan fast and stops it from wandering the entire internet. For every target it sends a request, follows any redirects to their destination, and records the HTTP status it lands on: 200 for healthy, 404 for gone, 301 or 302 for a redirect, 500 for a server that fell over. One important detail: this runs server-side, so the request comes from the tool’s IP address, not your browser. That means a clean result reflects what a neutral visitor sees, not something cached or personalised for you.

A worked example

Say you run a 30-page blog and point the tool at your homepage. The scan comes back with three things worth your attention. First, a hard 404 on an old /contact-us link that’s still sitting in your footer, left over from when you renamed the page to /contact. Second, a redirect chain on a post you moved twice, so the link hops from the old slug to a middle URL and finally to the live one. Third, two broken image paths on an older article, both pointing at an /wp-content folder from before a site migration.

Read that output by impact. The 404 in the footer appears on every single page, so it’s your first fix; sitewide dead links are exactly what a reviewer trips over. The broken images come next, because a visitor sees the gap immediately and it makes the page look abandoned. The redirect chain is real but lowest priority: it still resolves, it just wastes a hop, so you clean it up by pointing the original link straight at the final URL. Three findings, a clear order, ten minutes of work.

Limitations to be honest about

This tool checks what it can reach from the URL you give it, and that’s a real boundary. Orphan pages, ones nothing links to, never get discovered because the crawler has no path to them. Anything behind a login won’t be tested, since the tool visits as an anonymous guest. And links that only appear after JavaScript runs may be invisible to it, because it reads the raw HTML your server returns rather than executing scripts the way a full browser would.

Two more caveats worth holding in mind. A scan is a snapshot in time: it tells you the state of your links at the moment you ran it, and a page that’s fine today can rot next week when someone else’s site disappears. It also can’t judge quality. A link that returns a healthy 200 still counts as working even if it now points at a parked domain or thin content. The tool confirms the door opens; it can’t tell you whether the room behind it is worth walking into.

Who should run this, and when

If you’re a blogger about to apply to AdSense, run it first. Dead links are an easy, avoidable reason to look unpolished before review, and clearing them is one of the quieter steps in how to get AdSense approved. Beyond that first pass, certain events practically demand a scan: a site migration, a redesign, a switch to HTTPS, or a change to your permalink structure. Each of those quietly rewrites URLs across your site, and each is a classic source of the broken images and stale internal links you saw in the example above.

Outside of big changes, a monthly cadence keeps you honest. Links decay on their own as other people move or delete their content, so a quick scan once a month catches the drift before it piles up. Pair it with an occasional page speed check and you’re watching the two things that make a site feel either cared for or neglected: whether it loads well, and whether its links still go anywhere.

Frequently asked questions

What does the broken link checker do?

It crawls your website starting from the URL you enter, follows the links it finds across your pages, and makes a request to every link to see whether it still works. Anything returning a 404, 5xx error, DNS failure or timeout is flagged as broken.

Why do broken links matter for AdSense and SEO?

Broken links waste crawl budget, frustrate visitors, and signal a poorly maintained site. Google's AdSense reviewers and search ranking systems both treat a site full of dead links as lower quality. Fixing them is one of the easiest quality wins before applying for AdSense.

How many pages does it crawl?

Up to 20 same-domain pages and 400 unique links per scan. That covers most small and medium sites in one pass. For very large sites, run the checker on individual sections.

Do you store the URLs I check?

No. The crawl runs server-side in memory and results are streamed straight to your browser. Nothing is saved.

Comments

Leave a comment

5/5

Never published or shared.

0/100 words

Comments are moderated before they appear. Be respectful.