Do You Need an AI Readiness Tool? | AI Schema Gen

Every AI readiness tool, ours included, is selling you a shortcut. That's a fair question to ask about: a shortcut to what, exactly, and is the thing it's shortcutting actually hard enough to need one? None of the four things an AI readiness score measures, whether crawlers can reach your site, whether they can read it, whether they can tell who runs it, and whether they can answer real questions about it, requires special software to exist. A sitemap is a text file. A JSON-LD block is a chunk of plain text you could type into Notepad. Every validator that checks your work is free. So before comparing which tool to buy, it's worth answering a more basic question honestly: do you need one at all?

The honest answer is that it depends on your site, not on how good any tool is. This piece walks through what doing this entirely by hand actually involves, pillar by pillar, where that holds up fine, and where it quietly stops working, so you can tell which side of that line your own site sits on.

What "doing it yourself" actually means

DIY here doesn't mean "read a blog post and understand the concepts." It means executing the fix yourself, by hand, with no software built for the job standing between you and the result. For AI readiness, broken down by the same four pillars any audit checks:

Discover: can a crawler reach your site. A sitemap is an XML file listing your pages; you can write one by hand or export it from your CMS, then reference it in robots.txt, a plain text file at your site's root that tells crawlers what they're allowed to fetch. Checking whether your content depends on JavaScript to appear (a real problem, since some AI crawlers don't run JavaScript) means opening your browser's developer tools, disabling JavaScript, and reloading the page to see what's actually left.

Read: can a crawler parse the page once it arrives. This is view-source work: checking that you have one clear heading, that your headings nest in order, that your canonical tag (the line that states which URL is the "real" version, when a page is reachable more than one way) points at the right address, and that no stray noindex tag or header is hiding the page from being read at all.

Understand: can a machine tell who runs the business and how the pieces connect. This is where DIY gets genuinely harder. You're hand-writing JSON-LD, a specific block of code in a format called JSON-LD that states facts like your business name, address, and founder in a form a machine can read directly, using schema.org's own vocabulary of over 800 types and thousands of properties. Google's own guidance is direct about which format to reach for: "we recommend using a format that's easiest for you to implement and maintain (in most cases, that's JSON-LD)." The same page is equally direct about who this is realistic for: if you use a CMS like WordPress, Wix, or Shopify, you likely can't edit the underlying HTML directly, and are pointed toward "CMS-specific options like plugins" instead of hand-editing.

Answer: can an AI accurately answer real questions about your business from what you've declared. The only genuinely manual way to check this is to ask. Open ChatGPT, Perplexity, or Gemini, and ask it what your company does, where it's based, and who runs it. Compare the answer against the truth.

The DIY toolkit that actually exists

None of this requires paid software. Here's the real, free toolkit, and what it does and doesn't cover.

That's a genuinely complete, genuinely free kit. Nothing in it is locked behind a paywall, and none of it requires you to trust a vendor's black box. It's also, on its own, only built for one page at a time.

Where DIY holds up fine

A small, mostly static site. If you're running a handful of pages, a portfolio, a single-location business, a personal site, the entire manual process above is a reasonable afternoon, not a project. There's no meaningful gap between what a tool would produce and what you'd write yourself, because there's nothing to keep synchronized across pages.

A one-time cleanup with no ongoing publishing. If your site doesn't change often, once your JSON-LD is correct and validated, it stays correct until something else on the site changes. The maintenance burden that makes DIY hard elsewhere doesn't apply if there's nothing regularly being added.

Learning what good markup actually looks like. Even if you end up using a tool for the ongoing work, hand-writing JSON-LD for one real page, then running it through the Schema Markup Validator and the Rich Results Test, is worth doing once. It's the fastest way to understand what your business's entity graph, the set of facts about your organization and how they connect, is actually made of, rather than treating it as something a tool does to you.

Where DIY breaks down

Page count. The work per page doesn't get smaller because you have more pages. Writing correct JSON-LD for a hundred product pages by hand is the same task a hundred times, not a harder task once. This is the exact math worth understanding before committing to doing all of it yourself: some fixes are genuinely automatable because they only need doing once and apply everywhere from a single answer, which is a very different time cost than fixes that repeat per page.

Consistency across pages. This is the failure mode that actually costs readiness points, not just time. If your business name, phone number, or address is hand-typed into JSON-LD on twenty different pages, the odds that all twenty stay identical over a year approach zero. Someone updates the address on the contact page and not the footer. A new page gets created by copying an old one and nobody notices the copied entity ID still points at the wrong page. None of this looks like a mistake in the moment; it looks like normal website maintenance, and it's exactly how sites end up with a business described three different ways in three different places.

Publishing cadence. A site with one person publishing occasionally can remember to add markup to a new page. A site with several people publishing regularly, especially non-technical people, will not. The realistic outcome isn't "everyone forgets," it's that markup coverage becomes a matter of who happened to know the process, which quietly decays as staff turns over.

Surviving a redesign or a platform change. Hand-written JSON-LD usually lives in a template file or is pasted into a page's HTML directly. A redesign that rebuilds templates, or a CMS migration that moves content into a new structure, has no reason to know that markup needs to come along for the ride. It's one of the more common ways schema quietly disappears after a deploy, and a manual process has no mechanism at all for catching it beyond someone remembering to re-check.

Regression detection. A validator tells you whether your markup is correct right now, at the moment you run it. It has no memory. If a plugin update, a theme change, or a template edit removes your markup next month, nothing manual notices until you go looking, and most people only go looking after something else prompts them to.

The actual trade-off, stated plainly

The comparison isn't "hard versus easy." Writing one page of correct JSON-LD by hand isn't hard if you're willing to read schema.org's own documentation for the type you need. The comparison is between two different kinds of cost:

DIY cost: your own time, spent once per page and then again every time something changes, plus the risk that consistency quietly drifts because nothing is checking it for you.

Tool cost: whatever the software costs, in exchange for the same work applied at whatever scale your site actually has, plus something checking your existing pages on a schedule so a regression doesn't sit unnoticed for months.

Neither of those is free. DIY's cost is real, it's just paid in your own hours instead of a subscription, and that's a legitimate choice if your hours are cheap relative to the work and your site is small enough that the hours stay small. A five-page brochure site run by one person who's willing to learn schema.org's vocabulary genuinely doesn't need a tool. What changes the answer isn't ambition, it's scale, publishing cadence, and how many hands touch the site.

A short checklist for deciding

Answer these honestly about your own site:

• How many pages need markup, and is that number likely to grow? Under twenty and static: DIY is fine. Growing past that, or already past a hundred: the per-page cost stops being small.
• Does more than one person publish content? One person can maintain a manual convention. Several people, especially with turnover, usually can't.
• How often does your business information itself change? A service area that expands, a new location, a founder change. Every one of those means re-editing every page that mentioned the old fact, by hand, if nothing is centralizing it.
• Have you already been burned by markup silently disappearing? If a redesign or plugin update has already quietly wiped your schema once, that's a strong signal the manual process has no safety net, not that it was a one-off accident.
• Is your genuine gap crawlability and page structure, or entity consistency? Discover and Read fixes are close to one-time config changes even by hand. Understand-pillar work, the entity graph, is where hand-maintenance compounds, because it's the pillar weighted heaviest in the score for a reason: it rewards connected, consistent data and punishes exactly the kind of quiet drift manual upkeep invites.

If most of your answers point toward small, static, and single-owner, the free toolkit above is a genuinely complete answer, and paying for a tool would be buying convenience you don't need yet. If your answers point the other way, the honest case for a tool isn't that the work is impossible by hand, it's that the same work repeated across pages and repeated over time is exactly the kind of task software is supposed to remove from a person's plate. That said, a tool doesn't mean you stop thinking about any of this; some of the work, the facts themselves, stay yours regardless of what you buy.

If you're on WordPress and leaning DIY

WordPress specifically makes hand-writing this more approachable than a fully custom site, because the data you need (your site name, your permalinks, your publish and modified dates) is already available through WordPress's own functions rather than something you'd have to track separately. A full field-by-field walkthrough, including the WordPress-specific traps that catch people doing this by hand (a disabled author archive leaving a reference dangling, a page cache serving a stale modified date), is covered in our JSON-LD checklist for WordPress developers. If you're going to DIY on WordPress, that's the more complete version of this section.

Common mistakes

Copying JSON-LD from a random example without adapting every field. A sameAs array, @id, or url copied from a tutorial and left half-changed produces markup that validates as syntactically correct while pointing at the wrong entity entirely. The Schema Markup Validator checks syntax, not whether the facts are actually yours.

Validating once at launch and never again. A validator tells you the truth about your markup at the exact moment you ran it. It says nothing about whether a plugin update three months later quietly broke it.

Treating the Structured Data Markup Helper as if it covers everything. It's built for a short list of common page types. The moment your need is an Organization with a connected graph of related entities rather than a single Article or Event, you're past what a point-and-click helper does and into hand-written JSON-LD.

Underestimating the consistency problem because it's invisible in a code editor. Looking at one page's markup, it looks fine. The problem only shows up when you compare it against the other nineteen pages that also mention your address, and almost nobody does that comparison by hand until something else forces the question.

Assuming DIY is an all-or-nothing choice. Plenty of sites reasonably hand-write their Discover and Read fixes, which are close to one-time, and reach for a tool only for the Understand-pillar work that actually compounds. The decision doesn't have to be the same answer for every pillar.

Curious which side of this your own site falls on? Run a free AI readiness check and see exactly what's already fine, what's genuinely worth fixing, and how much of it is realistic to do by hand.