BYTESLIP ← Back
Notes // 006 · Site scores

meta.com’s 400 error page scored 75 on Inspectrosite

By Johnny · Byteslip · scan run

After google.com, wikipedia.org, hawaii.gov, amazon.com, and ebay.com, I pointed Inspectrosite at meta.com — the address people type. It came back with 75 out of 100, grade C. That number is real, but it isn’t a score of Meta’s company homepage.

meta.com Inspectrosite score on byteslip.org

Quick disclosure: Inspectrosite is Byteslip’s own free browser tool. The badge above is just a picture of the score from our scan, not proof of anything (anyone can type a number into a badge link). The real record is the scan itself, and you can run it again here.

Context // What got scored

A redirect, then a 400 “Error | Meta” shell

We started at https://meta.com/. The server sent a normal HTTP redirect to https://www.meta.com/. Inspectrosite follows those, the same way it did for google.com → www.google.com, amazon.com → www.amazon.com, and ebay.com → www.ebay.com.

What came back was not the company homepage. The response was HTTP 400 and a large JavaScript document titled “Error | Meta” — about 212.5 KB (217598 bytes). The root element is <html id="facebook" … lang="en" dir="ltr">, which is Meta’s shared Facebook/Meta frontend. After scripts and styles are stripped, there is almost no HTML text left: a title, a favicon, a viewport meta, a <meta name="bingbot" content="noarchive" /> (not a noindex), CSS/script preloads from static.xx.fbcdn.net, and a hidden #has-finished-comet-page div. Visible word count is ~0 because the UI would be drawn by JavaScript. External scripts are the usual fbcdn.net / rsrc.php style URLs. A proxy-status header of http_request_error goes with that 400 — the edge treated the incoming request as a bad request and served this error shell.

It ran 53 checks: 27 passed, 9 warned, 7 failed, and 10 were info only. The HTML came back in 2926 ms (including our proxy). Inventory: 71 scripts (41 external, 30 inline), 0 images, 1 stylesheet, 0 links, 0 forms, ~0 visible words. Detected tech (info only): “No common CMS/framework fingerprints.”

Same number as google.com’s 75, but Google’s 75 was the real search homepage. Meta’s 75 is the error shell. Side by side with the other edge stories: Amazon’s bot-check page scored 82 (HTTP 202 WAF challenge, still treated as reachable); eBay’s 403 error page scored 78 (a small static “Error Page | eBay”). Meta’s error page is the heavy JavaScript cousin of eBay’s short 403 document.

Findings // The seven fails

The seven fails, in plain language

All seven match an error shell that never meant to be a homepage.

  1. Page is reachable (HTTP 400)

    The server returned HTTP 400. Browsers may show an error page. For Inspectrosite, that means the reachability check itself fails — unlike Amazon’s 202 challenge, which still counted as reachable.

  2. Missing <meta charset>

    No charset declaration in the HTML. Honest note: the HTTP Content-Type header did include charset=utf-8. Inspectrosite looks for the HTML <meta charset> tag, so this still fails.

  3. Missing meta description

    No meta[name=description]. For a JS-drawn error shell with almost no HTML text, that isn’t surprising — but the check still fails it.

  4. No <h1> heading

    There is no <h1>. The body is almost empty of HTML text; any heading would have been drawn by JavaScript after load.

  5. 0/4 landmarks (header, nav, main, footer)

    Found: header:false · nav:false · main:false · footer:false. Landmarks let keyboard/screen-reader users jump around; this shell doesn’t ship them in the HTML.

  6. Inline JS totals 172.7 KB

    A lot of JavaScript is inline, which can’t be cached between pages and bloats every load. On Meta’s usual stack that is expected plumbing — Inspectrosite still flags the size.

  7. 72 blocking resources (71 JS + 1 CSS)

    Each file costs a round-trip. The page loads 71 scripts plus one stylesheet. Separately, “No render-blocking scripts in <head>” still passed — external scripts use defer/async, modules, or sit at the end of the body — even though this overall blocking-resources count failed.

Findings // Warnings

Nine warnings, grouped

Findings // Indexing note

No noindex — but HTTP 400 still blocks ordinary indexing

Two facts are both true. SEO’s “Page is indexable” passes because there is no noindex meta and no X-Robots-Tag. The indexing verdict is still blocked because of HTTP 400 — Googlebot needs a 2xx response with the real content. robots.txt was fetched (HTTP 200, 3.4 KB, 10 groups) and allows this path; it lists 31 sitemaps (not fetched). Contrast with eBay’s error page, which set noindex,nofollow. This is not a claim that Meta “wants this error page indexed.”

Findings // What looked solid

What looked solid about that error response

Context // What the number means

75 is a check average, not a grade of Meta

Inspectrosite’s score is an average of the checks that count: a pass is worth 100, a warning 60, a fail 0, and info checks are left out. So 75 tells you how this one HTTP 400 “Error | Meta” page did on our checklist. It isn’t a grade for Meta as a company, and it says nothing about Facebook, Instagram, WhatsApp, or Quest.

Side by side with the earlier notes: google.com scored 75 on the real search homepage; wikipedia.org scored 89 on the real portal; hawaii.gov scored 67 / portal 91 because the short URL was a meta-refresh hop; amazon.com’s bot-check page scored 82; ebay.com’s 403 error page scored 78. Meta’s 75 belongs with Amazon and eBay: the scanner scored what it was served, which was not the page a visitor normally sees. One score only — 75 on the error shell. We did not try to craft extra headers, bypass the 400, or invent a second “real homepage” score.

Try it // Re-scan

Scores change

This is one scan, taken at 2:51 AM Hawaii time (HST) on November 6, 2026. Meta can change what it serves the proxy, and Inspectrosite gets updates too. A re-scan may still get this error page, or someday the homepage. Re-scan meta.com, or try your own site.

← All Notes Re-scan meta.com Inspectrosite guide