The Plain Fetch viewer

In short

The viewer requests a URL the way a plain-fetch agent does: no JavaScript, one request for HTML, one for markdown, one for llms.txt and one for a path that should not exist. It shows the initial HTML on the left, the readable text on the right, and seven flags underneath.

Pre-loaded with www.wikipedia.org, read 4 November 2026. Type any public URL to run your own.

GET https://sportybet.com/ answered 500 with text/html, 6.5 KB, 3 redirects, read 8 November 2026, 14:25 UTC. Final URL: https://www.sportybet.com/ng/.

Permalink: /viewer/?url=https://sportybet.com/

A plain-fetch client does not get the heading: 1 of 6 checks found.

Initial HTML what a plain fetch receives

<html>
<head>
<meta name="viewport" content="width=device-width, target-densitydpi=high-dpi,initial-scale=1.0,maximum-scale=1.0,user-scalable=no,minimal-ui" >
[... 1 more head element folded ...]
</head>
<body class="ke" data-gr-c-s-loaded="true">
  <div class="error-page-container">
    <div class="page-head">
      <div class="error-title-container">
        <div class="error-title-1">
          50X
        </div>
        <div class="error-title-2">ERROR</div>
      </div>
      <div class="sb img-container">
        <img class="hide" src="//s.sporty.net/global/main/modules/main/desktop/page50x/img/encore_500.e831f94649.png" />
        <img class="hide" src="//s.sporty.net/global/main/modules/main/desktop/page50x/img/PC_500.feffed9c4c.png" />
      </div>
    </div>
    <div class="page-body">
      <div class="error-message-title">
        Uh...
      </div>
      <div class="error-message-container">
        <span class="error-message">
          Something went wrong and ball is deflated. Developers have been informed about this and will correct the issue. Please try again. Thank you!
        </span>
        <a id="back-btn">Go Back</a>
      </div>
    </div>
  </div>

  <script>[... 2,579 characters folded ...]</script>
</body>
</html>

Shown with 3 long blocks (scripts, styles, long tags) folded into a marker that says how many characters they hide.

Reading view the text a plain-fetch client can extract

title: none in the initial HTML

No H1 in the initial HTML

50X ERROR Uh... Something went wrong and ball is deflated. Developers have been informed about this and will correct the issue. Please try again. Thank you! Go Back

28 words in all.

1 found, 4 missing, 2 notes, from 7 checks run

H1Missing
200 wordsMissing
llms.txtNote
MarkdownMissing
Missing pathFound
JSON-LDMissing
OpenAPINote

What a plain fetch found on sportybet.com
Check	Result	Detail
H1 in the initial HTML	Missing not read	The home page answered 500.
First 200 words in the initial HTML	Missing not read	The home page answered 500.
llms.txt present and linked	Note present, not linked	4499 bytes, 12 links. Structure grade B (5 of 6). Nothing on the home page points to it. Ora's lab found 86 percent of llms.txt fetches arrived through a link.
Markdown on request	Missing 500 text/html	Accept: text/markdown returned 500 with text/html. The server ignores the header.
Status of a made-up path	Found 404	/agent-ready-html-missing-path-check returned 404: a real status code for a missing page.
JSON-LD types	Missing none	No JSON-LD block on the home page. Ora's lab found it made no difference when the answer was already in the HTML; Google says it is not needed for AI features.
OpenAPI link	Note none on the home page	No OpenAPI link on the home page. It matters only for a site that ships an API.

Run the full check

The viewer read one page with four requests. The full check we recommend next is Ora's scan. Its Access layer runs 42 checks worth 30 of its 100 points, among them content without JavaScript, bot detection, llms.txt, markdown on request, JSON-LD and the sitemap (Ora's check catalogue, contract 1.38.0, read 5 November 2026). Open Ora's report for sportybet.com.

Limits: Ora reads public URLs only, says two runs of one scan land within a couple of points without publishing repeat-scan data, and keeps the product that fixes what it finds behind a waitlist. Cloudflare's scanner at isitagentready.com is a quick free alternative, and Mintlify's score covers documentation.

What the viewer does

It sends four plain GET requests with the user agent Mozilla/5.0 (compatible; agent-readiness-crawl/1.0): the URL itself, the same URL with Accept: text/markdown, /llms.txt on the same host, and a made-up path at the root. It runs no JavaScript. The left pane is the first bytes of the HTML as text, with long scripts and styles folded into a marker that says how many characters they hide. The H1 and the first 200 words of visible text are marked in both panes. The flags under the panes say what the four responses added up to.

Limits

Ten seconds for all four requests together, 1.5 MB read from the home page, at most five redirects, each one checked again.
http and https only, default ports only. Private, local and internal addresses and names are refused.
Ten runs per address per minute. The counter lives in memory on the edge function, so it is per instance rather than global. Past ten you get a 429 with a Retry-After header.
Results are cached for 24 hours by the response headers. Nothing is written to a database: the viewer keeps the first 200 words and the extracted fields for the length of the request and keeps no page body beyond that.

What it does not tell you

A plain fetch from this server is not a real agent. Bot protection weighs the source address more than the user agent, so a page that answers 200 here can still refuse an agent, and the reverse. Ora's lab found (2026-10-19) that returning 403 to agent user agents and hiding the answer in JavaScript were the only two of 19 configurations that stopped retrieval; the viewer can see the second, and can only hint at the first. The initial HTML reference covers both. The server logs and the published crawler address ranges settle the first.

The seven flags

H1 in the initial HTML: Whether the HTML the server sends already contains an H1. It is the cheapest sign that the page does not depend on scripts to say what it is.
First 200 words in the initial HTML: Whether at least 200 words of visible text arrive in the initial HTML. Under 40 words with an app root element is flagged as a JavaScript shell.
llms.txt present and linked: Whether /llms.txt answers with a plain-text file, whether the home page links it (an anchor, a link element or a Link header), and the structure grade the index uses.
Markdown on request: Whether a request with Accept: text/markdown comes back as text/markdown. Cloudflare Radar found 3.9 percent of scanned top sites passing this at its April 2026 launch.
Status of a made-up path: Whether a path that should not exist returns 404 or 410. A 200 is a soft 404 and reads as a live page.
JSON-LD types: The schema.org types found in JSON-LD blocks on the page. Ora's lab found JSON-LD made no difference when the answer was already in the HTML.
OpenAPI link: Whether the page links an OpenAPI file, by an anchor or a service-desc link relation. It matters only for a site that ships an API.

Sources

Ora: AgentReady launch post (Ora's lab findings) https://ora.ai/blog/agentready-launch, read 4 November 2026
Ora check catalogue, contract 1.38.0 (132 checks, 42 in the Access layer) https://ora.ai/api/checks, read 5 November 2026
Ora home page (the fixing product is behind a waitlist) https://ora.ai/, read 5 November 2026
Ora: Introducing Deep Scan (repeat scans) https://ora.ai/blog/introducing-deep-scan, read 5 November 2026
Ora llms.txt (public URLs only) https://ora.ai/llms.txt, read 5 November 2026
Vercel: Make your site readable by AI agents https://vercel.com/kb/guide/make-your-site-readable-by-ai-agents, read 4 November 2026
llms.txt proposal (llmstxt.org) https://llmstxt.org/, read 4 November 2026

Last reviewed 5 November 2026