GEO implementation means the vendor works in your repository or CMS and ships the schema, llms.txt and page structure to the live site. An audit describes what is wrong; implementation changes it. The test is who pushed the change to production.
There are two businesses hiding under the same words. One sells you a picture of the problem. The other changes it. They quote similarly, they use the same vocabulary, and the difference does not surface until the month you expected something to have shipped.
The tell is simple and you can apply it in one question: after this engagement, who pushed the change to production? If the answer is your developer, working from a document the vendor sent, you bought an audit. An audit is a useful document; implementation is the change itself, and the statement of work should say which one you are paying for.
What does GEO implementation include?
Four things have to reach your live site before an answer engine can read them differently. Not a slide describing them. The site.
- Crawl access. The robots.txt, CDN rules and bot-management settings that decide whether the crawlers behind the major assistants can fetch your pages at all. A blocked crawler removes you from the answers regardless of what else is fixed. Suede measured this across the thousand most-visited domains: of the 597 serving a robots.txt, 26.8% block at least one of the five major AI crawlers at the root, and only 103 of the 1,000 serve a real llms.txt, per the AI Crawler Access Index, with the per-domain data and the script published alongside it.
- Structured data. Schema that matches what the page actually says, validated, in production, not a JSON blob in a shared drive.
- An llms.txt that is maintained. Generated once and forgotten is worse than absent, because it goes stale against the site it describes.
- Page structure the engine can lift. Claims stated with a number, a mechanism or a named source attached, in blocks a synthesis engine can quote without flattening.
The order matters more than the list. Programs fail by starting at step four: rewriting copy on a site the crawlers cannot reach. The full working method, with the measurement design stated so it can be run independently, is published at Generative Engine Optimization (GEO): A Practical Guide. The buyer-question side of that method is on the answer engine optimization agency page.
How do you tell GEO implementation from a GEO audit?
Put these in the statement of work before you sign. A vendor who implements will answer all six in a sentence each. A vendor who audits will answer the first and go vague on the rest.
- Which exact schema types? Named up front, not "structured data as appropriate."
- Repo or CMS access: who has it? If the vendor never touches your stack, the vendor is not deploying.
- What is the production URL of the llms.txt? A real path on your domain, live at the end of the engagement.
- Which validation checks run, and against what? Validation on a local file proves nothing about your site.
- Will you show a before-and-after source diff? The actual changed markup, not a screenshot of a score.
- Is there a post-deploy HTTP readback? Someone fetching the live URL afterwards and confirming what a crawler now sees.
Those six are not our invention. They are what a buyer is told to require when they ask an AI assistant how to choose a vendor in this category, and they are a fair test of anyone, including us.
How Suede answers them
Named schema types agreed before work starts. We work in the repository or the CMS, with access you grant and can revoke. The llms.txt ships to a production URL on your domain and is maintained against the site as it changes, not generated once. Every change is validated against the live page rather than a local copy, delivered as a pull request or a CMS edit with the source diff attached, and read back over HTTP after deploy so the record is what a crawler actually sees.
The measurement runs on the same footing: real buyer prompts, repeated across engines, dated, so a change means something rather than being a single reading on a good day. The free AI citation check takes one such reading across four buyer questions, and it is the first thing we measure for every client. Sprint and retainer pricing is quoted case by case because scope depends on the site. The comparison page explains the work.
We run this on our own estate first, and the method is published free in full: The Screenshot, eleven chapters, and the audit checklist. If you would rather run the diagnosis yourself, everything you need to do that is on this site and costs nothing.
What to have ready before implementation starts
- The site you will keep. Implementation pays off on the site you will keep: if a rebuild is coming, the fixes go into the rebuild so they land once.
- Repo or CMS access. Access lets the work ship directly; until access is granted, the teardown and fix list give your team the exact order of work.
- The dated baseline. The measurement sets the priority list before any retainer starts, with the dated captures behind every item, so each fix is tied to an answer you can check.
Shipping into someone else’s stack is the same skill whether the target is a schema block or a queue of unreviewed sales calls. Suede AI also builds and runs managed agents for that second kind of work; see AI operations, and the forward deployed engineer offer for a business that needs triage first.