How to audit what your website tells visitors

Most websites say slightly different things on different pages. The pricing page was updated last spring, the FAQ two years ago, and a help article still describes the old trial. Nobody notices, because nobody reads the whole site in one sitting. Customers do notice, one page at a time, and so does every AI tool that answers questions from your pages. This guide shows how to audit what your site actually tells visitors, using short summaries to read many pages quickly.

Why summaries help an audit

Reading twenty pages in full takes an afternoon and you stop paying attention by page eight. A summary of each page takes a minute to read, and it shows you what a quick reader takes away, which is what most visitors are. The website summarizer reads the main text of a page and writes a one-sentence summary and bullet points. It is told to use only the page text and to add nothing, so the summary is a test of the page itself: if a fact is not in the summary, ask whether it is clear on the page.

A summary is not proof. The model can misread a table or skip a condition, so treat every summary as a pointer and check the page before you change anything.

Step 1: list the pages customers rely on

Start with the pages that answer questions people ask before and after they buy:

• Pricing and plans.
• Shipping, delivery or onboarding.
• Returns, refunds and cancellation.
• Contact and support hours.
• The FAQ page.
• The five help articles your team links to most often.

Add any page that repeats one of these facts, such as a landing page that mentions the trial, or a blog post that quotes a price. Repeats are where conflicts hide.

Step 2: summarize each page

Run each page through the summarizer with the Detailed length, which follows the page section by section. Paste each summary into a document under the page address. The free tool has a daily limit, so spread a large audit over a few days, or start with the pages that drive the most support questions.

Watch for two warning results. If the tool cannot read a page, the text may be built with JavaScript or blocked by robots.txt, and some AI tools cannot read it either. If the summary says the page is mostly navigation, the page gives readers very little to work with.

Step 3: build a fact table

Now pull out the facts. Make one row for each fact a customer acts on, and one column for each page. Fill in what each summary says, then check the cells against the pages. Here is an example for an invented online store:

Step 4: read the table for three problems

Conflicts

A row with two different values is a conflict. In the example, the return window is 30 days on two pages and 14 days in the FAQ, and the shipping page promises free returns while the returns page says the customer pays. Customers quote the page that suits them, and your team has to decide which one to honor. An AI tool that reads both pages may give either answer.

Gaps

A row with no value is a gap. Nobody in the example says anything about international orders. If customers ask about it, your support team answers the same question by email again and again. Gaps also show up in the support inbox: compare the questions you get most with the rows in the table.

Buried facts

Some cells say "Not stated" in the summary, but the fact is on the page, deep in a paragraph or in a side box. That is a buried fact. A quick reader misses it in the same way the summary did. Move it up, under a heading that names it.

Some facts are missing for a technical reason: the text is in a side box, a footer or an image that tools leave out. The website text extractor shows you the exact text that the summarizer worked from, so you can see whether the fact is there at all.

Step 5: give each fact one home

The lasting fix for conflicts is to give each fact one owner page. The returns page owns the return window. The FAQ answers the question in a sentence and links to the returns page for the details, instead of repeating every condition. When the window changes, you change one page, and the rest stay true.

• Fix the conflicts first, because they cause wrong promises.
• Then fill the gaps that match your most common support questions.
• Then move buried facts into the first lines of their section.
• Write down which page owns each fact, so the next person who edits the site knows where to change it.

Step 6: repeat when something changes

A full audit once or twice a year is enough for most sites. A small one is worth doing every time a price, a plan or a policy changes: summarize every page that mentions the old value, and check the fact table row for it. A search of your own site for the old number finds most of those pages.

What the summaries will not catch

• The end of a very long page. The summarizer reads up to 16,000 characters, so check the last sections of long policies by hand.
• Pages behind a login. Your account area and in-app help can disagree with the public site too. Add them to the table by hand.
• Tone and wording. A summary shows what a page says, not how it sounds.

Why this matters for a support chatbot

A support chatbot that answers from your website inherits every conflict and gap in it. Paperlink AI is a customer support chatbot that answers only from the documents you upload and the website pages you import. When two pages disagree, the bot has two answers in its sources. Your team can see the source behind every answer in the dashboard, so a wrong answer leads you straight to the page that needs the fix. When your content does not answer a question, the bot says so and shows your support contact, and the question appears in the Unanswered report. That report is a gap list you did not have to build by hand.

If an old page cannot be changed quickly, you can upload a corrected document and mark it as the one that replaces the page. The versions guide explains how. Fixing the page is still the better fix, because your visitors read it too.