What a 75/100 Agent-Readiness Score Means for rajeevg.com

An agent-readiness audit moved my site from 69 to 75. The useful result is a clearer distinction between helping an agent understand a content site and building a product an agent can operate.

I ran the first Is Agentic report on rajeevg.com on 24 August 2026. It scored 69/100 across 16 eligible checks. After a round of work, the refreshed report scored 75/100 and labelled the site “Ready with a few material gaps.” That report evaluated 24 eligible checks.

The score is useful as a diagnostic. It is not a universal SEO score, and it does not promise rankings, traffic, citations, or agent recommendations.

Audit evidence

The refreshed rajeevg.com result

What I changed

The production work focused on making the site easier to read, identify, and recover from when an agent fetches it.

The site now selects Markdown responses through the HTTP Accept header. In plain English, a client can ask for a machine-friendly representation rather than receiving only the normal webpage response. I also added a real 404 status and a short Markdown recovery response, so a requesting agent gets a truthful failure and useful guidance instead of an ambiguous success page.

The homepage now includes meaningful server-rendered content and heading markup in its raw HTML. That means the important copy is present in the document returned by the server, rather than depending entirely on JavaScript running in a browser. I added Person JSON-LD, a structured data format that identifies the person represented by the site, and added or improved /llms.txt, /developers, /contact, and sitemap coverage.

I wrote tests for content negotiation, status codes, raw HTML, machine-readable files, and structured data. Tests do not make a site agent-ready on their own, but they make these promises easier to keep while the site changes.

The refreshed report no longer lists the earlier Markdown negotiation, 404, JSON-LD, contact, and agent-instruction problems. That is a concrete improvement. It is also the limit of what the audit proves.

Visibility and operability are different jobs

Visibility is the current job

For a content site, agent readiness starts with visibility. Visibility means an agent can fetch the page, extract its content, identify who published it, find related pages, recover from a missing URL, and cite a stable source.

Server-rendered copy, headings, metadata, structured identity, sitemaps, Markdown, internal links, and consistent naming all support that job. They help an agent answer basic questions: What is this page? Who wrote it? Which page should I read next? Is this URL real?

The machine-readable entry point at /llms.txt is part of that visibility layer. It gives an agent a concise route into the site's content without pretending to be a product API.

Operability is optional

Operability is a different job. It means an agent can call a product through a defined interface. OpenAPI describes an HTTP API in a machine-readable format. Structured errors explain failures. A command-line tool lets an agent run product actions. Function calling gives those actions a model-compatible contract.

What the nine remaining findings actually measure

The refreshed report still lists nine issues. I find them easier to evaluate when they are separated by the job they support.

This split is my interpretation of the audit findings, not a new score or category supplied by Is Agentic.

The visibility findings are fair prompts. The content warning is about extraction and heading structure, not proof that the live homepage is JavaScript-only. Brand search is also not fixed by code alone: indexing, consistent naming, links, and time all matter.

The operability findings are accurate too. They are mostly irrelevant to this site. rajeevg.com is a personal editorial and portfolio site. It does not offer a public site-wide API, an official command-line tool, or a function-calling product. The /developers page says so directly.

I should not manufacture those interfaces to make a score look complete.

Why 75 is enough for this site

The Is Agentic methodology gives most of its score to essential checks and the rest to recommended checks, with bonus signals and exclusions for checks judged not applicable. The important point is that different sites have different public jobs.

A software product with customers calling its API should care about schemas, predictable JSON errors, documentation, and function calling. A personal site publishing essays and project information has a different job. Its public surface is the content itself.

For my site, the sensible target is strong visibility. An agent should be able to read the writing, understand that Rajeev Gill is the person behind it, find the relevant project or contact page, and avoid mistaking a missing page for a valid one. The work above improves those paths.

The score of 75 says the site has a few material gaps in that broader audit. It does not say that I need to turn a blog into a software platform. Chasing 100 without checking applicability would reward fake or unused features. That would make the implementation less honest while leaving the reader-facing job unchanged.

A practical checklist for marketers and content teams

If you run a marketing site, portfolio, or editorial publication, I would check these items before adding an API just for an audit:

• Request the important pages as raw HTML and confirm the primary copy and heading hierarchy are present without JavaScript.
• Return real HTTP status codes, especially for missing pages, and keep the recovery response short enough for a machine to use.
• Publish stable metadata and structured identity so the site, author, organization, and content type are clear.
• Provide a sitemap, useful internal links, contact information, and a plain-language machine-readable entry point such as /llms.txt where it fits the site.
• Use one public name across page titles, author metadata, About copy, LinkedIn, GitHub, and other profiles.
• Check how the brand appears in external search results. Code changes cannot guarantee a ranking change; indexing and profile consistency take time.
• Add a visible homepage link labelled “Developer resources” if technical collaborators need it. Do not call it API documentation when no API exists.

The list is deliberately less exciting than launching a new interface. It is also more likely to help the people and systems that actually visit a content site.

What I will do next

I will keep checking the homepage's raw HTML and heading hierarchy as the content changes. A server-rendered page can drift. A new component can move meaningful copy behind a client boundary, or a heading can be chosen for visual size instead of document structure.

I may add a visible “Developer resources” link for collaborators. That is a discoverability improvement, not a promise that the site has an API. I will also keep the public name consistent and use Search Console alongside normal off-site profile work. The outcome depends on external indexing, so I will not describe it as a guaranteed ranking fix.

I will not add an OpenAPI file, command-line tool, JSON API, or function-calling layer unless the site gains a real callable product. If that happens, those interfaces will have a user and a maintenance reason. Until then, they would be props for a checklist.

For rajeevg.com, a trustworthy 75 is better than a fictional 100.