Which AI Readiness Problems Are Machine-Fixable?

Run an AI readiness audit and you get a list of problems. Read almost any tool's marketing and you'll see the word "automated" attached to fixing them. What that word actually covers varies enormously, and the gap between "automated" and "you still have to do this yourself" is exactly where a lot of frustration and a lot of wasted money happens. This is an honest breakdown of which readiness problems a machine can actually fix for you, which ones need one answer from you and then run themselves, and which ones no software, ours included, can shortcut.

This matters more once you've moved past the audit itself. A findings list is easy to produce, plenty of tools stop there. The harder, more useful question is what happens next: of everything a report just told you is wrong, how much of that workload is actually the software's to carry, and how much is still yours. Knowing the honest answer up front is what turns "audit -> fix" into a plan you can actually estimate, instead of a list that quietly assumes you'll do most of it by hand. This piece is the fix stage of that loop, the AI readiness loop covers the whole thing end to end.

Why this isn't a simple yes-or-no question

It's tempting to sort every finding into two piles: "automated" and "manual." The real picture has three, and the difference between the second and third pile is where most of the confusion lives.

Zero-decision fixes. The software has everything it needs already. There's nothing to ask you, nothing to decide, it just does the work.

One-answer fixes. The software can't invent the missing fact, but once you supply it a single time, the software applies it everywhere it's needed, instantly, without you touching each page.

No-button fixes. These get flagged and explained clearly, but nothing runs automatically, either because the problem is genuinely a content or engineering task, or because it's technically simple but too specific to your site's own setup to safely automate with one universal button.

Knowing which pile a given finding falls into tells you what to actually expect, from any tool, not just this one.

Pile one: fixes with zero decisions

These are the findings where a system can look at what's already on a page and produce a complete, correct fix without asking you anything.

Generating missing structured data. When a page has no structured data (also called schema markup) at all, the fix works out the right markup from what's already written on that page and adds it, without touching anything that's already there. Nothing to decide: the content already exists, the software is just translating it into a form machines can read directly.

There's a real limit worth naming here. A page that already carries structured data, just not data that identifies your business (a page correctly marked as an "About page" or a "Contact page," for instance) doesn't get regenerated a second time. Doing so wouldn't change anything, since the software already did its best work on that page. The real fix for those pages isn't more generation, it's the business-details fix in the next section.

Publishing an llms.txt file. This is a short, plain-text map of your site, your name, a one-line summary, and the pages worth reading, built from your business details and page list and published automatically. It's worth naming that this one doesn't move your readiness score at all. It's offered as a quick, free opportunity, not because it's scored, but because there's no reason not to have it once the pieces to build it already exist.

Turning on a canonical link. If your pages don't state which address is the "real" one (a common problem when a site is reachable both with and without www, or with and without a trailing slash), a canonical link fixes it site-wide. No code change on your end, and it keeps itself current as pages are added.

What all three of these share: the software already has, or can already see, every fact the fix needs. There's no missing information for a human to supply.

It's also worth being honest about scale here, since it's the part that actually saves time. None of this is one page at a time. A site with two thousand pages missing structured data gets all two thousand handled in the same pass a ten-page site would, because the software isn't waiting on a person to click through each one individually, it's running the same zero-decision logic at whatever volume the site actually has. That's the real distinction between pile one and everything that follows: it scales for free.

Pile two: answer once, apply everywhere

This is the pile that gets miscategorized most often, both by tools overselling it as "one-click" and by people assuming it must therefore be manual because a form is involved.

The clearest example is your core business details: your legal name, your founder, the areas you serve, the subjects you're an authority on, your contact information, your business registration facts. None of this exists anywhere for software to find and copy. It has to come from you, once. But once you've answered, the software writes it into every page that needs it, automatically, the same way a single edit to a shared template updates every page that uses it.

This single form-fill actually resolves three separate problems at once, which is easy to miss if you're only looking at the findings list as flat rows:

The missing-facts problem, directly: your site not stating your founder, service area, or registration details in a form a machine can read.

The inconsistency problem, as a side effect: if your business name, phone number, or address is stated differently on different pages, declaring the canonical version once and republishing it everywhere removes the disagreement, rather than requiring you to hunt down and edit every page individually.

The "ungrounded answer" problem, also as a side effect: when an AI assistant correctly guesses a fact about your business by inferring it from your prose, rather than reading it from a declared field, that's counted as a real weakness (a right answer today that can drift wrong tomorrow). Once the fact exists as declared data, the same correct answer becomes a stated fact instead of a lucky guess, no separate action required. The distinction between a guessed answer and a grounded one is covered in more depth in entity grounding: guessing vs. knowing.

The honest limitation here: it's genuinely not "zero-click." You have to know your own founding date, or decide which of two office addresses is the one worth declaring. But it's a world away from manual, because you answer each question exactly once, ever, not once per page. The full picture of what belongs in this step is covered in how to build your brand's entity profile.

Pile three: flagged, explained, no button

This is where "the software understood the problem" stops meaning "the software can fix the problem." There are two genuinely different reasons a finding lands here, and they call for different responses from you.

Reason one: it's simple in principle, but too specific to automate safely

A handful of findings are about the structure of your site's data graph rather than its content: a reference pointing at something that was never actually described anywhere, an entry with no permanent identifier so nothing else can reliably point back at it, the same business described two conflicting ways under one identifier, an entry that exists but that nothing else on the site ever refers to, or an entry missing information that its type would normally carry.

Worth being precise about where these actually come from: schema freshly generated by the fix in pile one is wired correctly from the start, these problems show up in structured data that already existed on the site before an audit ever ran, put there by hand, by a different plugin, or by markup nobody has touched in years. Every one of these is, in the abstract, a small fix. But "small" doesn't mean "safe to automate with one universal button," because the actual fix depends entirely on how your specific site's templates are built, which one is the correct piece of information to keep when two conflicting versions exist, or which page ought to be linking to an entry that currently sits orphaned. A tool that guessed wrong here wouldn't just fail to help, it could make the graph worse, not better. So these get named specifically and explained clearly, but the actual correction is a task for whoever manages your site's templates (which, for most of the readers of this piece, is either you, a developer, or your existing schema plugin's settings). More on how these specific graph problems show up and get diagnosed in Can AI Tell Who Runs Your Site?.

Reason two: it's a genuine content or engineering task

The rest of this pile has nothing to do with wiring and everything to do with substance that has to be created, not translated.

Your site isn't reachable or isn't listed. No sitemap, or pages that return an error or time out. A sitemap is the list of pages you hand a crawler; without one, an AI system has to guess what exists by following links. This is infrastructure work.

Your content only exists once JavaScript runs. If a page comes back nearly empty to a basic fetch and full once a real browser renders it, any crawler that doesn't execute JavaScript sees a blank page. The same applies when structured data itself is injected after the fact by a tag manager rather than served in the page itself. Both are fixed by changing how the site is built or how that markup is delivered, not by a form.

Missing image descriptions. A text-based model can only read a picture through its description. Writing accurate ones is content work, one image at a time.

Missing trust pages. No terms of service, no privacy policy, no real "about" or "contact" page. These have to actually be written and published; nothing can synthesize a trustworthy about page out of nothing.

Questions an AI genuinely can't answer, or can only guess at, about your business. This is the one worth sitting with longest, because it's the most common and the least fixable by any button. When an AI is asked a basic question about your business, what you do, who you serve, what you offer, and your own pages simply don't contain enough to answer, no amount of structured data cleanup fixes that. The content has to exist first. Filling in a business-details form supplies facts a machine can quote; it can't write the paragraph explaining your actual service in enough depth for an AI to answer a real question about it confidently. That's writing, and it's yours to do.

What this means for reading any tool's claims

Every one of these three piles is a legitimate thing for a tool to help with, the honesty problem is in how a fix gets described. A useful habit, whether you're evaluating this product or anyone else's: for any feature marketed as "automated" or "one-click," ask which pile it's actually in.

Ask what happens with zero input from you. If the answer involves you supplying even one fact the tool couldn't have found on its own, it belongs in pile two, not pile one. That's not a knock against it, pile two is genuinely valuable, but "one-click" undersells the one real click you had to make.

Ask what happens to the findings a button doesn't cover. A tool that only shows you what it can fix, and quietly drops what it can't, leaves you with a false sense of completion. A tool that shows you the full list, including the pile-three items with a plain explanation of why no button exists, is telling you the truth about where your remaining work is. This is also the deciding difference between an audit-only tool and one built around fixing, covered in more depth in the three kinds of AI readiness checker.

Ask whether "automated" is describing the fix or the detection. Plenty of tools detect a problem automatically and then hand you a to-do list; that's still valuable, but it's a different product than one that actually writes the fix for you.

Common mistakes

Assuming a fixed schema-coverage number means your identity is solved. Generating markup for pages that had none closes a real gap, but if your site still doesn't state your founder, service area, or contact details anywhere, an AI still can't answer basic questions about you. Coverage and identity are separate problems with separate fixes, and they aren't worth the same number of points either, which fixes actually move your score is worth reading before you assume the easiest fix is the most valuable one.

Filling in the business-details form once and never revisiting it. People change, addresses change, service areas expand. A one-answer fix only stays correct if the answer stays current.

Treating a pile-three "explained, not fixed" item as a false positive. It was flagged because it's real. The absence of a button reflects the limits of safe automation, not that the finding is wrong.

Expecting a competitor gap analysis or generic checker to fix anything at all. Detection and remediation are different capabilities. A tool that only measures the gap between you and a competitor gives you a to-do list, not a completed job.