If you want to test an AI-powered website , you need a reproducible process rather than a single score: First, check accessibility and loading time, then source code and structured data, followed by discovery files like llms.txt and a possible Markdown version. Finally, compare a specific AI response with published primary sources. Crucially, this requires documented test conditions, multiple measurements, and a verifiable fact-check.
I've been working with websites for small and medium-sized businesses for over 20 years. In that time, I've learned that a technically present signal is not yet conclusive proof. Only when technology, visible content, and well-maintained company data are aligned can people, search engines, and AI systems reliably categorize a business.
Testing an AI-enabled website means comparing verifiable facts across all relevant issues.
Testing an AI-enabled website: the process in seven steps
The following website AI test combines technical testing with content-based evidence. The practical example used is btlabs.dev , which runs on btlabs Core. The website is therefore a test object, but not yet proof of individual product claims.
- Accessibility and speed: Measure status code, redirects, server response time and loading time.
- Source code: Control page titles, canonical URLs, language signals, and visible company information.
- Structured data: Check the Schema.org markup technically and editorially.
- Discovery files: Directly access llms.txt and other publicly named files.
- Markdown version: Evaluate accessibility, readability, and compliance with the HTML page.
- AI query: Ask a fixed question with a documented model and web access enabled or disabled.
- Comparison of facts: Check and classify each relevant statement made by the AI against a primary source.
The measurement protocol precedes the test.
Before you can test an AI-powered website and compare results, you need to define the test conditions. A metric without context is not reliably repeatable. This is especially true if a provider advertises a specific loading time or a high Lighthouse score.
First, document the framework conditions:
- Verified URL: including language and full path.
- Time: Date, time and time zone.
- Location: actual test location or one selected in the tool.
- Test profile: Device, browser, screen size, and simulated CPU and network conditions.
- Tool and version: for example Lighthouse, PageSpeed Insights or WebPageTest.
Then record the measurement series:
- Number of runs: Ideally, five consecutive measurements.
- Evaluation: Median as well as lowest and highest measured value.
- Disruptive factors: Cache state, extensions, server load, external services, and parallel processes.
Lighthouse results can fluctuate even without changes to the source code. The Lighthouse project cites network, server, hardware, and browser as possible causes and recommends multiple runs under consistent conditions. According to the documentation, the median of five runs is about twice as stable as a single run.
Separate server response time, load time, and Core Web Vitals
A statement like "under 200 milliseconds" is incomplete without specifying the metric. It could refer to the server response time, the retrieval of the HTML document, or another measurement point. The complete page load time, in turn, refers to a different process.
Core Web Vitals should not be equated with a general speed rating. Google currently uses three key field metrics:
- Largest Contentful Paint, LCP for short: good at a maximum of 2,5 seconds.
- Interaction to Next Paint, INP for short: Good at a maximum of 200 milliseconds.
- Cumulative Layout Shift, CLS for short: good at a maximum of 0,1.
The assessment is performed at the 75th percentile, separately for mobile and desktop devices. A page passes the Core Web Vitals assessment only if all three metrics meet the recommended thresholds. Server response time, often referred to as Time to First Byte, aids in diagnosis but is not a Core Web Vital. Lab data also does not replace field data from real page views. Lighthouse cannot directly measure INP without actual user interaction and uses Total Blocking Time as a supplementary diagnostic metric in the lab.
For btlabs.dev, this means: The statement "speed under 200 ms" may only be described as a measurement result if the metric, tool, URL, test profile, and measurement series are documented. A product description alone does not confirm the value.
Check the source code for unambiguous company facts.
Anyone wanting to test an AI-enabled website should check the delivered source code and the rendered DOM after assessing performance. A machine-readable website isn't just about valid HTML. Search engines and AI systems need to be able to identify who is behind the site, what services are offered, and for which location the information applies.
Check at least:
- a clear page title and a suitable meta description,
- a canonical URL without conflicting language or domain variants,
- correct language settings and hreflang references,
- a comprehensible heading structure,
- Visible information about name, offer, location and contact details,
- Internal links to services, contact information and legally relevant pages,
- Key facts that are accessible even without user action.
Next, compare the output: Does the source code contain the same company name as the contact page? Are the phone number, email address, scope of services, and location identical? Even small discrepancies weaken data consistency.
Validate structured data technically and in terms of content
Structured data identifies content with standardized properties and relationships. For company websites, depending on the page content, Schema.org types such as Organization, LocalBusiness, Person, Service, WebSite, or BreadcrumbList are suitable.
The examination has two levels:
- Technical validity: Is JSON-LD syntactically correct and do it have the required properties?
- Factual accuracy: Does the excellent information match the visible content and the binding company data?
Google recommends using the Rich Results Test and the URL Inspection Tool for technical verification. However, valid markup does not guarantee a Rich Result, nor its inclusion by Google or an AI system. Google explicitly points out that correctly marked-up data is not automatically displayed in search results.
Therefore, when checking btlabs.dev, don't just look for the presence of Schema.org code. Compare the organization, product name, vendor, contact information, languages, and URLs with the visible pages. Our article on schema validation with JSON-LD describes the technical verification process in more detail.
Correctly classifying llms.txt and Markdown
To test an AI-enabled website, you can directly access an existing llms.txt file in the root directory. This file can provide automated readers with important content in a compact format. The format was published as a voluntary proposal in 2024. llms.txt is not a ratified W3C or IETF web standard and does not guarantee support from any specific system or improved visibility.
Check the following points in an llms.txt file:
- Does the URL respond with a successful status code?
- Is the content readable without registration and JavaScript?
- Does the file reference accessible, canonical pages?
- Are the name, offer, location and contact details clearly described?
- Is an update date or a traceable version identifiable?
- Does the information match the website and structured data?
- Does the file contain verifiable facts instead of unsubstantiated product claims?
Our article on llms.txt for SMEs, its limitations and its practical benefits provides a more in-depth analysis.
Check the Markdown version separately
A Markdown version can provide content without navigation, layout code, or other visual elements. The mere existence of the output is not what matters. A usable Markdown version must be complete, up-to-date, logically structured, and consistent with the visible website.
Compare paragraph by paragraph:
- Are there any essential services missing or limitations?
- Are the headings and lists logically structured?
- Will links and sources be preserved?
- Are contact details displayed correctly?
- Do the German, Italian, and English versions agree factually?
- Does the Markdown version contain information that has already been changed on the website?
A compact machine output containing incorrect facts is less useful than a more comprehensive HTML page with correctly maintained information.
A concrete AI response, documented testing
Testing an AI-powered website also means controlling the actual output of an AI system. To do this, formulate a well-defined question that requires several verifiable facts. For btlabs.dev, the wording could be:
"What is btlabs Core, who offers the system, for which companies is it intended, what current functions are offered, and which contact and location details are verified by primary sources? Name the sources used and separate verified facts from conclusions."
Document the following regarding the question:
- the exact wording without subsequent correction,
- the model used and the visible model version,
- Date, time and language,
- whether web access was enabled,
- whether the system has named sources,
- the complete AI response in its original wording.
Then check the answer sentence by sentence. The most authoritative primary source available is always the official one: the official website, contact page, legal notice, published product documentation, or information directly provided by the company. A summary from another source is not considered an equivalent primary source.
Four status indicators for fact-checking
- Confirmed: The statement is in complete agreement with a recent primary source.
- In contrast: The AI gives a different name, location, contact method, or scope of services.
- Not assigned: No reliable published source can be found to support this statement. This is not automatically an error, but the statement cannot be considered a proven fact.
- Outdated: The statement was correct previously, but contradicts the currently published information.
Missing information is not automatically incorrect. If an AI doesn't provide a phone number even though one is published, the answer is incomplete. However, if the AI provides an incorrect phone number, there is a discrepancy.
btlabs.dev as a verifiable test object
When testing btlabs.dev, measured results, technically existing files, editorial assessments, and observed AI outputs must be documented separately. A reference to a function does not replace a direct retrieval, and an internal product statement does not replace a measurement.
Use the same four status values for the evaluation:
- Confirmed: A current primary source or reproducible measurement supports the statement.
- In contrast: The target value, visible content, and actual output do not match.
- Not assigned: A claim like "under 200 ms" does not contain a named metric or verifiable measurement series.
- Outdated: An older file or AI response contradicts the currently published state of affairs.
Future features such as AI booking agents, shop and inventory modules, protected areas, live price calculators, or additional apps are prepared development stages. They should not be considered currently available standard features.
Checklist for South Tyrolean SMEs
If you want to test an AI-enabled website for a South Tyrolean business, multilingualism must be included in the test protocol. German, Italian, and any other language versions must contain the same verifiable core messages. Different translations must not lead to differing services, opening hours, or contact methods.
- Company Management: Confirms name, legal form, locations, services, contact person and binding contact details.
- Editors: maintains visible content and ensures factually accurate translations.
- Technique: It controls source code, canonical URLs, hreflang, Schema.org, llms.txt and Markdown output.
- Person responsible for testing: It maintains the measurement log and documents deviations in AI responses.
- Testing frequency: A full test is required at least quarterly and after changes to services, location, team, or contact.
In my work with owner-managed businesses, I often see that technology and content are maintained separately. This is precisely where inconsistencies arise. Our approach to repeatable LLM monitoring therefore combines standardized test questions, reference data, and clearly defined responsibilities. AI serves as a tool for monitoring in this process.
Technical signals are only as reliable as the facts they refer to.
Questions and answers about the website AI test
What makes a website AI-ready?
An AI-enabled website provides clear, accessible, and consistent information in visible content, source code, and machine-readable formats. Crucially, this requires verifiable sources, technical accessibility, and ongoing data maintenance.
Is an llms.txt file sufficient for AI visibility?
No. llms.txt is a voluntary suggestion and not a guaranteed visibility lever. The file can provide guidance, but it does not replace good content, structured data, crawlability, external trust signals, or consistent company facts.
How do I test structured data?
First, test JSON-LD using the Rich Results Test, and for indexed pages, additionally with the URL Inspection Tool in Google Search Console. Then, compare each property with the visible content, as technical validity does not necessarily confirm factual accuracy.
What facts should I compare in an AI response?
Compare at least the company name, provider, location, contact information, target audience, current services, and clearly identified development stages. Use a current primary source for each fact check and indicate any missing evidence separately.
How often should I repeat the website AI test?
For most SMEs, a quarterly test is advisable. Repeat the test additionally after relaunches and after changes to services, locations, opening hours, contact persons, or technical specifications.
Can a technically sound website guarantee a correct AI response?
No. AI systems use different data sources, models, and retrieval methods. A technically and editorially sound website improves the starting point, but every single AI response remains a snapshot in time.
Conclusion: Test an AI-enabled website and substantiate the facts.
If you want to test a machine-readable website, you shouldn't stop at an llms.txt file, a Lighthouse score, or a successful AI response. A robust test combines metrics, source code, structured data, discovery files, Markdown output, and a documented factual comparison.
For small businesses, the most important outcome isn't another technical score, but clarity: Which facts are confirmed, where are there inconsistencies, what is unsubstantiated, and who is responsible for making corrections? Testing an AI-enabled website therefore also means clearly assigning responsibility for data consistency.
