Tool · tool guide

Website Health Check: Separate Availability from SEO

Run a website health check that separates HTTP availability, indexability, markup validity, and page signals instead of compressing them into one score.

Published Updated 11 min readBy William Zhu & InfiniSynapse Data Team

Author credentials: William Zhu is cofounder of InfiniSynapse (GitHub @allwefantasy · auto-coder). Desk: shipping SEO Health and the /en/tool/ visibility pages. No personal LinkedIn published. About: team / editorial standards.

Publisher credentials: InfiniSynapse has public profiles on GitHub, YouTube, and X. A 2026 WAIC Future Tech OPC excellence award covers the Agentic Data Infra entry (WAIC; third-party recap: Xinhua / Caohejing). That award does not review this page or SEO Health. Method CLI: infinitegrowth on npm. Archive: recognition and scope notes.

Website Health Check: Separate Availability from SEO
On this page

By William Zhu · Cofounder, InfiniSynapse · Published: 2026-09-11 · Last updated: 2026-09-14 · Last verified: 2026-09-14 · Reviewed by the InfiniSynapse Data Team.

Reviewed by: InfiniSynapse Data Team · method review 2026-09-14. First-party curl of InfiniSynapse public URLs plus one hub CLI check; no uptime vendor and no Search Console export.

Trust / COI: About · Corrections. SEO Health is a commercial product from this team. A 200 on our own host is not a customer outage report and not proof Google stored the URL.

TL;DR

A 200 from this host is not a health certificate. HTTP delivery only says the process answered. A website health check still has to read the title, the robots header, and the first HTML bytes.

Direct answer: Treat a website health check as independent layers. Status, robots, title honesty, and page lights are separate facts. A live homepage does not excuse a 404 that reprints the same title, and a robots file that answers 200 can still carry noindex on the file itself.

The 2026-09-14 desk used curl as InfiniSynapse-P2-desk/2026-09-14 on InfiniSynapse public URLs. The sample size is eight public requests plus one CLI document on the hub URL. That sample cannot establish how often other templates reprint the homepage title, and it does not prove Google stored any path. Reproduce the hops with curl -sSI and curl -L. Those codes are transport, not a vendor 100.

What you will learn

  • Which first-party paths answered 200, 308, 301, or 404
  • Why the invented /en/ miss still wore the homepage title
  • What robots.txt declared while wearing x-robots-tag: noindex, nofollow
  • When a CLI exit 0 still leaves an alt warning
  • Where this website health check page stops and a sibling owns the queue

Do not flatten those five bullets into one color. The 2026-09-14 desk already shows a live 200, a correct 308, a robots file that is 200 and noindex, and a miss that 404s with the homepage title. Those four facts cannot share a badge. Keep them on one row with four columns.

What healthy is not

Key definition: A website health check is a layered read of delivery, eligibility, document honesty, and specialist signals on a bounded public sample. It is not an uptime badge, not a Core Web Vitals contest, and not an official Google grade.

MDN HTTP status is the vocabulary we used for first status and terminal status. Google’s block-indexing guide is the public reminder that a retrieved URL can still ask not to be kept. Neither page grades this host.

People open a website health check when a stakeholder says “the site is down” and the real ticket is a leftover hop, a polite 404, or a robots header on the wrong file. They do not need a blended color.

SEO Health remains the measurement layer for one-URL lights. After those rows exist, a team may send the export into an InfiniSynapse Server API long-task workspace; the API does not refetch status or override any observation.

Status is delivery

A 200 means the host returned a body. A 308 means the host named a next hop. A 404 means the final document is gone. None of those codes is a keep vote. A website health check that stops at the first digit is already late.

Title is not a diagnosis

The invented path on this host finished as a blog 404 and still printed the homepage title. That mismatch is a classification finding. It is not proof the homepage itself is broken. File the title next to the status. Do not average them.

First-party fetches on 2026-09-14

User-agent InfiniSynapse-P2-desk/2026-09-14 requested eight public addresses without following unless noted.

Requested URLFirst statusNote
/200Homepage title; 91,875 bytes
/en308Location /
/en/tool/seo-website-audit200Hub title; 95,445 bytes
/en/blog/seo-website-audit308Location /en/tool/seo-website-audit
/en/tool/seo-audit-tool20087,057 bytes
/en/blog/what-is-a-data-agent200Blog template; 93,934 bytes
invented /en/this-path-…-p2-20260914301Then /en/blog/… 404; title = homepage title; 17,292 bytes
/robots.txt200938 bytes; x-robots-tag: noindex, nofollow

robots.txt allowed / and disallowed /auth/, /api/, /v1/, /webhooks/, /dashboard, /analyze, and /Volumes/. It named three Sitemap lines. All three maps answered 200. The main map held 1,568 <loc> values. Across the three files the total was 1,738. Those loc counts are inventory. They are not a website health check of every template.

The robots response itself wore x-robots-tag: noindex, nofollow. That header labels the robots document, not the HTML addresses sitting inside the maps. A website health check that treats “robots 200” as “the site is indexable” has already mixed two layers.

Grouped bars for first-party 2026-09-14 fetches: first HTTP status beside response bytes

Figure: Two series from the same curl desk. First status is not body size. Neither series is a site-wide health score.

How we fetched

curl -sSI -A 'InfiniSynapse-P2-desk/2026-09-14' \
  https://infinisynapse.com/en/this-path-should-not-exist-p2-20260914

Follow the Location once. The blog URL answered 404. The 404 HTML title matched the homepage title. Record the user-agent, the first status, the Location, the final status, and the final title. A later bot can see different HTML. As of 2026-09-14 those five fields matched this desk.

What the CLI still warned

The same afternoon, npx --yes -p infinitegrowth@0.1.1 seo-health check --format json --lang en against https://infinisynapse.com/en/tool/seo-website-audit exited 0. Cached false. JSON about 71 KB. Title 51 characters. Words 2,530. Speed 79. Images 5, missing alt 2. Issues: 0 error, 1 warning (Image Alt Text), 7 good.

Exit 0 is transport plus a completed document. It is not a clean website health check. The warning still belongs on the row. We did not run audit --pages 50. Help text documents that range. A range is not a completed crawl.

Why 200 still fails

/ answered 200. The hub tool URL answered 200. The blog article answered 200. Those three rows still need eligibility and document checks. A leftover noindex on a 200 is a keep refusal, not an outage. Google’s block-indexing guide is why we open robots meta after status, not instead of status.

The invented miss answered 301 first. Courtesy routing hid the 404 until the second hop. A website health check that only records the first code will call that path “moved” and skip the dishonest title.

/en answered 308 to /. That is a correct collapse, not downtime. Do not file it as a broken locale. The SEO website audit hub owns the inventory that explains why those hops exist. This website health check owns the layer split.

A 200 can still be slow, inaccessible, or markup-invalid. Those facts belong to specialist tools. They do not rewrite the first status. web.dev performance is the public performance curriculum we point to after delivery is honest. It does not replace curl -sSI.

The hub CLI makes the same point in another vocabulary. Exit 0, speed 79, and one Image Alt Text warning sat on a 200. A website health check that files “green” because the process finished has ignored the warning column. Keep speed in the performance cell. Keep the warning in the document cell. Do not let either cell rewrite the first status.

Bytes are context, not health. / was 91,875 bytes. The invented 404 was 17,292 bytes and still wore the homepage title. Smaller is not healthier. A website health check that sorts URLs by body size is sorting the wrong axis.

Four layers that stay separate

Transport first

Resolve DNS and TLS. Capture first status, Location, hop count, MIME type, and bytes. Unavailable URLs do not proceed to copy diagnosis. This first layer is the start of every website health check. MDN HTTP status stays the label set.

Eligibility second

Inspect robots.txt, robots meta, X-Robots-Tag, and canonical only after the URL has stopped moving. The robots file on this host answered 200 and still asked not to be indexed as a document. That is legal and expected. It is not a site-wide refuse. A website health check that never opens the header will miss it.

Document body third

Confirm the rendered title, one primary heading, and whether the body matches the status. The 404 that reprints the homepage title fails this layer while passing a naive “we got HTML” test. Keep the title string on the website health check row.

Specialist tests last

Send performance to lab or field tooling, headers to an observatory, markup to a validator, and TLS to a scanner. Mozilla HTTP Observatory is one header surface. W3C Markup Validation Service is one markup surface. Qualys SSL Labs is one TLS surface. None of those tools is a testimonial for this website health check, and none of them should be averaged into the first status.

How to read a health row

Record one website health check row per URL and one column per layer. Use pass, fail, blocked, not applicable, and not tested. A 503 makes rendered headings unknown, not failed. An intentional noindex on a utility file can be acceptable even when every document check would pass. Timestamp every state other than pass.

Route the earliest broken dependency. DNS, TLS, timeout, and final-status failures belong with infrastructure. Robots and canonical conflicts belong with publishing. Dishonest titles belong with the template owner. Performance and markup retain their own owners. After the earliest blocker is repaired, rerun from that layer forward. Do not carry an old Lighthouse number across a new 404.

A website health check that publishes one percent has already destroyed the matrix. The SEO audit checklist page owns the order of those tickets. This website health check owns the refusal to blend them.

Read coverage by template. A clean homepage does not excuse an untested tool URL. The seo site audit page owns template mapping. Eight fetches cannot establish how often the 1,131 blog locs reprint a homepage title. Write n beside N.

Rerun the affected URL after the earliest blocker is repaired. If routing changed, the old title string is stale. If robots changed, the old eligibility cell is stale. A website health check that copies yesterday’s matrix onto today’s 308 is filing theater. Keep the new curl beside the old row instead of overwriting it.

When two people repeat the same eight requests, they should see the same first codes unless a release shipped between them. That repeatability is the point. Narrative priority lists are a different job and belong after the matrix exists.

Failure modes that fake uptime

Equating HTTP 200 with healthy. Delivery is layer one. The hub URL was 200 and still carried two missing alts.

Scoring a noindex file as a content failure. The robots response asked not to be indexed. That can be correct.

Calling a 308 downtime. /en collapsed to / in one hop. File it as a keep-path fact.

Soft 404 politeness. A gone URL that reprints the homepage title still needs a classification cell. Status was honest on the final hop. The title was not.

Averaging specialist tools into one badge. Observatory, validator, and SSL Labs answers are different jobs. Keep them off the availability cell.

Homepage-only confidence. / was 200. The invented path was not. A website health check that never leaves the apex will miss the polite miss.

Sitemap count as health. 1,568 locs are a list. Health still needs fetches.

Lab performance as availability. A Lighthouse number on a 200 does not explain the invented 404. Keep web.dev performance in the specialist column of a website health check, not in the first-status cell.

Observatory as SEO. Mozilla HTTP Observatory grades headers. It does not decide whether the 404 title is honest. File it with W3C validation and SSL Labs as routed work, not as a replacement layer.

Adjacent guides

This website health check returns to the SEO website audit hub for inventory and sample rules. Narrower jobs stay on siblings.

Job you actually haveGuide to open next
Declared maps and strataSEO website audit
First status before lightsSEO audit checklist
Template map before a crawlseo site audit

Read status before you rewrite the title

Capture first status, Location, robots, and the HTML title on a public URL. Then enlarge the sample only if templates disagree.

Run SEO Health Checker

Use only authorized, sanitized data. Do not paste secrets.

Frequently Asked Questions

Is HTTP 200 enough for a website health check?

No. HTTP 200 proves a response was delivered. A website health check still needs eligibility, title honesty, and specialist signals as separate columns. The hub URL on 2026-09-14 was 200 and still had an alt warning.

Does robots.txt 200 mean the HTML is indexable?

No. This host’s robots file answered 200 and still carried x-robots-tag: noindex, nofollow on the file itself. That header does not noindex every HTML URL in the maps. Read the header and the HTML robots meta as different fields.

Should health collapse into one score?

A website health check should avoid an opaque composite. Publish layer states so owners know whether the repair belongs to infrastructure, publishing, frontend, or content. A blended percent hides the earliest blocker.

When should copy review start?

Only after the intended page is available, eligible, canonicalized correctly, and rendered with a title that matches the status. The invented 404 on this host failed that test before anyone opened a copy doc.

Can a public checker test staging safely?

Not by default. Do not submit credentials, signed links, internal hosts, or confidential previews. Use an authorized local path instead. Once the layered row exists, a credited memo may be opened once in the InfiniSynapse web app.

Conclusion

Use a website health check when the job is to separate delivery from eligibility and document honesty. The 2026-09-14 desk shows live 200s, a locale 308, a robots file that is 200 and noindex, and an invented path that 404s with the homepage title. Close the website health check when first status, Location, robots header, and title are still visible as separate fields. A layered row is more useful than an unsupported green badge.

Keep the user-agent on the row. A later bot can see different HTML. This desk used one string. It cannot stand in for Googlebot. If you need property-level membership, open URL Inspection on the keep URL and keep that screenshot beside the curl. Do not paste the Inspection GIF into this website health check as if it were the hop table.

WZ

William Zhu · Cofounder, InfiniSynapse · GitHub @allwefantasy

Desk-validated SEO Health methods. Corrections: zhuhl@infinisynapse.com · corrections policy.

Website Health Check: Separate Availability from SEO