How to Find and Fix Broken URLs on Your Website
Broken URLs hurt SEO, frustrate users, and break the web. This guide covers how to find them (free tools, logs, search console), how to fix them (redirects, rewrites, removals), and how to prevent them in the first place.
Broken URLs are 404s, server errors, and redirect chains. Find them with Google Search Console (Coverage report), a site crawler (Screaming Frog, Sitebulb), or your server access logs. Fix them with 301 redirects (permanent), 410 Gone (intentional removal), or by restoring the page. The Uttir URL tools (encoder, decoder) help debug URL encoding issues, which are a common cause of broken URLs.
Broken URLs are one of the most common — and most preventable — problems on a website. A 404 is a missed opportunity: the user wanted something, the site didn't have it, the user leaves, and Google lowers the site's quality score. Over time, broken URLs erode search rankings, frustrate users, and break the web. This guide covers how to find them, how to fix them, and how to prevent them.
What counts as a "broken URL"
The term covers several distinct cases:
- 404 Not Found — the URL does not exist on the server. Most common type. The user clicked a link or typed a URL that no longer matches a real page.
- 410 Gone — the URL existed and has been intentionally removed. Treated by Google as "this will never come back" — the page is dropped from the index faster than a 404.
- 500-class errors — server errors. The URL exists but the server is broken. These are the most serious because they affect every user, not just visitors to a specific page.
- Redirect chains — the URL works, but only after 2+ redirects. Each redirect is a round trip and a chance for a browser to time out. Best practice: one redirect maximum.
- Soft 404s — the URL returns 200 OK but the page is "not found" content. Google may index these as real pages, hurting SEO.
- Incorrect URL encoding — the URL has the wrong escape sequences.
caf%C3%A9andcaféshould be the same page; if the server treats them differently, you have a bug.
How broken URLs hurt you
User experience
A 404 is a dead end. The user has to back-button, search, or leave. Studies show 88% of users are less likely to return to a site after a bad experience. A 404 is a bad experience.
SEO
Google's quality score is partially based on the number of broken URLs a site has. A site with many 404s ranks lower than a site with few. Google also stops crawling past a 404 — if a broken URL is in your sitemap, Google may stop trusting the rest of the sitemap.
Crawl budget
Google allocates a finite amount of "crawl budget" to each site. Broken URLs waste it. A site with 10,000 URLs, 1,000 of which are broken, has Google spending 10% of its crawl on nothing. Fix the broken URLs and the remaining 9,000 get crawled more often.
How to find broken URLs
Google Search Console (free, recommended)
The Coverage report shows every URL Google tried to crawl and the result. URLs in the "Excluded" section are the most useful: they include "Not found (404)", "Soft 404", "Blocked due to 404", and "Crawled - currently not indexed". Each one tells you which URLs are broken and how Google is treating them.
Set up email alerts for new 404s. The Search Console will email you when a new category of issue appears.
Site crawlers
Tools that crawl your site like Google does:
- Screaming Frog — the standard for SEO audits. Free for up to 500 URLs; paid for more. Crawls every page and reports status codes, redirects, and broken links.
- Sitebulb — similar to Screaming Frog, with a more visual UI.
- Ahrefs / Semrush — paid SEO tools with site audit features. More expensive but include backlink and keyword data.
Run a crawler monthly. Fix every 404 and every redirect chain.
Server access logs
The most thorough source: your server's access log. Every request is recorded with the URL and the response code. A simple log parser can extract every 404 in the last 30 days. Tools: grep, awk, or a log analyzer like GoAccess.
Logs are useful because they show what real users are hitting. Search Console shows what Google is hitting; logs show everyone.
External link checkers
Tools that crawl other sites and report links pointing to your site:
- Ahrefs / Semrush — paid, comprehensive.
- Google Search Console → Links — free, but limited.
- Dead Link Checker — free, fast, ad-supported.
These find "external broken links" — links on other sites that point to URLs on your site that no longer exist. Fixing these (with redirects) recovers traffic that would otherwise land on a 404.
How to fix broken URLs
Case 1: the page was renamed
Set up a 301 redirect from the old URL to the new URL. This is the most common fix. The 301 tells browsers and search engines "this page has permanently moved". The user is sent to the new URL, and Google transfers the search ranking from the old URL to the new one.
Implementation depends on the server:
- Apache — in
.htaccess:Redirect 301 /old-page /new-page - Nginx — in the server block:
rewrite ^/old-page$ /new-page permanent; - Netlify — in
_redirects:/old-page /new-page 301 - Vercel — in
vercel.json:{"source": "/old-page", "destination": "/new-page", "statusCode": 301} - Cloudflare Pages — same as Netlify, in
_redirects
Case 2: the page was removed and will not come back
Return a 410 Gone status. The 410 is faster for Google to process than a 404 — Google knows immediately to drop the URL from the index, rather than waiting for a 404 pattern to emerge.
Use 410 when you are sure the page is gone for good. If there is any chance the page will return, use 404.
Case 3: the page was a typo or never should have existed
Redirect to the most relevant existing page. If the broken URL is /blog/10-tips-for-X and the real blog post is /blog/10-tips-for-Y, redirect to Y. If no good target exists, redirect to the section index or the homepage.
Case 4: the page was deleted by accident
Restore the page from backup. The 301 redirect is the wrong fix for this case — you want the original URL to work, not redirect to a different one.
Redirect chains
A redirect chain happens when a URL is redirected multiple times: /a → /b → /c → /d. The user has to make 3 round trips to get to the final destination. Each one is a chance for a failure, and Google has explicitly said redirect chains hurt rankings.
Fix: collapse the chain. Update the original URL to point directly to the final destination. /a → /d is one redirect, not three.
Common cause: layered migrations. A site moves from /a to /b, then later from /b to /c. The redirects stack. The fix: when migrating, update the original redirect to point to the new destination.
URL encoding issues
A common cause of broken URLs: incorrect URL encoding. URLs can only contain ASCII characters. Non-ASCII characters (accented letters, emoji, CJK) must be percent-encoded: é becomes %C3%A9, 日 becomes %E6%97%A5.
Most modern frameworks handle this automatically. But bugs happen: a user types a URL with a literal é and the server treats it as a different URL from %C3%A9. The fix is to canonicalize: the server should always treat both forms as the same URL.
The Uttir URL Encoder and URL Decoder help debug these issues. Encode a string, decode the result, and check that round-tripping is consistent.
How to prevent broken URLs
Never delete a URL without a redirect
The single biggest cause of broken URLs is deletion without a redirect. The page existed, someone linked to it, and now it returns 404. The fix: every page deletion should come with a 301 to a related page or a 410 Gone.
Use canonical URLs
Duplicate content (e.g. /blog/foo and /blog/foo?page=1) creates two URLs with the same content. Google may index both, splitting the ranking. The fix: add a <link rel="canonical"> tag pointing to the primary URL.
Validate links before publishing
When publishing a blog post that links to external sites, validate every link. Tools: W3C Link Checker (free, slow), or any of the SEO crawlers above.
Monitor the Search Console
Set up email alerts for new 404 categories. The Search Console will email you when a new batch of broken URLs is discovered, so you can fix them quickly.
Plan migrations
If you are changing URL structure (e.g. moving from /post-title to /blog/post-title), the migration is the dangerous time. Plan the redirects before the move. Test on a staging environment. Then move atomically: deploy the new structure and the redirects at the same time.
Common pitfalls
301 vs 302
301 is permanent, 302 is temporary. Use 301 for content that has moved for good. Use 302 for content that may move back. The wrong choice can hurt SEO: a 302 does not transfer ranking signals the way a 301 does.
Redirect loops
A redirect loop is /a → /b → /a. The browser detects it and gives up, showing an error. The cause is usually a typo in the redirect configuration. Test every redirect with a crawler.
Redirecting every 404 to the homepage
This is a common anti-pattern. The user clicks a link, lands on the homepage, and has to search for what they were looking for. The redirect should point to the most relevant page, not the homepage. The only exception: the homepage itself, which should 404 if it does not exist (which it should).
Forgetting the trailing slash
/blog/foo and /blog/foo/ are technically different URLs. Many servers redirect one to the other, but the redirect itself counts. If you have many of these, consolidate by enforcing a single convention (with or without trailing slash) and redirecting the other form.
Bottom line
Broken URLs hurt users, hurt SEO, and waste crawl budget. Find them with Google Search Console and a site crawler. Fix them with 301 redirects (for renamed content), 410 Gone (for intentionally removed content), or restoration (for accidental deletion). Prevent them by always redirecting on deletion, using canonical URLs, and validating links before publishing. The Uttir URL tools help debug encoding issues that often underlie broken URLs.