AI WEBSITE
People are not the only ones looking at a website. Search engines index it and answer engines read it to cite it. We put all three readers' conditions into the definition of done, and split the work three ways — new build, crawler accessibility, rebuild — according to the state the site is in now.
In one paragraph
A website has three readers — people, search engines, and AI answer engines. Our web work is not about making a screen look good; it is about putting three states into the definition of done at once: readable by a person, understandable by a search engine, and cuttable for citation by an answer engine. We hold those conditions against the site as it is, decide whether to build new, open the settings, or rewrite, and proceed by that branch.
The three readers read the same document differently. A person looks at the screen, a search engine looks at the HTML and link structure, and an answer engine looks at whether it can be cut paragraph by paragraph. Build for them separately and one of them always gets pushed back, so we design them as one structure from the start.
Last verified
IN THIS AREA
Each piece of work has its own page setting out what we do and what you receive.
WHEN YOU NEED THIS
These are the situations we hear repeatedly in consultations. If any of them apply, start by measuring.
Page counts and mock-up counts are comparable, but document structure, URL policy and the machine-readable layer are not line items on a quote. When the comparison basis lives only in the visuals, the differences that surface after completion are invisible at contract time.
The three branches differ in cost and in what stands to be lost. Choosing the branch before measuring the current state means either building bigger than necessary, or changing the screen while leaving the cause in place.
In a contract where only the human reader is in the definition of done, the layers search engines and answer engines read belong to nobody. Widening the definition of done to three is the starting point of this area.
The screen sits with the agency, ads with the marketers, copy in-house — and URL policy and structured data fall between them. Because nobody owns that space, the same place breaks again at every redesign.
WHAT WE DO
Written as units of work rather than abstract proposals. The scope of an engagement is set from this list.
When done means screen sign-off alone, the other two readers are always next in line. We first write what each of them looks at and where each gets stuck, and turn that directly into the review checklist.
Whether to build new, open the settings, or rewrite usually separates on four values. Skip this order and the only basis for the decision is the impression a quote made.
When the sentence on screen and the value in structured data disagree, that itself is a signal that erodes trust. The design principle here is not writing the same value twice but having two places read one source.
Some values cannot be recovered after a site changes. Not speaking about improvement by instinct requires the before value to still exist.
URL policy and the machine-readable layer are the spaces most likely to fall between owners. Fixing ownership in writing is what stops the next redesign reverting it.
PROCESS
What you receive at each stage is stated alongside it. Durations are the working time Navirang controls; they are not a promise about when results appear.
We check body text in the scripts-disabled response, URL format, crawler policy and index status from public state alone. No materials needed from you.
Assessment checklist
Which of new build, accessibility work or rebuild fits is decided from the observations. The areas deliberately left untouched are written down too.
Branch decision · scope definition
We move into the procedure for the chosen branch. Included scope, duration and deliverables differ per branch and are set out on each page separately.
That branch's deliverables
All three criteria — people, search engines, answer engines — are judged item by item. Anything that fails gets fixed before launch.
Pre-launch checklist
We request indexing and record how answer engines treat the site that day. Every later change is judged against that value.
Index submission record · baseline observation
DELIVERABLES
We do not do work that ends in conversation. The documents below remain, and become the baseline for the next measurement.
The current state marked pass or fail against all three readers. Built from public information only, so you can receive it without submitting anything.
Which of the three branches to choose and the observations that decided it. The areas deliberately left untouched are stated too, which fixes the scope.
The same three criteria judged again immediately before launch. The client keeps it so the next redesign can be compared on the same items.
The starting point: how answer engines treat the site at launch. Whether anything improved is only judged by comparison against this record.
Reviewloger, the unified campaign search service we designed and built, renders its listings and filters as HTML from the server and consolidates 6,147 active listings (as of 2026-08-12) under one schema — and in a diagnosis on the same day it still did not make the first set of answer candidates for questions with the brand name removed. What structure is responsible for is getting to a readable state; the last step, an answer engine choosing us, is made together with mentions and trust signals from outside the site.
HOW IT CONNECTS
Our work moves as one piece. SEO builds the foundation for being found by search engines, AEO raises the odds of that information being cited in an answer, structured data helps machines understand the facts, and content supplies the evidence there is to cite.
| Area | Relationship to this work |
|---|---|
| AEO website build | For building new — included scope, technical standard, deliverables |
| AI crawler optimization | Leaving the site alone and opening crawler accessibility technically |
| Website rebuild | For rewriting an existing site — protecting existing search performance is the core |
| SEO | Getting the built site indexed and understood by search engines |
| AEO audit | The starting point that separates a structural problem from a content problem by measuring |
| Pricing | Where build scope and monthly operations cost divide |
FAQ
A The technology is the same; the definition of done differs. It is built with the same HTML, CSS and JavaScript, but rather than ending at screen sign-off, the definition of done also includes a state a search engine can index and a state an answer engine can cut and cite paragraph by paragraph. You are not buying a special product — the review checklist grows to three.
A A few observations separate them. If the scripts-disabled response has no body text and the URL scheme is inconsistent, rebuilding the structure is faster in the end. If body and URLs are sound and only one layer — robots.txt or a security setting — blocks, we leave the site alone and open access. If indexing and traffic have already accumulated, a rebuild that does not lose them comes first. That judgement is made together during the assessment.
A Getting to a readable state. Other work attaches before and after — separating what the problem currently is belongs to the audit, writing the sentences that get cited belongs to content design, and confirming a change actually happened belongs to repeated measurement of the same questions. It is also why this area does not promise a result: what an answer engine selects on is not public, and which document it chooses is decided by each engine on undisclosed criteria.
A Yes. The assessment runs from public state alone, so it proceeds regardless of who built it, and you get the result as an item-by-item checklist. For items we have no edit rights to, we write down what to change and how, and your team applies it. If what needs fixing is a few lines of configuration, saying so is the right answer.
A No. The standard is not whether scripts are used but whether body text is in the HTML source. If the body is already in the source, interaction layered on top is not a problem — we simply build so the body still shows when a script fails. Elements whose content changes, such as lists and tabs, get real path links instead of script handlers so a crawler reads each as its own page.
A It is not required. llms.txt began as a community proposal rather than an official standard, and Google states in its guidance that search ignores it. That said, one file costs almost nothing and the act of organising the facts in one place helps, so we offer it as an optional item. What genuinely has to be handled is robots.txt and the sitemap.
A No. People are one of the three readers, and a page people leave mid-read is not a good document for a search engine either. We keep the items that decide the reading experience — contrast, mobile, loading speed — in the judged set, and we do not trade screen quality against machine-readable structure.
Send us a URL and we check body text without scripts, crawler policy, structured data and index status first. Whether to build new or rewrite gets decided together from that result.
We reply within one business day.