HTTP Status Checker

An HTTP status code is a three-digit number a server returns with every response to tell the client what happened with the request. 200 means the page loaded successfully. 301 means the page moved permanently. 404 means the page was not found. 500 means the server crashed. The codes are part of the HTTP specification (RFC 9110) and every browser, crawler, and API client uses them to decide what to do next. There are 63 defined status codes split across five classes, but in real SEO work you see roughly ten of them regularly: 200, 301, 302, 307, 308, 403, 404, 410, 500, and 503. This http status checker reports the exact code returned for every URL you submit so you can fix the ones that should not be there.

The five classes are 1xx, 2xx, 3xx, 4xx, and 5xx. 1xx codes (100-103) are informational and tell the client the request was received and processing continues. You almost never see them in browser or SEO contexts. 2xx codes (200-226) mean success. 200 is the standard OK and the only one most sites use. 3xx codes (300-308) mean redirect, telling the client to fetch a different URL. 301 is permanent, 302 is temporary, 307 preserves the request method on a temporary redirect, and 308 preserves it on a permanent one. 4xx codes (400-451) mean the client made a bad request, with 404 (not found), 403 (forbidden), and 410 (gone) the most common. 5xx codes (500-511) mean the server failed, with 500 (internal error) and 503 (unavailable) the ones SEOs hit most often.

A 301 is a permanent redirect that tells search engines to update their index and pass full link equity to the new URL. A 302 is a temporary redirect that tells search engines to keep the old URL indexed because the move is not permanent. For SEO, almost every redirect should be a 301. Use 302 only for genuine temporary cases, like geo-redirects during a regional rollout or A/B test traffic splits. Google has confirmed that long-lived 302s are eventually treated as 301s, but the transition can take weeks, during which rankings can dip. If you ran a migration and your old URLs return 302, change them to 301 today. This redirect checker shows the exact code returned, so a quick bulk run on your old URL list confirms whether your redirect map uses the right type.

A 307 is a temporary redirect that preserves the original HTTP method, which means a POST stays a POST when the client follows the redirect. A 302 historically allowed clients to switch a POST to a GET, which broke form submissions. 307 fixed that. For SEO purposes, 307 behaves like 302: temporary, does not pass full link equity, keeps the old URL indexed. You will see 307s on sites that use server-side frameworks (Next.js, Nuxt, Django) for redirects, since those frameworks default to 307 for safety. If a 307 is meant to be permanent, switch it to 308 (the permanent equivalent) or 301. The url status code checker captures the exact code so you can spot 307s that should be 308 or 301 instead.

A 404 means the server cannot find the page right now and the client should not assume anything about the future. A 410 means the page is gone permanently and will never come back. For SEO, 410 is a stronger signal to Google to drop the URL from the index quickly. If you deliberately removed a page (discontinued product, deleted blog post, retired feature) and have no replacement, return 410 instead of 404. Google deindexes 410 URLs roughly 2x faster than 404 URLs based on multiple Search Central recommendations. If the page is genuinely missing by accident or temporarily down, 404 is the right code. This 200 301 404 checker reports both so you can switch deliberate removals from 404 to 410 and clean your index faster.

A 500 status code means the server hit an internal error it could not handle. Common causes include a crashed application process, a database connection failure, an unhandled exception in code, or a misconfigured server. 500 is generic, which means the response body usually has no useful diagnostic information. To debug, you need server logs. For SEO, 500s are crawl waste and a quality signal that hurts rankings if they persist. Google retries 500s for a while, then drops the URL from the index if the error continues. If your bulk checker run shows 500s on URLs that should work, check your server logs immediately. A 500 on a high-traffic page costs revenue and rankings every minute it stays broken. Run the http status checker after every deploy to catch 500s introduced by code changes.

A 503 means the server is temporarily unavailable, usually because of overload, maintenance, or a service degradation. Unlike a 500, which signals a real error, a 503 says "come back later." Properly configured 503s include a Retry-After header that tells crawlers when to try again. Google respects Retry-After and pauses crawling without dropping the URL from the index, as long as the 503 clears within a few hours. If 503s persist for more than 48 hours, Google starts treating them like 500s and drops the URLs. For planned maintenance, return a 503 with a Retry-After header set to the expected downtime. For unexpected 503s found by this checker, investigate server capacity, CDN configuration, or upstream service health.

Paste up to 50 URLs into the textarea in this http status checker, one per line, with the full protocol (https:// or http://). Pick whether to follow redirects, then hit Check statuses. The tool fetches every URL in parallel and returns a table with the status code, the redirect chain if any, the final URL after redirects, and the response time in milliseconds. For lists larger than 50, split them into batches. The bulk approach is roughly 30x faster than checking each URL one by one in a browser, and it surfaces patterns (every URL in a folder returning 404, every product page chaining through two redirects) that single-URL checks miss. Pair the output with the sitemap-checker to confirm your sitemap only lists 200s.

Pull a list of every URL on your site from your sitemap, your CMS, or a crawler like Screaming Frog. Split the list into batches of 50 and run each batch through this bulk http status checker. Group the results by status code class. Every 4xx is a broken page that needs a fix or a redirect. Every 5xx is a server problem that needs investigation. Every 3xx is either a working redirect or a chain that needs flattening. For sites under 1,000 pages, the full audit takes under an hour. For larger sites, prioritize URLs with inbound external links and pages that get organic traffic, since those are the ones that cost real visibility when broken. Re-run monthly to catch new breaks before they accumulate.

A redirect chain is a sequence of two or more redirects between the original URL and the final destination. URL A redirects to URL B, which redirects to URL C, which finally returns 200 at URL D. Each hop adds latency (typically 100-500ms per redirect) and dilutes link equity. Google has confirmed it follows up to 10 hops before giving up, but treats every hop as friction. Long chains slow down both users and crawlers. Fix chains by updating the original URL (URL A) to point directly to the final destination (URL D). This redirect checker shows the full chain when Follow redirects is set to Yes, so you can see exactly how many hops each URL goes through and flatten the ones longer than two.

A healthy redirect goes one hop, returns 301 (or 308 for non-GET requests), preserves the path structure where possible, and points to a relevant living page. The destination should return 200 and canonicalize to itself. The chain should not include 4xx, 5xx, or mixed protocols. For a migration, the redirect map should cover 100% of old URLs that received external links or organic traffic in the last 12 months. URLs that never had links can be allowed to 404. A 2023 SEMrush study of 200 site migrations found that sites with single-hop 301s and zero broken redirects retained 89% of organic traffic post-launch, while sites with chains longer than three hops or unmapped 404s retained only 51%.

For SEO, server response time (also called Time to First Byte or TTFB) should be under 800ms for a good user experience and under 200ms for an excellent one. Google's Core Web Vitals data shows pages with TTFB above 1,500ms rank measurably lower in competitive queries. This http status checker reports response time per URL so you can flag the slow ones. A 200 that takes 3,000ms to respond is technically alive but functionally broken. Common causes: unoptimized database queries, missing CDN, oversized server-rendered HTML, or geographic distance between server and crawler. Fix the slowest 10% of pages first since they usually share an underlying cause. Pair this tool with the google-crawler-simulator to confirm Googlebot sees the same response time you do.

curl is a command-line tool that can fetch any URL and show the status code with the right flags (curl -I -L https://example.com). It is powerful, free, and works for one URL at a time. A bulk http status checker like this one runs the same fetch against 50 URLs in parallel, captures the redirect chain in a readable table, times the response, and displays the result in a browser without typing flags. For a developer comfortable with the command line, curl is fine for spot checks. For SEO audits across hundreds of URLs, a bulk tool is roughly 30x faster and far easier to share with non-technical teammates. Both tools return the same status codes since both speak HTTP.

Yes. Open the Network tab in Chrome or Firefox devtools, load the URL, and look at the document request. Each redirect appears as a separate row with the status code (301, 302, 307) and the Location header pointing to the next URL. The final row is the page that returns 200. Devtools is excellent for debugging one URL at a time and seeing the exact request and response headers. It is impractical for checking 50 URLs because you have to reload each one and read the network log manually. For bulk audits use this redirect checker, which shows the same chain data in a table you can scan in seconds. Use devtools when you need full header detail and the bulk checker when you need scale.

Migrations break URLs. Even careful redirect maps miss edge cases: trailing slashes, case sensitivity, query strings, encoded characters, files in subfolders the new server forgot to copy. A bulk url status code checker run on the day of launch catches the first wave of breakage. A second run two weeks later catches the URLs that traffic patterns reveal. Sites that skip post-migration audits typically lose 20-40% of organic traffic in the first month and take 3-6 months to recover. Sites that audit immediately and fix within 48 hours usually retain 85%+ of traffic. Run this http status checker against your sitemap, your top 100 organic landing pages, and any URLs with external backlinks. Use the sitemap-checker to confirm the new sitemap only contains 200s.

Yes. This http status checker is free, requires no signup, and has no daily limit on how many batches you run. The only constraint is 50 URLs per run, which keeps the response fast and prevents abuse. For larger batches, split the URLs into groups of 50 and paste each one in turn. The tool runs server-side, which means it sees status codes the way Googlebot sees them, not the way your browser sees them after caching. Use it as often as you need: weekly for active sites, daily during migrations, and after every deploy to catch regressions. Pair it with the canonical-checker, sitemap-checker, and google-crawler-simulator for a full URL-level audit workflow.