Make your website readable to AI: the complete fix

Google's PageSpeed Insights now grades something new alongside performance and accessibility: whether AI agents can read your website at all. The audit has three checks. Most sites fail at least one of them.

We built a free checker at thesocialtarget.com/ai-visibility that runs this exact audit against any site in about 30 seconds, no email required. This article is the companion piece: the complete fix for all three checks, written so you can do the whole job yourself. It is not a teaser with the method held back. Every pass bar is stated exactly, every fix is here, and the order matches the report.

Fair warning on the other side of that promise: this is the technical layer, and it is deliberately technical. If you can edit your site's files or templates, everything below is doable this week. If you cannot, the last section is for you.

What "readable to AI" actually means

AI agents do not see your rendered page. They read your site through three layers Google now audits: an llms.txt file that introduces the business, the structural tree behind the page (names, labels, headings), and a layout stable enough to parse while it loads.

When ChatGPT, Claude, Perplexity, or Google’s own AI features send an agent to your site, the agent works from structure, not pixels. It looks for an introduction file at a known address. It parses your page through the same structural tree screen readers use. And it needs the page to settle, because content that jumps around mid-load confuses an agent the same way it confuses a person on a phone.

Google formalised this in PageSpeed Insights as an AI-readiness audit (the category is called agentic browsing), and it is the audit our free check runs. The strategy question, whether AI search matters for your business and where it ranks against SEO, is covered in what answer engine optimization actually is and how AI Overviews choose which brands to cite. This piece is the spanner work: the three fixes, in the order the report lists them.

Before you touch anything, make going back easy

One rule before the first fix: know how you will undo a change before you make it. If your site lives in version control, that is a commit before each fix. On WordPress, take a backup through your host or a backup plugin first, and paste any template file you are about to edit into a text file so the original survives. On a hosted builder, screenshot or note each setting before you change it. Then make one change at a time and re-check after each, so if something looks off you know exactly which edit caused it. Unglamorous, and it is the difference between a live-site job and a calm one.

Fix 1: put a real llms.txt file at your domain root

llms.txt is a plain Markdown file served at yourdomain.com/llms.txt. It tells AI systems who you are, what you do, and where your key pages live. The check passes when that URL returns actual text, and fails when nothing answers there, or when your platform quietly serves an HTML page in its place.

llms.txt is a proposed web standard from the team at Answer.AI: one Markdown file, at a fixed address, that gives language models a curated map of your site instead of forcing them to parse your homepage's navigation, cookie banner, and animation code. Think of it as a sibling to robots.txt: robots.txt tells crawlers which pages they may not visit, llms.txt tells AI systems what they should know.

The format is deliberately simple, and it is the same one we serve at thesocialtarget.com/llms.txt if you want a live example to copy the shape of:

# Your Business Name

> One sentence on what you do, who you serve, and since when.

## Who we are

Two or three short paragraphs. Founded when, based where, run by whom.
What you actually sell. The proof you would want an AI to repeat.

## Key pages

- [Services](https://yourdomain.com/services): what you offer, how it is scoped
- [Case studies](https://yourdomain.com/case-studies): published results
- [About](https://yourdomain.com/about): the founder story
- [Contact](https://yourdomain.com/contact): how to start

## What we do not do

One honest paragraph. Models repeat this too, and it keeps the wrong
enquiries out of your inbox.

Writing rules: the # heading with your name is required and comes first, the one-line summary sits in the blockquote under it, and everything after is short sections with links and one-line descriptions. Write it like a person, not a keyword list: the reader is a language model, and stuffing it with search terms reads exactly as desperate as it sounds. Keep it to one screen. Update it when your offer changes.

Where the file goes depends on your stack:

• Any site where you control the web root: upload llms.txt to the folder your homepage is served from, next to robots.txt.
• Next.js, Vite, and most modern frameworks: drop it in the public folder and redeploy.
• WordPress: upload it to the site root over SFTP or your host's file manager. Several SEO plugins now generate one; check the output rather than trusting it blindly.
• Hosted builders (Shopify, Wix, Squarespace and similar): support varies by platform and changes often. Search your platform's help centre for llms.txt; if there is genuinely no way to serve a plain text file at the root, that is worth knowing about your platform anyway.

Then verify it, because this check has a trap. Open yourdomain.com/llms.txt in a browser and view the page source. You should see your Markdown text, starting with the # heading. If you see HTML (a doctype tag, your site's shell, a styled error page), the check fails even though a page answered: single-page apps and some hosts respond to unknown paths with the app itself and a 200 status, which looks fine to a human and is not an llms.txt file. A real llms.txt returns plain text, nothing else.

Fix 2: make the page structure agent-readable

AI agents parse your page through its structural tree: the machine-readable layer of names, labels, and headings behind the layout. The audit fails on unnamed buttons, unlabelled form fields, and headings that skip levels. The fix loop is Lighthouse-guided: run it, fix every flag, re-run until clean.

Behind every page the browser builds an accessibility tree: the structured version of your content that screen readers have always used, and that AI agents now use too. If a button in that tree has no name, an agent cannot know what it does. If a form field has no label, an agent cannot fill it. If your headings jump from h1 to h4 because someone liked the font size, the agent’s map of the page is wrong before it starts reading.

This is why sites that look immaculate still fail this check. The audit is not looking at your design. It is looking at the tree.

Work through this list on your key templates (homepage first, then your main service or product page, then one article):

• Name every control. A button or link needs an accessible name. Visible text does it; icon-only controls (the hamburger menu, the search magnifier, the basket) need an aria-label, for example aria-label="Open menu". A link whose entire name is "here" or "more" tells an agent nothing about the destination; name the thing you are pointing at.
• Label every form field. Each input gets a label element tied to it with the for attribute, or a wrapping label, or an aria-label. Placeholder text does not count: it vanishes on focus and is not read as a name.
• Fix the heading order. One h1 per page: the page’s title. Sections are h2, subsections h3, no skipped levels on the way down. Pick heading tags for structure and set sizes in CSS, not the other way round.
• Give images honest alt text. Describe what the image does in the page. Decorative images get an empty alt attribute so agents skip them cleanly.
• Declare the basics. The html tag carries a lang attribute, every page has its own title tag, and the page regions sit in semantic landmarks: header, nav, main, footer.

To find every instance instead of hunting by eye: open Chrome DevTools, run a Lighthouse audit with the accessibility category ticked, and it lists each failing element with a selector pointing at the exact node. Fix, re-run, repeat until the flags are gone. Treat the bar as strict: the audit’s structural checks are pass or fail, so anything flagged is work, not advice. In practice a clean pass lands your accessibility score in the high nineties, and you will have made the site better for screen-reader users in the same afternoon, which is the rare fix that pays twice.

Fix 3: stop the layout shifting while it loads

Layout stability is measured as Cumulative Layout Shift (CLS): how much visible content moves around during load. Google's pass bar is 0.1 or less, and the audit runs on mobile and desktop, so both have to hold. The usual causes: images without dimensions, late-swapping fonts, and content injected above what is already on screen.

Cumulative Layout Shift is Google's measure of visual stability: every time something on screen moves without the user asking, the shift is scored, and the scores add up across the load. Google's own threshold is direct: 0.1 or less is good, above 0.25 is poor. The AI-readiness audit checks the same number, and it checks it on mobile and desktop separately. One device failing fails the check, and in the reports our checker runs, desktop fails more often than owners expect.

Almost every failing site is failing for one of five reasons. Work down the list in order, because the top entries are the common ones:

1. Images and video without reserved space. When the browser does not know how tall an image will be, it lays the page out without it, then shoves everything down when the file arrives. Fix: width and height attributes on every img and video element (the browser computes the slot from the ratio), or a CSS aspect-ratio rule on the container. On the sites we check, this is the most common cause and the cheapest to fix.
2. Web fonts swapping late. The page renders in a fallback font, your brand font arrives, and every paragraph reflows to the new letter widths. Fix: load fonts with font-display swap, preload the files so the swap window stays short, and give the fallback font matched metrics with size-adjust so the swap moves nothing (Google's optimisation guide walks through the font options, including when font-display optional is the safer trade). Modern frameworks automate the matching: Next.js's built-in font loading does it for you.
3. Embeds and widgets that arrive late. Maps, review carousels, booking widgets, video embeds: anything living in an iframe turns up after your page and pushes content aside. Fix: give the container a min-height matching the loaded size, so the space is spent before the widget arrives.
4. Content injected above content. Cookie notices and announcement bars that push the whole page down are the classic. Fix: overlay them (position fixed) or reserve their space in the layout from the start. The rule is absolute: after first paint, nothing gets inserted above existing content unless the user asked for it.
5. Animations that move layout. Anything animated with top, left, width, or height re-lays-out the page every frame. Fix: animate with transform instead. It moves pixels, not layout.

While you fix, measure at the source: PageSpeed Insights reports the CLS value per device, and the Performance panel in Chrome DevTools highlights each shifting element as it happens, so you can watch the load and see exactly which block jumped.

How to verify the fixes passed

Re-run the audit after each fix, on both mobile and desktop. PageSpeed Insights gives instant, uncached results; the free checker on our site re-tests a domain against a cached result for up to 24 hours. Passing means the file and structure checks come back clean and layout stability sits in Google's good band.

Two ways to re-test, with one honesty note about ours.

Our free checker is the fastest way to see the report the way a prospect sees it. But it caches a domain's result for up to 24 hours and limits repeat checks per hour, so it is the wrong tool for a fix-and-refresh loop: you would be staring at yesterday's failure while your fix sits live.

For instant feedback while you work, go to the source: PageSpeed Insights directly. Start with your homepage, because when someone checks a domain in our tool, the homepage is the page being graded; your other key templates are worth running straight afterwards. Run mobile and desktop, and read the AI-readiness section of the report alongside accessibility and CLS. The bar, stated exactly: the llms.txt and structure checks are pass or fail and need to come back clean; layout stability passes inside Google's good band, 0.1 or less. Both devices. Fix the failing one; do not average.

Because the fixes are template-level, they carry to every page built on those templates. Check your money pages individually anyway: the service page with the booking widget, or the article template with the newsletter embed, is exactly where a stray layout shift hides.

One scope note, so the win is the right size. Passing this audit makes your site readable, which is the floor, not the ceiling. Whether AI systems then cite you or recommend you is a content and reputation question (that job is answer engine optimization, a different discipline with its own playbook). Readable is necessary. It is not sufficient. Anyone selling the two as one thing is rounding up.

DIY or hire: how to decide honestly

The honest split is time, not skill. If you can edit your site's files or templates, everything in this guide is doable and you should pay nobody. Hiring makes sense when your weekend is worth more than the job, or when a hosted platform stands between you and a required fix.

The same rule we wrote in our SEO guide for small businesses applies here: the constraint that actually decides is time, not ability. None of the three fixes is beyond a careful non-developer. All three need unhurried hours with your site open, and the honest question is whether those hours exist in your week.

Do it yourself if you can edit and deploy your site's files, or your platform gives you template access and you are comfortable using it. This guide was written to be sufficient: follow it top to bottom and there is nothing left to buy.

Hand it over if you would have forwarded this article to someone anyway, because then the real comparison is our fixed price against their day rate plus your coordination time. Or if your site runs on a hosted builder (Shopify, Wix, Squarespace, GoDaddy and similar): template and root-file control varies by platform and plan, some required fixes can be genuinely blocked, and finding out which is which takes checking by hand. That check is part of what you would be paying for.

If you would rather hand it over

"The article really is the whole job. That is deliberate," Alessandro Lombardo says. "Nine years and 600+ clients in, the pattern holds: the owners who want to do this themselves only trust you once you have shown them everything, and the owners who do not want to do it just want it done properly."

So, to say it plainly: everything above is the entire fix. There is no held-back step and no premium version of this article.

If you have read this far and concluded the weekend belongs to your business rather than your aria-labels, that is what the AI Visibility Fix is: our team makes every applicable check in Google’s AI-readiness audit pass within 5 working days of admin access, or you get a full refund. £197, fixed. The work happens through your own admin panel, every change logged and reversible, and we never touch your copy or your design direction.

Either way, start in the same place: run the free check. Thirty seconds, no email, and you will know exactly which of the three fixes above is yours.