Languages

Bulk HTTP Status Checker

Free, no signup. A site migration or audit turns up hundreds of URLs to check, one at a time is not an option. Paste up to 500 and get status codes, full redirect chains, and final destinations, with the SEO problems already flagged.

Built by Patrick Stox

Advanced: safe request headers

Up to 5 response-negotiation headers: Accept, Accept-Language, Cache-Control, and Pragma. Credentials, cookies, and X-* headers are refused. Headered checks are never cached or stored.

Request user-agent

A matching user-agent does not make this request originate from that crawler’s verified IP range.

follows redirects · max 5 hops
0 URLs

Example data — replace with your own, then press Check status codes

Checks run from our server; we fetch the URL you enter and don't keep the results. Re-running the same list within about ten minutes reuses a short-lived cache. Checks with custom headers deliberately bypass that cache. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.

Feedback
Report a bug

Found something broken in Http Status Checker? Let us know what happened — this goes straight to a private triage queue, not a public list.

What will be sent 
 No tool inputs, uploads, pasted source, complete results, query parameters, or URL fragments are attached automatically. You can edit or remove the selected passage above. Browser and anti-abuse metadata is processed for spam prevention. 
  
 
  
 
 
  
 
 
   
       
 
Sample report Illustrative status inventory — not a company audit
 
Say you paste four URLs:
 
 
https://example.com/old-trail-shoe
https://example.com/products/trail-runner
https://example.com/products/retired-boot
https://example.com/dead-link
 
 
…and the checker returns:
  
     
  • Two pages return 200 — that confirms successful HTTP responses, not
            necessarily healthy or indexable content. Inspect titles and rendered copy before calling
            either URL clean.
    •  
  • One URL cleanly 301-redirects. https://example.com/old-trail-shoe lands on
https://example.com/products/trail-runner in a single hop (green→amber dots show it) — expand the row for
            the full chain detail.
    •  
  • One is a dead 404, flagged in red as a broken link — the row most worth fixing
            first, since every internal link pointing at it is wasted.
    •  
  • Sort by status or expand any amber/red row to triage a big list fast instead of
            reading every line — see HTTP status codes for what
            each class means for SEO.
    •  
 
Soft-404 trap: green status, missing product
 

Suppose /products/retired-boot returns 200, but its title is
          “Product unavailable” and its body is the same empty shell used by thousands of retired
          SKUs. This checker correctly reports the HTTP response as successful; it does not pretend
          that status alone proves useful content. Cluster repeated titles/body templates with a
          crawler, inspect representative rendered pages, and confirm Google's classification in
          Search Console. The `.example` URL and scenario are illustrative.

 
 
 
How to use it
 
     
  1. Paste your URLs into the box, one per line — up to 500. The scheme is optional; a bare
example.com/pricing is treated as https://. Duplicate lines are removed
            automatically.
    2.  
  2. Or press Import sitemap, paste a sitemap.xml URL, and the tool
            pulls every <loc> into the list for you (capped at 500).
    3.  
  3. Pick the user-agent — default, browser, Googlebot, Bingbot, or the listed AI
            crawlers — if you want to compare an anonymous crawler response with a browser response.
    4.  
  4. For an opt-in content-negotiation check, open Advanced: safe request headers.
            It accepts only Accept, Accept-Language, Cache-Control, and
Pragma; credentials, cookies, and X-* headers are intentionally blocked.
            Those checks bypass the short-lived cache.
    5.  
  5. Press Check status codes. Results stream in per batch. Filter with the status
            chips (2xx / 3xx / 4xx / 5xx / error), sort by status, latency, or chain length,
            and expand any redirecting row to see every hop.
    6.  
  6. Use Export CSV for the full list — input URL, final status, final URL, redirect
            count, chain, latency, flags, and errors. Export a snapshot to compare a later run;
            the comparison calls out status changes, new 4xx rows, and chains that grew.
    7.  
 
 
 
       
     
       

Checks run from datacenter IPs at the edge — some bot-protected sites (Cloudflare
        challenges, WAFs, CDN bot rules) answer these requests differently than they would
        answer a real browser.

  
 
What the results mean
 
Every row's status pill is colored by its status class:
 
     
  • 2xx Successful final HTTP response (green) —
            the chain ended with a 2xx response, usually 200. That does not prove the content is healthy,
            useful, or indexable; inspect the chain dots, flags, title, and page content separately.
    •  
  • 3xx Terminal redirect response (amber) —
            the checker ended on a 3xx it could not or should not follow. A redirect chain that successfully
            lands on a 2xx page keeps the final 2xx pill; its chain dots, flags, and expanded hops show that
            redirects occurred.
    •  
  • 4xx Client error (red) — broken or missing
            (404), forbidden (403), gone (410). These are dead links to fix or remove.
    •  
  • 5xx Server error (red) — the server failed
            (500) or is unavailable (503). Often transient, worth re-checking.
    •  
  • ERR Connection error (red) — the request
            timed out, the host didn't resolve, or the site refused it.
    •  
 
Amber flags on a row call out specific redirect problems the tool detects, including:
 
     
  • Redirect chain — reduce to one hop — more than one redirect before the final page.
    •  
  • 302 in chain — a temporary redirect where a permanent 301 belongs, so signals
            never consolidate.
    •  
  • http → https → www multi-hop — a common canonicalization chain that should be
            collapsed to a single redirect straight to the final host.
    •  
  • Meta refresh — a client-side refresh on the final page that header-only tools miss.
    •  
  • Redirect loop and more than 5 redirects — shown as red error flags.
    •  
 
How it works
 

The page splits your list into batches of up to 25 URLs and posts them to a server-side checker (URL
          fetching can't run in your browser). Batches are dispatched at a deliberate pace, with no more than
          10 URLs for one host in a batch, and each completed batch streams back into the table. For each URL the
          checker requests it without auto-following redirects, records the status and
Location at every hop up to five, and reports the final status and destination. It also
          reads the final HTML for a meta refresh.

 

Everything after the fetch — the status-class chips, sorting, filtering, and CSV export — runs
          entirely in your browser. No URLs are stored, and re-running the same list within about ten minutes
          reuses a short-lived edge cache.

 
Features
 
     
  • Up to 500 URLs per run, checked in deliberately paced batches with per-batch progress.
    •  
  • Full redirect chain per URL — expand any row to see every hop, its code, and its target.
    •  
  • Status-class filter chips and sortable columns (status, latency, chain length).
    •  
  • SEO flags for long chains, 302-in-chain, multi-hop canonicalization, meta refresh, and loops.
    •  
  • Sitemap import that pulls URLs straight from a sitemap.xml.
    •  
  • Browser, search-bot, and AI-crawler user-agent choices; safe, bounded request-header overrides;
            CSV and local snapshot export.
    •  
  • Runs against public URLs only — no sign-in, nothing stored.
    •  
 
Limitations
 

Checks run from datacenter IPs at the edge, so bot-protected sites (Cloudflare challenges, WAFs, CDN
          bot rules) may answer differently than they would a real browser — and choosing the Googlebot
          user-agent doesn't make the request pass reverse-DNS verification. It follows the HTTP
chain plus one layer of meta refresh, not JavaScript redirects (window.location,
          framework routers won't appear). Each chain stops at five hops. It only reaches pages a public crawler
          could reach — login-gated, IP-restricted, or private addresses are refused. And the 500-URL cap plus a
          courtesy limit of 10 URLs per host per batch mean very large single-site lists are spread across
          multiple batches.

 
Frequently asked questions
 
How many URLs can I check at once?
Up to 500 URLs per run. Paste them one per line, or import them straight from a sitemap URLA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing.. The tool splits the list into batches of 25 and deliberately paces requests to avoid overwhelming one host or the checking service, so a full single-site run can take a couple of minutes. Duplicate lines are removed before checking.
What is the difference between the status code and the final URL?
The status codeAn HTTP status code is the three-digit number a server returns with every response to tell a browser or crawler what happened to its request — success, redirect, client error, or server error. For SEO the code matters as much as the content: it tells Google and Bing whether to index a page, follow a redirect, retry later, or drop the URL from the index. shown is the final status — the code of the page the URL actually lands on after following any redirects. The Final URL column shows where a redirecting URL ended up. If a URL redirects, the tool follows the whole chain (up to five hops) and reports the destination, not the first hop. Expand any row to see every hop and its individual code.
Why is my status code colored red or orange?
Rows are colored by status class. Green is 2xx (success), amber is 3xx (redirect), and red is 4xx (client errors like 404), 5xx (server errors like 503), or a connection error. The color lets you scan a large list and spot the broken and redirecting URLs without reading every code.
Does it check the status code a crawler sees?
It can send the browser, GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer., BingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share., GPTBot, ClaudeBot, or PerplexityBot user-agent string, which can surface crawler-specific rules. The request still comes from a datacenter IP, not that crawler's verified network, so IP-verifying sites may treat it as an unverified bot.
Are the URLs I paste stored anywhere?
No. URLs are sent to the checking endpoint only to fetch their status and are never saved. Filtering, sorting, and CSV export all run in your browser. Re-running the same list within about ten minutes reuses a short-lived cache so repeat checks are faster, but nothing is persisted to an account or database.
 
 
 
   
Next stepRedirect Map Builder — generate the corrected version.

People also explore
ToolSEO Incident SimulatorToolSEO Migration Planner & ValidatorToolCrawl Export ComparatorArticlePage with Redirect (GSC Status)ArticleURL Structure Migration SEOArticleSubdomain vs Subdirectory
 
 
 
Feature requests for Http Status Checker
 

Upvote what you want most. New ideas can be submitted from the floating Feedback menu;
      requests appear here once approved, and the most-wanted rise to the top.

   
Loading…
  
  ➕ Request a feature   
New requests are reviewed before they appear here.
 
     
  
  
 
 
 
 
   
   
 
Where this tool helps
Common use cases
Validate migration and launch URL lists
Check representative old and new URLs together, confirm their final destinations, and identify broken or unnecessarily long paths before launch evidence goes stale.
Prioritize 4xx, 5xx, and connection failures
Filter a large result set by response class so broken links, server errors, and requests that were not completed can be investigated without treating every failure as the same problem.
Trace and simplify redirect chains
Expand redirecting rows to inspect each observed hop, then replace temporary, looping, or multi-hop routes with the shortest correct permanent destination where appropriate.
Compare bounded crawler and language responses
Repeat an authorized check with a selected user-agent or allowlisted response-negotiation header while remembering that a name string does not make the request a verified crawler.
Compare status snapshots over time
Export a local baseline and compare a later run to surface changed statuses, new 4xx responses, longer chains, different final URLs, and changed error states.
Create an evidence-led remediation handoff
Export the exact input, final status, destination, chain, latency, flags, and errors, then validate content quality and indexability separately from the HTTP response.
Watch the full workflow
HTTP Status & Redirect Checker walkthrough
Read the transcript

      
      

        
HTTP Status & Redirect Checker

        

        
This beginner walkthrough explains what an H-T-T-P status checker observes, when to use it, how to import or paste a list, how to run a complete fictional check, how final statuses differ from redirect chains, how to filter failures and compare snapshots, and what a successful response still cannot prove.

      

      

        
Step 1

        

        
This tool checks up to five hundred public U-R-Ls and records the final H-T-T-P status, final destination, each observed redirect hop, total latency, and selected response evidence. It also flags common redirect problems. Use that evidence for migration checks and audits, but remember that it describes the response path, not the complete quality of the page.

      

      

        
Step 2

        

        
Use the checker to validate migration or launch lists, prioritize four-x-x, five-x-x, and connection failures, simplify redirect chains, compare bounded crawler or language responses, compare status snapshots over time, or create an evidence-led remediation handoff. Each use case keeps the exact U-R-L and observed response attached to the decision.

      

      

        
Step 3

        

        
Paste one public U-R-L per line, choose Try an example, or import a leaf sitemap. A bare domain is treated as H-T-T-P-S, duplicate lines are removed, and the run is capped at five hundred. The disclosure says checks run on the server, results are not kept, and ordinary repeats may use a short-lived ten-minute cache.

      

      

        
Step 4

        

        
Choose Import sitemap, enter a public leaf sitemap U-R-L, and fetch its page locations. The fictional sitemap adds six reserved dot-example addresses and updates the count to one batch. A sitemap index is rejected here; select one child sitemap at a time. Imported U-R-Ls are still only inputs and are not proof that search engines crawl or index them.

      

      

        
Step 5

        

        
Advanced mode accepts only response-negotiation headers such as Accept-Language, Accept, Cache-Control, and Pragma. Credentials, cookies, and X-prefixed headers are refused, and headered checks bypass the cache. You can also choose browser, search-bot, or A-I crawler user-agent strings. That changes the request label; it does not make the request originate from a verified crawler network.

      

      

        
Step 6

        

        
The sample report shows two final two-hundred responses, one clean three-oh-one redirect, and one broken four-oh-four. The status pill, input U-R-L, final destination, latency, chain dots, flags, and expand control all have different jobs. Sort or filter a large list to prioritize work, then expand any redirect or error before deciding what to change.

      

      

        
Step 7

        

        
The soft-four-oh-four example is essential. A retired product can return H-T-T-P two hundred while showing Product unavailable or a repeated empty template. This checker correctly reports the response as successful; it cannot prove that the content is useful or indexable. Inspect rendered content with a crawler and confirm search classification separately.

      

      

        
Step 8

        

        
The full workflow is: paste or import up to five hundred U-R-Ls, select a user-agent only when needed, optionally add safe headers, run the check, filter or sort the streamed results, expand redirect rows, and export C-S-V or a local snapshot. The snapshot can be compared with a later run to call out status and chain changes.

      

      

        
Step 9

        

        
The complete example contains six reserved dot-example U-R-Ls: a multi-hop redirect, a live product, a retired product that still returns two hundred, a dead link, a temporary server failure, and a host that cannot be resolved. Every endpoint response is fulfilled locally and every external response is blocked, so no public site is contacted.

      

      

        
Step 10

        

        
Choose Check status codes. The table appears while batches run, then the summary confirms six U-R-Ls checked with the browser profile. A live run may vary with the server, network path, cache, bot protection, or deployment state. The fixed local response makes the evidence identical across retakes.

      

      

        
Step 11

        

        
The chips count six evaluated rows: three ending in two-x-x, one four-x-x, one five-x-x, and one connection error. Three-x-x is zero because the redirecting old-product U-R-L ultimately lands on two hundred. The pill shows the final response; the colored dots and flags reveal that redirects happened earlier.

      

      

        
Step 12

        

        
Expand old-product to see H-T-T-P three-oh-one to an intermediate catalog U-R-L, then a temporary three-oh-two, then the final two-hundred trail-shoe page. The tool flags a two-hop chain and the temporary redirect. Replace that path with one intentional permanent redirect to the correct final destination when the migration requirements support it.

      

      

        
Step 13

        

        
Live-product and retired-product both end on two hundred. The table can preserve a bounded title in expanded evidence, but a green pill still cannot validate the rendered copy, canonical choice, indexing directives, template quality, or search-engine soft-four-oh-four classification. Treat it as a successful server response and continue the content review.

      

      

        
Step 14

        

        
Choose the four-x-x chip to isolate the dead-link row. Four-oh-four means the requested page is missing; fix or remove internal links, or restore the intended resource. Five-oh-three is a server-side failure that may be temporary and should be retested. A D-N-S, T-L-S, timeout, or refused connection produces an error row, but this snapshot alone cannot identify the complete root cause.

      

      

        
Step 15

        

        
Use the row control to open the exact chain, select four-x-x to isolate broken pages, then return to All. The other chips isolate terminal three-x-x, server errors, or requests with no usable response. Sorting by status, latency, or chain length changes the view only; it does not change the captured evidence.

      

      

        
Step 16

        

        
Import a previously exported local snapshot to compare the same U-R-Ls. This baseline reports four changed rows, one new four-x-x, and one chain that grew. It also names the final-destination and error-state changes. A comparison is a triage aid: confirm the baseline date, deployment context, and each current row before assigning a regression.

      

      

        
Step 17

        

        
Export C-S-V for the input, final status, final U-R-L, redirect count, chain, latency, flags, and errors. Export evidence package adds structured per-U-R-L acquisition evidence and a decisive result image. Export snapshot creates the local baseline used by Compare snapshot. Review every not-evaluated row separately; an absent observation must never be converted into a clean result.

      

      

        
Step 18

        

        
Two-x-x means the chain ended with a successful H-T-T-P response, not that the content is healthy. A terminal three-x-x means the checker ended on a redirect response it could not or should not follow. Four-x-x identifies client-side missing or forbidden resources, five-x-x identifies server failure, and E-R-R means no usable H-T-T-P response completed.

      

      

        
Step 19

        

        
The browser divides the list into batches of up to twenty-five, keeping one host to ten or fewer U-R-Ls per batch, and dispatches batches at a deliberate pace. The server requests each U-R-L without automatic redirect following, records status and Location at every hop up to five, and reads the final H-T-M-L for one layer of meta refresh. Filtering, sorting, and exports then run locally.

      

      

        
Step 20

        

        
The main features are five-hundred-U-R-L runs, paced batches with progress, full expandable redirect chains, status filters and sortable columns, redirect-problem flags, leaf-sitemap import, several user-agent profiles, bounded request-header overrides, C-S-V and evidence exports, and local snapshots for later comparison.

      

      

        
Step 21

        

        
Checks come from datacenter edge I-Ps, so bot protection may answer differently than a real browser. A Googlebot label is not a verified Googlebot network. The tool follows H-T-T-P plus one meta refresh layer, not JavaScript navigation, and stops after five hops. It refuses private or gated targets, cannot prove content quality or indexability, and cannot turn one latency or connection error into a complete diagnosis.

      

      

        
Read the final response and the path that produced it

        

        
Export the exact U-R-Ls, final statuses, destinations, redirect chains, latency observations, flags, and errors with your handoff. Fix broken links and redirect rules at the source, then rerun the same list. Use a crawler, rendered-page inspection, Search Console, logs, and monitoring to validate content, indexability, JavaScript behavior, and availability questions that an H-T-T-P response alone cannot answer.

      

    
 
          
 
Common issues & how to fix them
 
     
  •  Warning URL returns a redirect Fix: Update internal links to the final URL and use one intentional server-side redirect for obsolete addresses. 
  •  Error URL returns a 4xx response Fix: Correct the URL or restore the resource; return 410 only when permanent removal is intentional. 
  •  Error URL returns a 5xx response Fix: Fix the application, origin, or upstream failure until the URL returns a stable successful response. 
  •  Error URL has no usable HTTP response Fix: Resolve the DNS, TLS, timeout, or connection problem so the URL returns a usable HTTP response. 
  •  Error URL enters a redirect loop Fix: Change the conflicting redirect rules to one acyclic path ending at a live final URL. 
  •  Warning Final URL resolves to a different host Fix: Point the redirect to the intended canonical host or update the source URL if the cross-host move is deliberate. 
    •