What does technical AEO cover, and who needs it?
Technical AEO checks whether important pages are accessible, render usable content and communicate entities consistently. It is suited to teams with an existing site whose technical setup may obscure otherwise useful information.
| Area | What we inspect | Useful when |
|---|---|---|
| Schema graph | Types, properties, entity connections and page alignment | Markup is duplicated or difficult to maintain |
| llms.txt | File location, accuracy and selected page references | You want a concise, maintained discovery file |
| Crawler access | Public access rules and observable responses | Pages or resources may be restricted |
| Rendering | Content and markup available in the rendered page | Key details depend on client-side rendering |
We start with the URLs that matter to a buyer decision: core service or product pages, company information and supporting documentation. The review is not a replacement for content quality or broader SEO. It identifies technical blockers and inconsistencies, then gives your team a scoped route to address them. For the wider strategy, see AI search visibility or begin with a GEO audit.
How should schema.org markup work as a graph?
Schema.org markup should express page facts and relationships that are also visible to readers. We review the graph for consistency, accuracy and fit with the page rather than adding types simply to increase markup volume.
- Identify entities represented on the page, such as an organization, service or article.
- Check that properties describe information the page actually provides.
- Review how related entities connect across relevant URLs.
- Compare structured values with visible copy and page metadata.
The practical test is straightforward: can a reviewer trace each important property to a clear source on the page, and does the graph describe the same entity consistently? We note stale values, conflicting descriptions, duplicate representations and markup that does not match the visible content. Implementation can then be handled in the CMS, a template or another agreed site layer.
Schema does not replace clear page content. It gives structured expression to information your site already presents. We document which pages need shared templates and which need page-specific data, so future edits do not create a new set of disconnected snippets. For a deeper primer, see schema markup for AI search.
What belongs in an llms.txt file?
An llms.txt file is a maintained, plain-text guide to selected site resources. Its usefulness depends on whether the file is accurate, reachable and aligned with the site’s information architecture; adding one is not a substitute for accessible pages.
| Review item | Decision |
|---|---|
| File location | Confirm the agreed public path and response |
| Resource selection | Include pages that explain the project, products or services |
| Descriptions | Use concise labels that match each destination |
| Maintenance owner | Assign responsibility for updates after site changes |
We compare the proposed entries with live URLs and remove references that are outdated, vague or duplicative. A short list of authoritative pages is easier to maintain than a broad catalogue with no clear priority. The file should not promise access to material that remains restricted, nor describe content that the destination does not contain.
For llms.txt best practices, we treat the published format as a convention to review against its project documentation, not as proof that a particular assistant will read or use the file. We provide a clean draft, implementation notes and a change checklist. For a non-technical overview, use our guide to llms.txt; for platform-specific work, explore Perplexity optimization.
How do crawler access and rendering affect technical AEO?
Crawler access and rendering determine what a visitor or automated requester can retrieve from a URL. Our review checks observable configuration and page output, then flags mismatches that could make important information unavailable or incomplete.
- Check whether priority URLs respond as intended without a sign-in or unexpected restriction.
- Review relevant access directives and confirm they match the site owner’s policy.
- Inspect rendered output for key text, links and structured data.
- Compare the rendered page with the content the team expects to be public.
The review focuses on evidence available to the site owner: URL responses, rendered output, configuration and server information when provided. If a page relies on client-side rendering, we record whether its key content appears in the reviewed output and identify a practical fallback or implementation change where needed. We do not infer how an AI service internally processes a page from a successful browser check.
This separation helps prioritize fixes. A blocked URL calls for an access decision; missing rendered content calls for a rendering or template review; inconsistent markup calls for schema correction. We log each issue with its affected URL, owner and verification method. See ChatGPT visibility for work on a specific answer platform, or AI visibility monitoring for ongoing observation.
What does the implementation include, and what remains outside your control?
The project includes a review, an agreed implementation scope and evidence that the delivered changes are present on the selected URLs. Before work starts, AEOTech uses a URL-and-access kickoff checklist to confirm the site environment, decision-makers and the person who can approve production changes.
| Deliverable | What you receive |
|---|---|
| Baseline review | Findings grouped by schema, llms.txt, access and rendering |
| Change plan | Priorities, affected URLs and implementation owner |
| Implementation | Agreed edits in the available site environment |
| QA record | Checked URLs, observed output and remaining actions |
The scope is sized after we know whether the team can provide CMS or developer access and whether production changes need client approval. If we cannot edit the site directly, we supply implementation-ready instructions and verify the resulting published pages when access is available. Reporting is an issue log, not a claim about hidden platform behavior.
AI services choose whether to request, interpret or use a page, schema graph or llms.txt file, and their access and presentation can change outside your site. We can verify the agreed files and page output; we cannot promise that a platform will ingest them or cite your content.
How do we verify technical AEO changes?
We verify the work against the agreed URLs and acceptance checklist, then report what is present and what still needs attention. The check is designed to be repeatable by your site team after later releases.
| Check | Evidence recorded |
|---|---|
| Schema | Relevant markup and alignment with visible page content |
| llms.txt | Published file, live destinations and accurate descriptions |
| Access | Observed responses and reviewed access configuration |
| Rendering | Key content and markup in the checked page output |
Each finding has a status and a clear next action: fixed and checked, awaiting client change, or excluded from scope. We also note the URL and verification method so developers can reproduce the review. If a template powers several pages, the record identifies the template-level change and the sample pages checked; it does not imply that every URL was inspected.
Technical readiness is one layer of AI search visibility. Pair it with content for AI answers when pages need clearer, more direct explanations, or with entity and knowledge graph building when the underlying entity information needs work. Send us your priority URLs, CMS or developer contact, and any existing schema or llms.txt file. We will return a scoped review and proposed implementation plan.
Prices
| Service | Price | Quote |
|---|---|---|
| Technical AEO | from $760 / project |
Starting prices in USD. Custom bundles and volume discounts on request. Payment in USDT, USDC, BTC, ETH, SOL, TON or your project token.
How it works
- Share priority URLsSend the pages you want reviewed, along with any existing schema and llms.txt file. Identify the site environment and who can approve changes.
- Review access and outputWe inspect the selected pages, visible content, relevant access configuration and rendered output. Findings go into a URL-based issue log.
- Agree scope and ownersWe group fixes by priority and confirm which changes we implement and which your developer handles. The kickoff checklist records dependencies.
- Implement and checkWe make the agreed changes or provide implementation-ready instructions, then verify the published output against the acceptance checklist.
- Hand over the recordYou receive the checked URLs, issue statuses, verification notes and maintenance actions for future site updates.
Frequently asked questions
How much does technical AEO implementation cost?
Technical AEO starts from $760 / project. The final scope is set after reviewing the priority URLs, access requirements and whether implementation happens in your site environment or through developer handoff.
How long does an llms.txt and schema review take?
Timing is agreed after the URL and access review. The project moves from a defined page set to findings, approved implementation and QA; CMS access, production approval and developer availability determine the sequence.
Is llms.txt enough to make AI services use my pages?
No. We can check that the file is published, accurate and points to useful public resources, but a file alone does not establish that any AI service will request or use those pages. Treat it as one maintained technical artifact alongside accessible pages and clear content.
What is the difference between llms.txt and schema.org?
Schema.org expresses structured information about entities and pages within the site. An llms.txt file is a text guide that points to selected resources. They serve different roles, so our review checks each against its purpose rather than treating one as a replacement for the other.
Can you promise that an AI crawler will access or cite my site?
No. Access rules and rendered pages are observable and can be reviewed, but each platform controls whether it requests, processes or presents your material. We commit to the agreed implementation and report the specific files and page output verified.
What should I prepare before the technical AEO kickoff?
Prepare priority URLs, an existing llms.txt file if available, schema or template access, and a contact who can approve technical changes. If your team has crawler-access policies or rendering concerns, include the affected URLs so the review can test the right cases.
Tell us about your project
Answer four quick questions and a manager will send you a plan, timing and a price range within the hour. Everything stays confidential.
Loading the form…