Seven things your website needs for on-site AI search to work

When someone asks your site's search a question, whether they get a good answer depends less on the AI tool than on the state of your content.

There's a version of AI search readiness that has become familiar over the past year or so: structured metadata, robots.txt permissions, content written to be citable by external tools. That advice is good, and it matters for visibility in ChatGPT, Google's AI Overviews, and similar platforms. But it doesn't cover what you need when the AI search is running on your own website.

On-site AI search, the kind that lets a visitor ask a question and get an answer drawn from your published content, has its own set of requirements. Most of them aren't about the AI. They're about whether your website is in a state where any AI, however well-designed, could reasonably find the right content, understand it, and give a useful answer.

These are the seven things that matter to prepare your website for AI search.

Insytful AI Search crawls your website starting from the homepage and works outward by following links. If a page isn't linked from anywhere else on the site, the crawler won't find it, and it won't be indexed. A councillor profile that only appears on page two of a paginated listing, reached by clicking a "next" button rather than a real link, is effectively invisible. The same applies to any page that can only be reached by a JavaScript-driven interaction: many crawlers can't trigger those actions, so the content behind them is never discovered.

A sitemap is a useful safety net for pages that are hard to reach through links alone, but it only works if it stays current. If new pages are being added regularly — staff profiles, service listings, events — a sitemap that isn't updated alongside them provides no benefit. The better long-term fix is making sure every important page has at least one real, crawlable link pointing to it from somewhere else on the site.

Some pages look complete in a browser but contain very little usable text once the underlying content is extracted. A landing page that consists mainly of navigation links to other sections, or a service page where most of the detail is hidden behind an expandable accordion, can end up with almost nothing for the AI to work with. The same is true of pages built primarily around images, video, or downloadable documents, where the body copy is thin or absent.

A useful test is to read the page without the layout, navigation, or styling: just the text, in the order it appears. If the result barely makes sense, the AI is working with the same thing. The fix is usually about how the page is structured and written, not about the AI.

An AI search needs to understand not just what a page says, but what it means. A phone number on its own isn't very useful. A heading that says "Contact us" followed by a number, with nothing to indicate what the number is for, isn't much better. If the same page is the only place a resident can find the direct line for planning enquiries, that context needs to be on the page explicitly, not assumed from the surrounding navigation.

Page titles, headings, and opening sentences do a lot of work in telling the AI what a piece of content is actually about. Pages that assume the visitor has arrived from somewhere else and already knows the context can produce confusing or incomplete answers. Every page should make sense on its own.

JSON-LD and schema.org markup give AI tools a reliable, machine-readable summary of what a page contains: who a contact is, what an event covers, what a service provides. A lot of sites either don't output structured data at all, or only do so inconsistently — a content type that was set up carefully three years ago, and another that was never configured. That's worth auditing before anything else.

Once structured data is in place, it needs the same maintenance attention as the content it describes. An opening hours field showing last year's hours, or a service address that was never updated after a team relocated, can actively mislead an AI that trusts structured data. Schema that contradicts the body copy of the same page creates exactly the kind of inconsistency that produces unreliable answers.

PDFs and Word documents are much harder for AI search to work with than ordinary web pages. Many organisations publish key information — service guides, eligibility criteria, fee schedules, contact details — as downloadable documents rather than as web content, often because that's how the content was originally created. That information frequently ends up invisible to AI search as a result.

A reasonable test: if a resident or student would need to open a document to answer a common question, the AI probably can't answer it either. A council's housing application guide published as a 40-page PDF, a university's tuition fee schedule as a downloadable spreadsheet — both contain content users regularly need, and neither is easily surfaced by AI search. Where the content is important enough to publish, it's usually important enough to be a web page.

AI search can only surface what has been published. If there's no page covering a topic users regularly ask about, no amount of tuning the search engine will fix that. This is more common than it sounds: a university with no web page explaining what happens to a student's funding if they interrupt their studies, or a council with nothing published about how to appeal a planning decision.

Query data from the search itself is one of the clearest signals for finding these gaps. It shows what people are looking for and not finding, which is a content brief rather than a technical problem. The most useful thing many organisations can do after launching AI search is spend a few hours reviewing the questions it couldn't answer, and treat that as a starting point for the content roadmap.

News articles and policy pages that were accurate when published can become a problem once the facts change. An AI search has no reliable way to know that an article from two years ago is out of date unless something flags it. It may surface that article confidently alongside current content, because it looks relevant to the question. A piece announcing a service consultation that has since concluded, or a news story about a senior officer who has since left, are both examples of content that can produce answers that are technically sourced but no longer accurate.

Deciding how news is indexed — whether older articles are included, excluded after a certain date, or tagged to prevent them being surfaced — is a publishing decision worth making deliberately rather than leaving as a default. The same thinking applies to any content where the facts move: elected member profiles, service charges, opening hours, statutory guidance. Reviewing what's being indexed is part of running AI search well, not a one-time launch task.

Most of the problems that surface once AI search goes live are content and website problems, not AI problems. The engine can only work with what it finds, so the state of the website matters more than most teams expect when they first start the project.

If you're preparing to launch AI search or reviewing results that aren't as good as you'd hoped, these seven areas are the right place to start. See Insytful AI Search in action to talk through what's involved for your site.