AEO WEBSITE
Structure gets settled before design. We fix the information architecture and content specification in writing, build so that body text lands in the HTML source, and hand over with structured data and index submission already done.
In one paragraph
An AEO website build settles the information architecture and content specification in writing before any screen is drawn, and builds the site on top of that specification. It is built so body text lands in the HTML source, handed over with structured data and index submission complete, and the deliverables include a URL rules document, a structure specification, an operations guide and a launch baseline alongside the screens. Reaching the same state after completion means reworking the information architecture and URL scheme, so this standard goes into the engagement scope at the start.
What we fix is the structure, not the product. One condition is held constant — body text has to be present in the HTML as received, read without executing scripts — and the stack is chosen from the options that satisfy it, to suit the client's operational team and existing assets. We do not work in the order of choosing a product first and fitting the requirements to it.
Last verified
WHEN YOU NEED THIS
These are the situations we hear repeatedly in consultations. If any of them apply, start by measuring.
In a contract where completion is judged by the screen alone, nobody owns what search engines and answer engines will read. If a document-structure standard was not a line item, that site was not an oversight — it was completed to contract with people as the only reader.
Reverse that order and the rendering method can only be chosen from the options that can implement an already-drawn screen. The end of that road is a structure where body text appears only after scripts run — and then writing more copy does not increase the sentences a crawler can take.
If pages are not divided by question, the information architecture has to be rebuilt, and when URLs change the accumulated indexing and links shake with them. Changing structure costs far more than changing content.
When entity information — business name, representative, address, contacts, founding — exists only as an image or a footer line, an answer engine has no basis for confirming us as one organisation. Deciding where that information lives is one line of specification during a build and a site-wide edit after completion.
WHAT WE DO
Written as units of work rather than abstract proposals. The scope of an engagement is set from this list.
Pages get divided by question rather than by menu. We set the boundary so one page answers one question through to the end, and fix that boundary as a URL rule so it does not drift later.
The skeleton of a document gets pinned down as a specification per page type. The purpose is that the same structure comes out whoever writes the copy, and this specification becomes the rule for adding content later.
Design goes on top of semantic markup. Heading levels have to match the document's logic for a machine to judge which section a paragraph belongs to — and that is what allows it to be lifted paragraph by paragraph.
Static output or server rendering, the condition is one: the HTML received without executing scripts must already contain the body, the lists and the tables. The stack is chosen from the options that satisfy that.
The facts visible on screen and the values a machine reads get aligned. Inserting only the schema that matches the page, accurately, matters more than increasing the number of types.
Ownership verification and sitemap submission are completed at launch. And so operations can be handed over, the management procedure, the content-addition rules and the measurement baseline come as documents.
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 confirm the business and the questions it should be the answer to, and settle the page list and URL rules. Decisions here govern every later cost, so they are signed off in writing before moving on.
Information architecture · URL rules
Per page type we fix where the heading, direct answer, evidence, FAQ and update date sit, and settle where company entity information appears. Copywriting proceeds from this specification.
Structure specification per page type
Mock-ups get built on top of semantic markup. The duration varies with page count and how ready the copy is, and whether body text lands in the HTML source is checked on every page.
A working site (for private review)
JSON-LD, the sitemap and robots.txt are applied and reviewed for anywhere the on-screen wording and the values disagree. Index requests go in at launch so verification starts the same day.
Schema review · index submission record
The management procedure and content-addition rules are handed over as documents, and the state immediately after launch is recorded once as the answer engine baseline. Every later change is compared against it.
Operations guide · launch baseline
DELIVERABLES
We do not do work that ends in conversation. The documents below remain, and become the baseline for the next measurement.
The page list, the hierarchy and the URL format rules. The client keeps it so pages added later attach under the same rules.
Where the heading, direct-answer paragraph, evidence notation, FAQ and update date sit, per type. Its purpose is that page shape does not drift when the writer changes, so it gets opened first every time a new page is made.
The working site and the complete source. We do not lock it into a form only one agency can edit.
The procedure for adding, editing and deploying content, the edit boundaries that do not break the schema, and the rules for images and alt text. Written so an internal owner can follow it directly.
One measurement of how answer engines treat the brand immediately after launch. Every later change is compared against this value.
The scope is fixed this way while the stack is not — this site satisfies the same condition through static output, and Reviewloger, which we designed and built, satisfies it through server rendering. Separate items can run alongside, quoted and delivered separately.
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 |
|---|---|
| Citable content design | Rewriting the copy that fills the specification into sentences that get cited |
| Structured data | The area for extending beyond base schema to entity connections |
| AI crawler optimization | The area when allow-and-block policy per crawler needs designing separately |
| Website rebuild | The route taken when fixing an existing site rather than building new |
| Indexing | Continuing to check and manage index status after launch |
| Pricing | The build is one-off; operations afterwards are monthly |
FAQ
A Look at whether a document-structure standard is in the scope. There are three things to check: whether the information architecture and URL rules are settled in writing before construction, whether a content structure specification per page type is in the deliverables list, and whether structured data and index submission are in scope. A quote listing only page counts, mock-up counts and a maintenance period means completion will be judged by the screen alone. We write those three as separate lines at quoting stage.
A Chosen to suit the client's situation. The one condition we hold constant is that body text must already be in the HTML a crawler receives without running scripts. Both static output and server rendering satisfy it. Whether the operational team needs to publish articles directly, and whether the data changes frequently, change the answer, so it is decided together during requirements.
A You can if it satisfies the conditions. Three things to check: does body text land in the HTML source, can title, description and canonical be set per page, and can JSON-LD be inserted into a page. If one of the three is blocked we look for a way around it first, and only propose migrating when there is none.
A It varies with page count and how much copy is ready. The base skeleton is one to two weeks for requirements and architecture, one to two weeks for the content structure specification, three to six weeks for design and build, and a few days each for structured data, index submission and handover. We confirm the current state with the free audit, then set the scope and quote.
A We fix the structure as a specification and the client supplies the factual information. The specification carries the method for making a heading a question, the placement that finishes the answer in the first paragraph, and where evidence and update dates go — a form an owner can fill in. Fully rewriting existing copy into sentences that get cited is handled separately in citable content design.
A We cannot promise a date. When a search engine collects and indexes a new address is decided by the search engine, and what an answer engine selects on is not public — neither is a value we control. What we do is complete ownership verification and sitemap submission at launch so verification can begin, and record that day's state as the launch baseline so later change is compared under the same conditions.
A Yes. The complete source, the admin accounts and the deploy paths are handed over. The operations guide marks both the procedure for adding articles and the points where an edit breaks the schema, so the structure survives a change of owner. Whether to do the measurement and improvement together afterwards is decided separately at that time.
Tell us the purpose and the rough page count and we will draft the information architecture and the included scope. If a site exists already, the free audit records its current state first.
We reply within one business day.