Find a product term and see what it means for your website. Examples below explain the interface; they are not readings of your business.
An audit of your public pages: content, metadata, structured data and the evidence behind each finding.
Why it matters · Find gaps before deciding what to change. A website audit does not reproduce a search engine or AI assistant’s answer.
Where you’ll see it · The read and your website report.
Your business facts and the answers you confirm in Legible. The product also shows what it found in your published markup.
Why it matters · Keep your intended business description distinct from what is currently on your website. Saving a record does not verify it live.
Where you’ll see it · The read, Your record and Publish.
A history of recorded AI answers: whether your business was named, which sources were cited, and which competitors appeared.
Why it matters · Compare repeated readings when enough samples are available. Results apply to the recorded questions and providers, not every AI service.
Where you’ll see it · Roll Call in your site workspace. Requires visibility readings; a website access check alone does not produce these results.
Monitoring that compares a new website audit with the previous reading and identifies changes.
Why it matters · Spot regressions after website edits. Scheduled readings depend on monitoring availability and your plan; this is not continuous monitoring.
Where you’ll see it · Website monitoring and drift notifications, when enabled.
A problem big enough that search engines or AI assistants are getting your website meaningfully wrong — like your company having no machine-readable identity at all.
Why it matters · Fix these first. Each one you clear usually moves your scores the most.
Where you’ll see it · Red badges on recommendation cards, and the red count card at the top of your site page.
Not an emergency, but a real gap — something machines would understand better if you fixed it, like a page title that's too long or a missing description.
Why it matters · These are the steady wins. Clearing warnings is how a good site becomes a great one.
Where you’ll see it · Amber badges on recommendation cards.
A polish opportunity. Your site works fine without it, but doing it makes everything a little sharper.
Why it matters · Do these when the criticals and warnings are done — they're the finishing touches.
Where you’ll see it · Blue badges on recommendation cards (internally called "info").
The only 'done' we accept. The change went live on your site, and we then re-visited the public page — like a visitor would — and saw it there.
Why it matters · Lots of tools say 'done' when a button was clicked. We only say it when the public internet proves it.
Where you’ll see it · The badge on completed cards, and step 6 (Validate) of every fix.
A read-only identity check: we confirm the account we're connected to really is the one that publishes your website — so a fix can never land on the wrong site.
Why it matters · It's the seatbelt. Nothing can be written anywhere until identity is proven.
Where you’ll see it · Step 1 on every fix screen.
You look at the exact before-and-after of every change and untick anything you don't want. What you approve gets frozen under a plan fingerprint.
Why it matters · You're the editor-in-chief. Nothing you didn't see and approve can ever run.
Where you’ll see it · Step 2 on every fix screen.
A full rehearsal of the fix with zero writes — we simulate every change and check the results for mistakes (placeholder text, wrong lengths, wrong branding).
Why it matters · If the rehearsal fails, nothing has happened and nothing needs undoing. That's the point.
Where you’ll see it · Step 3 on every fix screen.
The approved changes are written into your site platform's staged draft — the backstage copy only editors see. Your visitors still see the old site.
Why it matters · It gets everything ready to go live without anything actually going live.
Where you’ll see it · Step 4 on every fix screen.
The working copy of your website inside your site builder (like Framer). Think of it as backstage: you can rearrange everything and the audience sees nothing until the curtain lifts.
Why it matters · It's why Apply is safe — changes wait backstage until you decide to publish.
Where you’ll see it · The middle zone of the 'where is my change right now' strip on fix screens.
The curtain lift: your staged draft becomes the live website everyone sees. It's the only step in the whole product that changes your public site, and it asks you to type a confirmation.
Why it matters · Because it can't be un-clicked, it gets its own approval — separate from everything else.
Where you’ll see it · Step 5 on every fix screen, with the red LIVE badge.
After publishing, we fetch your live pages again — exactly like a visitor or Google would — and compare what came back against the plan, character by character.
Why it matters · An API saying 'success' proves nothing. Only the live internet showing the change does.
Where you’ll see it · Step 6, the final gate. Passing it is what turns a card green.
A short code (like 9da845eb…) computed from the exact content of your approved changes. Change even one letter of the plan and the fingerprint changes completely.
Why it matters · It makes approval tamper-proof: the system will only ever execute the exact plan whose fingerprint you approved.
Where you’ll see it · On the change-plan card and at the top of every fix screen.
An extra lock held by Sensate (the humans running this service). Even after you click Apply or Publish, nothing runs until Sensate has also given its go-ahead for that engagement.
Why it matters · Two keys are safer than one — especially for the button that changes a live website.
Where you’ll see it · The amber 'Safely held — nothing happened' notice, if you click before a gate is open.
The undo plan. Before anything is applied, we record what every value used to be, so each change can be reversed.
Why it matters · Confidence to act comes from knowing the way back.
Where you’ll see it · Mentioned in dry-run results ('rollback: recorded per-op') and stored in every run's manifest.
Legible can make this change entirely through your platform's API. You approve it; the engine does it.
Why it matters · Zero effort for you — just review and approve.
Where you’ll see it · Badge on recommendation cards and the change-plan summary.
The engine can write it automatically, but the content deserves your eyes first — like new page titles that should sound like you.
Why it matters · Machines are fast; you know your brand. This class combines both.
Where you’ll see it · Badge on recommendation cards and the change-plan summary.
Your platform has no API for this change, so you make it yourself — but we hand you everything: numbered steps, a picture of the exact dialog with the right values, and the exact content with a Copy button.
Why it matters · 'Manual' shouldn't mean 'figure it out'. It means five careful minutes with perfect instructions.
Where you’ll see it · Step 4 of a fix, when it says 'your action needed'.
The change can't be done inside your site platform at all — it needs something at a different layer, like a rule on your domain (e.g. serving llms.txt via Cloudflare).
Why it matters · Knowing a fix belongs to a different toolbox saves you from hunting for a button that doesn't exist.
Where you’ll see it · Badge on cards like 'No llms.txt', with the exact path forward spelled out after Apply.
Legible's connection to your website platform — the piece that lets approved fixes be written into your site (as a draft first, never straight to live). Framer has one today; other platforms get exact copy-paste instructions instead.
Why it matters · 'Adapter available' on your site means many fixes can be applied for you, with your review at every gate, instead of by hand.
Where you’ll see it · The badge next to your platform name at the top of your site page.
How sure the crawler is about what your site is built on, from the evidence it found — 'framer · 100%' means every signal agreed; a lower number means the evidence was thinner.
Why it matters · The platform decides which fixes can be applied for you and which come as instructions, so it's worth knowing how firmly we identified it.
Where you’ll see it · The chip beside your site's name, with the detected signals listed next to it.
Visiting your website's pages one by one and reading the code behind them — the way Google, Bing and AI assistants do it. That's how every audit here starts.
Why it matters · We judge your site by what crawlers actually receive, not by what your editor shows you.
Where you’ll see it · '57 pages analysed' on your site page; every audit and validation.
Short descriptions of a page that visitors don't see on the page itself — mainly the page title and meta description. They're what search engines show in results.
Why it matters · It's your shop window in Google. 'My Framer Site' in a title is like a shop sign saying 'SHOP'.
Where you’ll see it · The Search listings score; many recommendation cards.
The name of a page in the browser tab and — more importantly — the blue headline in search results. Best kept between 15 and 65 characters.
Why it matters · It's often the first thing a human reads about you on the internet. Make it yours.
Where you’ll see it · Title-fix recommendations; the case-study titles fix was the first one this product ever completed.
The one-or-two sentences under the blue headline in search results, set invisibly on each page.
Why it matters · It's your chance to say, in your words, why someone should click.
Where you’ll see it · Metadata recommendations and page-level fixes.
Facts about your pages written in a format machines can read with certainty — instead of guessing from your paragraphs. Usually written as JSON-LD.
Why it matters · It's the difference between a machine guessing who you are and knowing who you are.
Where you’ll see it · The Structured data score; the '✗ structured data' surface chip until it's fixed.
The exact file format structured data is written in — a block of organised text that sits invisibly in your page's code. (The name means 'JSON for Linking Data'.)
Why it matters · It's the block you paste in the 'End of <head>' custom-code fix. It never runs and never slows your site — it's information, not a program.
Where you’ll see it · The Organization entity markup fix; the code block with the Copy button.
The shared dictionary that Google, Microsoft and others agreed on for structured data — it defines words like Organization, Place, FAQPage and what they mean.
Why it matters · Using the shared dictionary is why every machine can read your facts the same way.
Where you’ll see it · Inside every JSON-LD block ('@context': 'https://schema.org').
A small text file at yoursite.com/llms.txt: a short, honest summary of what your site is and which pages matter, written for anything reading the site rather than browsing it.
Why it matters · It is your own account of the site, in one place you control. ChatGPT, Claude and Perplexity may read it and none of them says otherwise; Google Search does not use it, and none of them asks for it often. Cheap to publish and easy to remove — worth having, not worth waiting on.
Where you’ll see it · The 'No llms.txt' card; the '✗ llms.txt' surface chip until it exists.
Three lines your robots.txt may or may not contain, naming OAI-SearchBot (ChatGPT), PerplexityBot and Claude-SearchBot. Each one is allowed to read your pages unless you have told it not to.
Why it matters · OpenAI documents that a site which disallows OAI-SearchBot is not shown in ChatGPT search results. It is the only setting on this list where a vendor states the consequence out loud — and it is one line to change.
Where you’ll see it · The 'robots.txt blocks …' card, when one of the three is shut out.
A file at yoursite.com/robots.txt that tells crawlers which parts of your site they may visit. Almost every site has one.
Why it matters · Get it wrong and you can accidentally hide your whole site from Google.
Where you’ll see it · The surfaces checklist on your site page ('robots.txt ✓').
A machine-readable list of every page on your site (sitemap.xml). Crawlers use it as their map so they don't miss pages.
Why it matters · A page missing from the sitemap can be invisible to search — sometimes on purpose, sometimes by accident. (We flag it either way.)
Where you’ll see it · The surfaces checklist; findings like 'contact page missing from sitemap'.
How much of your business is published in a form a machine can quote directly, rather than infer. Assistants can read your pages either way — this is the part they can attribute to you, by name, with confidence.
Why it matters · An assistant can only work from what it can read. Whether it may read you at all is decided by three lines of robots.txt; what it finds once it does is decided by how much of the business your pages actually state.
Where you’ll see it · The AI readiness score card.
The connected map of facts about your business: your organisation, places, services, people — and how they relate ('REDSxP operates the Bangalore Experience Lab'). It's the source everything else is generated from.
Why it matters · One well-kept map, many outputs: your JSON-LD, your llms.txt and your page facts all come from it, so they never disagree.
Where you’ll see it · The knowledge-graph engine badge on cards; the Company identity score.
One 'thing' in your knowledge graph — a company, a place, a service, a person. Each entity gets a stable address (like yoursite.com/#organization) that machines can point at.
Why it matters · Naming your things precisely is how machines stop confusing you with someone else.
Where you’ll see it · The entity engine badge; entries inside your JSON-LD block.
Links from your entity to your official profiles elsewhere — LinkedIn, Instagram, Wikipedia — telling machines 'these are all the same us'.
Why it matters · It's identity verification for the open web: the more authoritative places agree you're you, the more machines trust it.
Where you’ll see it · The 'Organization has no sameAs links' recommendation (waiting on your list of official profiles).
A fact your website says outright — like the address printed on your contact page. The strongest kind of evidence.
Why it matters · Stated facts go straight into your structured data without needing anyone's confirmation.
Where you’ll see it · Green badges in the Business intelligence section; the green slice of the evidence donut.
A fact we worked out from strong clues — like judging business maturity from multiple delivered projects and a named team — without your site saying it word-for-word.
Why it matters · Useful, but held more loosely than stated facts. We show you these so you can correct us.
Where you’ll see it · Blue badges in the Business intelligence section; the purple slice of the donut.
Something we refuse to guess. 'Not recognised automatically — review required' means exactly that: a human should tell us.
Why it matters · A product that guesses your business model wrong is worse than one that asks. We ask.
Where you’ll see it · Amber badges in the Business intelligence section; the empty part of the donut.
A 0–100 rating of how well machines understand a part of your site today — 100 means fully machine-readable. Computed fresh from every crawl.
Why it matters · It turns 'how are we doing?' into a number you can watch improve as fixes land.
Where you’ll see it · The score cards on your site page, with the projection chart showing where approved fixes take you.
A 1-to-3 level describing how established your business looks from the outside (3 = fully established). It's an observation about you, not a problem with your site.
Why it matters · A full bar is a strength to be proud of — context for reading everything else.
Where you’ll see it · The three meters in the Business intelligence section, labelled 'Level n of 3'.