Skip to content
Browse tools

SEO · Site architecture

Canonical Host Checker

Every site has four front doors — with and without www, over HTTP and HTTPS. Exactly one should open onto your page and the other three should send visitors to it. This checks which yours actually does.

Try one
  • Four real requests from our server, not your browser
  • Every hop recorded, nothing followed silently
  • No account, no logging of the domains you check
How this is measured. Four separate requests — http:// and https://, each with and without www — each followed hop by hop with automatic redirects switched off, so every status code and Location header is recorded rather than collapsed into a final answer. An address only counts as serving when it answers with a page at its own hostname; one that redirects and finds a page elsewhere is behaving correctly, not duplicating. The canonical tag is then read from whichever address actually serves, so the declared answer can be compared with the real one.
Enter a domain to see which of its four addresses serves your page, which redirect, and whether the rel=canonical tag agrees with what the server actually does.
WHY IT MATTERS

Four Addresses, One Page, Split Credit

A search engine treats example.com and www.example.com as two different sites until something tells it otherwise. If both answer with the same page, every link anyone has ever made to your content is divided between two addresses that each look half as popular as the real total. The fix is a permanent redirect from three of the four to the one you keep, and a rel="canonical" tag that names the same host. Which one you pick matters far less than picking one: www gives you cookie scoping and the freedom to CNAME the apex later, no-www is shorter. What causes real damage is choosing neither, or choosing one in your redirects and the other in your canonical tags — a mismatch that sends crawlers on a round trip for every internal link and quietly halves the value of both.

Related tools: Redirect Chain Checker · SSL Certificate Checker · SEO Checker Pro · Sitemap Checker

What else can you check?

These tools all work on the same connection and address data — pick whichever question you actually have.

Want to see the full path to a site? DNS, redirects, every hop, the CDN, TLS and the origin server. Want to know your public IP? See your IPv4 and IPv6 addresses, location, ISP and ASN. Want to check your tower & route? Live ping, speed, DNS, traceroute and a map of nearby points. Want to ping from around the world? Real latency from real probes across 12 countries, live on a map. Want to locate any IP address? City, region, country and coordinates for any public IP. Want to know if an IP is risky? Proxy, VPN, Tor, hosting and abuse-report indicators. Want to know if you're blacklisted? Check an address against major spam and abuse DNSBLs. Want to know who owns an IP? Network owner, ASN, CIDR range and abuse contact. Want to explore an AS number? Announced prefixes, BGP neighbours and registry details. Want to test your connection speed? Measure real download, upload, ping and jitter. Want to see what changed? Word-level diff between two blocks of text or code. Want to know if a DNS change is live yet? Compare answers from five independent public resolvers. Want to verify a domain's nameservers? Direct authoritative checks, glue records and SOA serials. Want to check a domain's DNSSEC setup? DNSKEY, DS records, signature expiry and real validation. Want to see the hop-by-hop path to a server? A real traceroute from a genuine probe anywhere in the world. Want to know if a server port is open? A real TCP connection attempt - open, closed or filtered. Want to measure latency to a server? Real connect timing - min/avg/max, jitter and connection loss. Want a clean URL slug from a title? Real transliteration, stop words and batch mode. Want to find and replace across a document? Regex, capture groups and a live preview before you commit. Want to find the invisible character? Code points, escapes, bytes and hidden-character detection. Want to escape text for HTML? Minimal, named or numeric entities, attribute-safe. Want to strip emoji cleanly? Whole clusters - no half-flags or stray modifiers left. Want to spot repeated words? Frequency, density and accidental doubles like "the the". Want to know if a URL is cached? Two requests prove whether your CDN is really caching it. Want to see what a site knows about you? Storage, cookies, tokens and what your browser actually cached. Want to run that check on any site? One-click bookmarklet reads storage and tokens where they live. Want to know who your site talks to? Renders the page and names every outside company it contacts. Want to tidy up a messy SQL query? Beautify, minify, lint and convert keyword casing for six dialects. Need to work out a percentage? Nine calculators covering every way a percentage gets asked. Want to work out a rise or a raise? Increases, growth, compounding and CAGR, with the working shown. Want to work out a discount or a drop? Discounts, stacked sales and depreciation, with the working shown. What is actually on that page? Words, reading time, readability, every image, embed and link. Need a favicon that works everywhere? Every size, a real multi-resolution .ico, and the tags to paste.
COMMON QUESTIONS

Canonical Host FAQ

Should I use www or not?

Either works. www lets you scope cookies away from the apex and CNAME it to a CDN, which the apex cannot always do. No-www is shorter. Pick whichever your canonical tags and sitemap already say — switching means asking search engines to re-attribute everything they have already consolidated.

Why 301 and not 302?

A 301 says permanent and passes ranking signals to the destination. A 302 says temporary, so the original address keeps the credit and the destination never accumulates any. For a host redirect that will never be reversed, 302 is simply the wrong code.

Isn't a canonical tag enough on its own?

It helps, and Google usually honours it, but it is a hint rather than an instruction. A redirect is unambiguous, works for every client rather than just crawlers, and stops the duplicate being reachable at all. Do both.

Why can't a browser tool do this?

Cross-origin rules block a page from reading another site's response headers, and fetch with manual redirect handling returns an opaque response with no status and no Location. The check has to run somewhere that is not a browser, which is why this one runs on our server.

My site loads fine but this says "content could not be read". Why?

Bot protection. Cloudflare, Akamai and similar services routinely answer 403 or 503 to a request coming from a datacentre IP even when the same page loads instantly in your browser. The redirect behaviour is still measured accurately — status codes and Location headers are returned before any challenge — so everything in the redirect map holds. Only the page-level checks, the rel=canonical read in particular, are unavailable.

Does the redirect slow my site down?

One hop costs one round trip, which is why it belongs at the edge or in the web server rather than in application code. What genuinely hurts is a chain — http to https to www to non-www is three round trips before a byte of content. Redirect straight to the final address.

What if my HTTPS redirect loops?

Almost always because a CDN terminates TLS and forwards plain HTTP to the origin, which then redirects to HTTPS, which the CDN serves again from cache. Do the HTTP to HTTPS redirect at the edge only, and keep the origin rule to host normalisation.