How Often Should You Check for Broken Links? A Practical Schedule by Site Type
· 7 min read
"Check your links regularly" is common advice that doesn't tell you much. Regularly could mean every day or once a year. The honest answer is that the right schedule depends on how quickly your site can break, and that comes down to two things: how often you change it, and how many links point to things you don't control.
This guide lays out a schedule by site type, lists the events that should trigger a check no matter what the schedule says, and explains why "how often" matters less than "what happens after the check."
Why links break in the first place
To pick a schedule, it helps to know where breakage actually comes from. Almost all of it has one of five causes:
- You changed something. You renamed a page, changed a slug, removed a product, restructured the menu, or switched themes. This is the most common cause of internal broken links, and it happens right when you make the change.
- A migration or redesign. This is the same as the first cause but at scale. Changes to URL patterns (
/blog/post-namebecoming/post-name,.htmlextensions dropped, category bases changed) can break hundreds of links in one go. - Someone else changed something. External sites you link to delete pages, restructure, or shut down. This is "link rot." It happens gradually, and you have no warning.
- Content editors paste bad links. A missing
https://makes a link relative, soexample.comon/about/turns into/about/example.comand returns a 404. A typo or a staging URL left in a post does the same. - Files and media go missing. PDFs get replaced with new filenames, images are deleted from the media library, and CDN paths change.
Causes 1, 2, 4 and 5 happen when you change something, so you can catch them by checking after the change. Cause 3 happens at random, so you can only catch it by checking on a schedule. A good routine handles both.
A starting schedule by site type
These are sensible defaults, not rules. Change them based on what your first few scans turn up (more on that below).
Small brochure site (under ~50 pages, edited a few times a year)
Monthly scheduled check, plus a check after any edit session.
A local plumber's five-page site doesn't change much. Its internal links break only when someone edits it, so a scan after edits catches most problems. A monthly scan picks up external link rot (links to suppliers, certification bodies, review profiles) and any changes the host or platform made without telling you.
Active blog or content site (new posts weekly)
Weekly check.
Every new post adds links, and older posts link to external sources that rot over time. The more content a site has, the more external links it has, and the more rot each month. Weekly is usually enough. If you publish every day, look for a checker that can scan new pages as they go live.
E-commerce store
Weekly at minimum. Daily if products change often.
Stores change all the time. Products sell out and get removed, collections get reorganized, and seasonal landing pages expire. Each removed product URL can leave broken links in category pages, blog posts that mention it, and emails. On a store, a broken link means a lost sale, so it costs more than it would on a brochure site.
Large site, or a site with frequent deploys
Daily.
If the site has thousands of pages, several editors, or a development team that deploys several times a week, things break between scans often enough that weekly checks let problems sit for days. Daily scans that only alert on new breakage are the norm here. Without diffing, a daily report becomes noise.
Agencies managing client sites
Daily for every site under a care plan, with weekly or monthly reporting to the client.
The schedule and the report don't have to match. Checking daily means you find out about a break before the client does. Reporting monthly gives the client a summary they'll actually read. If you're charging for maintenance, finding out from the client that their booking page has been a 404 for two weeks is the outcome you most want to avoid.
Documentation and knowledge bases
On every build, plus a weekly scan of the live site.
Docs are full of cross-references and links to API references, code repositories and release notes, all of which move. Build-time checks catch internal mistakes before they ship. The weekly live scan catches external rot and anything the build check can't see, like redirects added at the server level.
Events that should trigger a check right away
Whatever your schedule, scan as soon as possible after any of these:
- A site migration or redesign. Scan the old site before the switch so you have a list of URLs, then scan the new site straight after launch. Every old URL that now 404s needs a 301 redirect or a reason it doesn't.
- A change to the URL structure. Permalink settings, category bases, trailing slashes, language prefixes.
- A theme or page-builder change. Menus, footers and widgets often get rebuilt, and their links can quietly change.
- Bulk deletion. Discontinued products, old events, expired job posts.
- A domain change or HTTPS move. Hard-coded absolute URLs in content are a classic source of breakage.
- A CMS or plugin update that touches routing. This doesn't happen often, but when it does it hits every page.
- Any time you get an unexplained traffic drop on specific pages.
If your checker has an API, wire a scan into your deploy pipeline so a scan starts as part of every deploy.
How to tune the schedule after a month
Your first scan is a baseline, and it will probably find a backlog. Fix that first. After that, watch how much new breakage turns up between scans:
| What you see between scans | What it suggests |
|---|---|
| Almost never anything new | Your schedule is fine, or you could scan less often |
| A few new external breaks each time | Normal link rot, so keep the schedule |
| New internal breaks most times | Edits are breaking things, so scan more often or add post-edit checks |
| Bursts of new breaks after deploys | Add a scan to your deploy process |
| Lots of 403/429/timeouts on the same external sites | Those sites block bots. Exclude them or verify them by hand |
The aim is that each scan turns up a small, manageable number of genuinely new problems. If every report is huge, either the backlog hasn't been cleared or the schedule is too infrequent for how fast the site changes.
What matters more than frequency
A daily scan that nobody reads is worth less than a monthly scan that someone acts on. Three things decide whether a checking routine actually keeps links working:
1. Only alert on what's new. If every report repeats last week's known issues, people stop reading them. Use a checker that compares each run against the previous one, or keep your own list of known issues and alert only on the difference.
2. Verify before you alert. External sites go down briefly, and some answer automated requests with errors while working fine in a browser. A good checker rechecks a failure before reporting it. When we built prospect lists for DeadLinkPatrol, we only counted a link as broken if it returned 404 or 410 on two separate requests. One failed request isn't enough to call a link broken.
3. Give the fix an owner. Every report should go to someone whose job includes fixing it. On an agency team, that means routing each client's alerts to the person who manages that client.
Does Google care how quickly you fix broken links?
Google's own documentation is useful here. Its Search Console help says that 404 responses "are not necessarily a problem, if the page has been removed without any replacement," and that if a page has moved, you should "use a 301 redirect to the new location." Its developer docs explain that URLs returning a 4xx status are removed from the index, and that Googlebot crawls them less often over time.
So a broken link isn't a penalty in itself. The real cost is what the link would have done: a visitor who reaches a dead end instead of a product page, internal link value that leads nowhere, or a page that dropped out of the index because it moved without a redirect. Those costs add up the longer the link stays broken, so the useful question is how long you're willing to let a broken link hurt you before you notice. If the answer is "no more than a day" for your checkout and contact pages, those pages need daily checks, whatever you do with the rest of the site.
A simple setup that covers most sites
If you'd rather not think about any of this:
- Run a full scan today and fix everything it finds.
- Schedule automatic scans: monthly for small static sites, weekly for blogs and stores, daily for large sites and client sites you're paid to maintain.
- Make sure alerts only fire for new breakage.
- Add a manual scan to your checklist for launches, migrations and theme changes.
- Look at the numbers after a month and adjust.
DeadLinkPatrol's plans follow this pattern. The free plan scans 1 site monthly (up to 100 pages). Starter ($9/mo) covers 3 sites weekly. Agency ($79/mo) covers 50 sites daily with white-label client reports. Every plan emails you only when new breakage shows up (see pricing).
Not sure where you stand? Run a free scan of up to 25 pages. No signup is needed, and it'll show you how much has broken since you last looked.