URL Checker: Read It and Fix It

A URL checker inspects one web address and tells you whether it is healthy: does it return the right status code, does it redirect, can Google index it, and does it point where you think it points. Run it before you publish a link, migrate a page, or wonder why traffic vanished. This guide explains every signal a URL checker reports and how to fix each one, using free tools by name.

What a URL checker looks at

A single web address carries a surprising amount of technical baggage, and a URL checker unpacks it. When you submit an address, the tool makes a request just like a browser or a search crawler would, then reports back on the response. The signals worth reading are the HTTP status code, any redirects the request passed through, the final destination, the canonical tag the page declares, whether the page allows indexing, and whether it renders well on mobile.

Each of those answers a different question. The status code tells you if the page exists. The redirect chain tells you if visitors and crawlers are being bounced around before they arrive. The canonical tells you which version of the page Google should treat as the master copy. Indexability tells you if the page is even eligible to appear in search. Read them together and you have a complete health snapshot of one URL.

The status code is the headline

The first thing any URL checker returns is a three-digit HTTP status code, and it frames everything else. The codes you will meet most often, defined in the MDN HTTP status reference, are:

• 200 OK. The page exists and the server delivered it. This is what you want for any address you expect people to visit and Google to index.
• 301 Moved Permanently. The address has permanently moved and the new location is given in the response. Use this for retired URLs you want to redirect for good.
• 302 Found. A temporary redirect. The original address should be used again in future. Reserve it for genuinely short-term moves.
• 404 Not Found. The server cannot find the resource. Common, and not automatically harmful, but a problem when real links or old rankings point at it.
• 5xx server errors. The server itself failed. These are urgent because they block visitors and crawlers alike.

Confusing 301 and 302 is one of the most common and costly mistakes in this area, so it gets its own section below.

301 versus 302: get this right

The difference between a permanent and a temporary redirect is not cosmetic. A 301 tells search engines the move is permanent, so they should transfer the old page's ranking signals to the new address and update their index. A 302 tells them the move is temporary, so they keep the old address indexed and do not fully pass the signals across.

The classic error is using a 302 for a permanent move, for example during a site migration or a URL rename. Google keeps indexing the old address, the new one struggles to gain traction, and rankings stall. If a URL checker shows a 302 on an address you have moved for good, change it to a 301. The MDN redirections guide also warns against redirect loops, where addresses point at each other endlessly and no page is ever reached. For a deeper walkthrough of diagnosing redirect chains, a dedicated HTTP redirect checker workflow is the right next step, and you can trace multi-hop chains with a URL redirection check.

Free URL checkers worth using

You do not need paid software to inspect a URL properly. These free tools cover the job honestly:

• Google Search Console URL Inspection. The single most authoritative free option. It shows the exact status Google saw, whether the page is indexed, which canonical Google chose, and a live test you can run on demand. Nothing else tells you how Google itself treats the address.
• Your browser's developer tools. Open the Network tab, load the URL, and read the status code and redirect chain directly from the request. Free, built in, and instant.
• Bing Webmaster Tools URL Inspection. The Bing equivalent, useful because Bing data also feeds other engines and answer products.
• Screaming Frog SEO Spider free tier. Crawls up to five hundred URLs at once and reports status codes, redirects, canonicals, and indexability in bulk, which is ideal when you need to check many addresses rather than one.

These report reality. They do not invent scores, and each one shows you the same underlying HTTP truth that a browser or crawler sees.

Fixing what the URL checker finds

Every finding maps to a fix. Here are the common ones.

A 404 on a URL that has inbound links or old rankings. Do not leave it. If an equivalent page exists, add a 301 redirect from the dead address to it. If nothing equivalent exists, decide whether to recreate the content or let it go, but never redirect it to an unrelated page just to avoid the 404. For the full playbook on this, see the guide to 404 Not Found errors and how to fix them.

A long redirect chain. If a URL passes through two, three, or more hops before landing, each hop slows the page and dilutes signals. Point the first address straight at the final destination in a single 301. Chains often build up quietly over years of migrations, so audit them periodically.

A wrong or missing canonical. If the checker shows the page pointing its canonical at a different or unexpected URL, Google may index the wrong version. Make sure each page's canonical points at its own preferred address, and that duplicates point at the master.

A page blocked from indexing. If a URL you want in search returns a noindex tag or is disallowed in robots.txt, it will never rank. Remove the block only for pages you genuinely want indexed, and keep it for thin or private ones. A broader website SEO checker pass helps you catch these at scale.

Build URL checking into your workflow

URL checking is not a one-off. Fold it into the moments where broken addresses do the most damage:

1. Before publishing, check every outbound link in the piece so you never ship a dead reference. Broken links quietly erode trust, as covered in the guide to broken links and their SEO impact.
2. Before and after any migration, snapshot the status codes of your key URLs so you can prove every one either stayed 200 or redirected cleanly with a 301.
3. On a monthly cadence, crawl the site with a free tool and pull a list of every non-200 response to triage.
4. Whenever traffic to a page drops sharply, inspect the URL first. A silent switch to noindex or a botched redirect explains a surprising share of sudden losses.

Frequently asked questions

What is the best free URL checker?

For SEO purposes, the URL Inspection tool in Google Search Console is the best free option because it shows exactly how Google sees the address, including its status, indexability, and chosen canonical. For a quick status and redirect read, your browser's developer tools Network tab works instantly, and Screaming Frog's free tier handles bulk checks.

What does it mean when a URL checker returns a 404?

A 404 means the server cannot find the resource at that address. It is not always harmful, but it becomes a problem when other sites link to the URL or it used to rank, because those visitors and signals hit a dead end. Fix it by redirecting the address with a 301 to an equivalent page or by restoring the content.

What is the difference between a 301 and a 302 redirect?

A 301 is a permanent redirect: the page has moved for good, so search engines should pass ranking signals to the new address and update their index. A 302 is temporary: the original address should be used again later, so engines keep it indexed. Use a 301 for permanent moves and reserve 302 for genuinely short-term situations.

Does 404Pulse offer its own URL checking tool?

No. 404Pulse is an educational blog and does not sell a URL tool. This guide explains how to read and act on the output of any URL checker using free tools such as Google Search Console, browser developer tools, and the free tier of Screaming Frog.

Why does my URL return 200 but still not appear in Google?

A healthy 200 status only means the server delivered the page. The URL can still be excluded from search if it carries a noindex tag, is blocked in robots.txt, has a canonical pointing elsewhere, or simply has not been crawled yet. Use Search Console's URL Inspection to see which of those applies.