AEO & GEO for Dealer Groups: A Practical Guide

Author: Martin Dew

Content Updated: 10 September 2026

TL;DR

This guide explains how dealer groups can make their websites clearer and easier to understand for answer engines and generative engines (used in AI search). It covers defining what each group, brand, location, department, offer and stock page is for; keeping important information up to date; linking pages together properly; and making sure customers can reach the right next step. It also gives website, marketing and operational teams a simple way to review what needs attention first.

Dealer groups don’t need additional pages for AEO or GEO. They should set up a website in which each significant page can provide a proper answer to a real customer question, obtain the data from an agreed-upon source and then direct the customer to a meaningful next step.

That is exactly what Answer Engine Optimisation (AEO) and Generative Engine Optimisation (GEO) involve. AEO enhances the clarity and retrievability of the answers on the company's own website, while GEO applies the same level of attention to search experiences that compile answers from several different sources. Both AEO and GEO place just as much trust in technical governance as they do in editorial quality.

The objective is to make it perfectly clear exactly what each page is meant for, which public facts are linked with it, and how a customer can access the next relevant page.

We have broken the process down into the key steps that follow:

Define your page structures and roles

You should prepare a list of page roles. Assign each of the important templates to one main function in order that the group site, the franchise pages and the various dealership pages do not all attempt to respond to the same query in the same way.

Page type	The question it should answer	Information it should own	Key implementation rule
Group page	Who is the group and what does it offer across its business units?	Group identity, central propositions, brands and routes to locations.	Do not repeat local opening hours or department details that belong to a dealership page.
Brand or business-unit page	Where can I explore this brand, its models or relevant services?	Brand-relevant models, offers, locations and supporting journeys.	Link to relevant locations rather than creating generic location-copy variants.
Dealership location page	Where is this dealership and how do I contact or visit it?	Address, telephone, opening hours, departments, local stock route and local services.	Give each real location one stable public URL and a distinct visible identity.
Department page	How do I contact sales, service, parts, fleet or accident repairs?	Department-specific action routes and service information.	Publish only where the department has a genuine customer journey.
Offer or campaign page	What is this offer, who is it for and how can I act on it?	Current terms, applicable locations, relevant vehicle/service and expiry handling.	Define an owner and a retirement or successor-page rule before launch.
Vehicle and stock landing pages	What is available and how can I enquire?	Current public vehicle information and relevant enquiry routes.	Make public data truthful, keep the route from discovery to enquiry clear, and manage retired URLs deliberately.

Once the map exists, assess every priority URL against three tests:

Unique purpose: Does this page answer a question that another preferred page does not?
Is it clear where the information about the vehicle, the offer, the location and the contact details come from?
Is it possible for a visitor to get to that page without having to restart their journey?

The work in this step is important because a search experience cannot make effective use of pages that are not clearly scoped, accessible, and internally connected.

Set up an entity and data model that corresponds to the real group

Website sites operated by dealer groups usually fail due to data drift rather than because of bad wording. The phone number for a location may be different in one CMS field from what it is in another. The offer might end in the feed but still be shown on the campaign page. A new department can be included on the site but missing from the location record. These are issues relating to implementation and they impact all aspects of the customer journey.

Prepare a lightweight data dictionary with publicly available facts. It does not need to provide access to internal systems; instead, it should indicate which source is the official one for the website, the data, and the marketing teams and also show who is responsible for verifying it.

Public fact	Recommended source of truth	Key fields to govern	Website use
Dealership identity	Controlled location record	Name, stable location ID, address, telephone, opening hours.	Location page, contact modules, navigation and relevant structured data.
Vehicle information	DMS or approved vehicle-data feed	Stock ID, registration/VIN controls where appropriate, status, price, specification, images, location.	Vehicle search, vehicle pages, feed distribution and enquiry routes.
Offers	Approved offer-management process	Start/end dates, eligibility, location applicability, terms and successor URL.	Offer pages, model pages, location modules and campaigns.
Department information	Central service content with local configuration	Department name, contact route, hours, booking/action URL.	Location and department pages.
Finance and buying journeys	Approved integration and content owner	Product wording, disclosure links, tool availability and hand-off route.	Relevant vehicle, offer and finance pages.

Every record needs to have a stable identifier and a last material review date. The stable identifier allows the platform to update the relevant dealership, offer, or vehicle record each time templates change. The material review date is an internal governance field and must not be confused with the public publication date of an article or page.

Make sure that the template layer is both answerable and crawlable

Strong AEO/GEO does not mean making every page a long FAQ. It means giving the visible page a stable semantic structure so that the customer and the crawler can identify its subject, key facts and action route.

For every indexable template, build and test the following baseline.

Template element	Technical requirement	Why it helps
One descriptive H1	State the page’s primary subject clearly: for example, the dealership, department, service or current campaign.	Gives the page an unambiguous main topic.
Meaningful H2s	Divide the page into real customer subjects, not decorative headings.	Makes key information easier to scan and retrieve.
Readable visible text	Keep essential information out of image-only designs, inaccessible tabs or client-side states that are not reliably rendered.	Google specifically recommends making important content available in textual form.1
Descriptive links	Link with the destination’s subject, not vague language such as “click here”.	Helps customers and search systems understand the relationship between pages.
Stable primary action	Use a clear enquiry, booking, call or location route that matches the page.	Avoids a page that explains an answer but offers no usable next step.
Accessible components	Ensure menus, tabs, accordions, filters and forms have usable keyboard and screen-reader behaviour.	Protects the customer journey as templates are reused at scale.

For components that are powered by JavaScript or are headless, you should test the public HTML obtained by a crawler. The key information on a page—for example, the title, headings, location details, vehicle or offer context, and internal links—must be reliably accessible without requiring any action by either the crawler or the customer.

Build the Markdown and llms.txt delivery layer

For dealer groups, llms.txt and Markdown page representations should be treated as fundamental implementation components, alongside HTML templates, structured data (schema.org), internal links and XML sitemaps.

The purpose is not to replace the website. The canonical HTML page remains the complete human-facing destination, with its interactive journeys, forms, images and accessible interface. The Markdown version provides a compact, text-first representation of the same approved information, while llms.txt provides a clear route map to the most important source documents across the group.

This matters at scale because a dealer group has many pages and several valid starting points. A well-maintained delivery layer makes it easier for AI systems, agents and other text-first consumers to identify the group, the relevant dealership or department, the approved source page, and the next action without having to infer that structure from a complex front end.

The three-layer model

Layer	Role	Implementation requirement
Canonical HTML page	The complete customer destination and authoritative public page.	Keep it indexable where appropriate, structured, accessible and linked from the site’s normal navigation.
Markdown page representation	A text-first, directly readable version of the approved page facts and key journeys.	Publish at a predictable stable URL, such as the canonical path plus .md, and generate it from the same approved content and data.
llms.txt	The group’s curated discovery map for high-value Markdown and canonical HTML documents.	Publish at /llms.txt, describe the group clearly and link only to maintained, authoritative source documents.

What a dealer-group Markdown page should contain

Each priority page should have a Markdown version that is concise but complete enough to preserve the page’s customer meaning. A dealership location document, for example, should identify the dealership, address, opening hours, contact routes, departments, relevant services, supported brands where applicable, and the canonical source page. A group-level document should identify the group, its locations or brands, core services and the logical routes to more specific documents.

The Markdown document should not become a second editorial workflow. Generate it from the same CMS fields and approved data records that power the visible page wherever possible. If a change is material enough to update the public location, offer or service information, it should update the Markdown version in the same release.

Markdown Example

# Example Dealer Group

> UK automotive dealer group with dealership locations, vehicle sales, aftersales services and online customer journeys.

## Core information

- [Dealer group overview](https://example-group.co.uk/dealer-groups.md ): Group structure, brands, locations and core services.

- [Find a dealership](https://example-group.co.uk/dealers.md ): Dealership locations, departments and contact routes.

- [Vehicle and buying journeys](https://example-group.co.uk/buying-a-car.md ): Vehicle enquiries, finance, part exchange and reservations.

## Locations

- [Example Town Dealership](https://example-group.co.uk/dealers/example-town.md ): Sales, service, parts, opening hours and contacts.

What belongs in llms.txt

llms.txt should be a concise index, not a second sitemap and not a dumping ground for every URL. It should explain what the group is, identify its main website and link to the Markdown documents that a text-first system is most likely to need. A group can include broad documents first, then direct routes to locations, key services, data or support documents.

Markdown Example

# Example Dealer Group

> UK automotive dealer group with dealership locations, vehicle sales, aftersales services and online customer journeys.

## Core information

- [Dealer group overview](https://example-group.co.uk/dealer-groups.md ): Group structure, brands, locations and core services.

- [Find a dealership](https://example-group.co.uk/dealers.md ): Dealership locations, departments and contact routes.

- [Vehicle and buying journeys](https://example-group.co.uk/buying-a-car.md ): Vehicle enquiries, finance, part exchange and reservations.

## Locations

- [Example Town Dealership](https://example-group.co.uk/dealers/example-town.md ): Sales, service, parts, opening hours and contacts.

The links must resolve, return the expected content and remain aligned with the canonical HTML page. Where a group publishes hundreds of locations, a location index document can be more practical than a very large root file. The key design principle is that the hierarchy remains obvious and the documents are curated rather than exhaustively generated without quality control.

Delivery-layer controls

Control	Required practice
One source of truth	Use the same approved CMS and data fields for HTML, schema, Markdown and llms.txt output.
Stable URL pattern	Choose one predictable Markdown convention, for example /dealers/example-town.md, and retain it through redesigns.
Canonical reference	Include the human-facing source URL in each Markdown document. Do not let Markdown and HTML carry conflicting descriptions, contacts, offers or dates.
Build validation	Test that llms.txt and priority .md URLs return 200, that their links resolve and that the generated document includes the required fields.
Material-change trigger	Regenerate the relevant document when location, offer, service, contact or other meaningful customer information changes.
Editorial review	Review generated text where local context, customer actions or regulated wording require a human decision.

This delivery layer is a critical AEO/GEO foundation because it turns a complex multi-location website into an explicit, maintained set of source documents. It should be included in the group’s platform specification from the start, not added as a hand-maintained afterthought.

Control duplicate and near-duplicate URLs with a canonical policy

Dealers usually have several methods of offering content which is essentially the same, for example different campaign versions, various location routes, parameterised stock URLs, similar brand pages and outdated site addresses. The solution is not to use noindex in all cases; rather, a written canonical policy should be included in the templates and publishing workflows.

Google considers redirects and the use of rel="canonical" to be strong canonical signals, while including a page in the sitemap acts as a weaker supportive signal. It recommends the use of self-referencing canonical tags, the keeping of consistent internal links to the preferred URL, and advises against using noindex as a way of establishing canonicality. You can find further information on Google’s guidance here.

Situation	Implementation action
A distinct physical dealership with its own address and customer route	Publish a standalone location page with its own self-referencing canonical and visible local data.
Two URLs that present the same campaign or offer	Select the enduring customer-facing URL; redirect or use a canonical relationship where the alternate page must remain accessible.
Expired campaign with a clear replacement	Use a permanent server-side redirect to the nearest relevant successor, rather than leaving a generic or misleading page live.
Filtered or parameterised inventory states	Define which landing pages are intended for search and ensure templates do not generate uncontrolled indexable permutations.
Legacy URLs following a platform migration	Preserve an agreed redirect map, then monitor crawl errors and destination relevance after launch.

Use full absolute URLs in the canonical tags, include them in the HTML <head> section, and ensure that client-side JavaScript does not replace them with different URLs after the page has loaded. The canonical URL should also be the one used in internal links, structured data, and the XML sitemap.

Make sure your internal links are designed to create a decision pathway from the group level to the local level.

Internal linking is the method by which the group's content and data model are linked together. Google has included internal linking among the established SEO practices that are still relevant to its AI features.

The usual journey within a group site is generally hierarchical but not rigid; a customer might start at the group proposition, then go on to the brand, then to an individual model, then to a town, a service need, or the current offer. The website should provide clear pathways linking these different starting points.

Group site

├── Brand / business-unit pages

│ ├── Model, offer and service pages

│ └── Relevant dealership locations

├── Dealership location pages

│ ├── Sales, service, parts and accident repair routes

│ ├── Local stock/offer routes

│ └── Contact, directions and booking actions

└── Group-level support pages

├── Central contact and governance

└── Careers, news and customer information

Use reusable navigation and breadcrumbs so users can see them, and provide contextual links to the page, as well as options to select your location or brand. Instead of inserting hundreds of exact-match anchor links in the footers, make sure that the links appear sensible to a person who has reached a particular page and must make the next decision.

Use structured data to connect real things with visible ones

You should use structured data (schema.org) to clarify the group's real web entities rather than setting up a separate "AI schema" layer. Although no special markup is required for Google's AI features, Structured data/schema still has a role when it mirrors the visible content.

Start with a consistent graph model. First check the output of the current template, then extend the graph rather than producing competing objects from various modules.

Organization (group)

└── WebSite (group website)

└── WebPage (specific group / brand / location / service page)

└── mainEntity (only where the page genuinely describes one entity)

└── AutoDealer or relevant Service / Department entity

The simplified location-page pattern illustrates this relationship as follows: you must use a more specific type only when it accurately represents the visible entity, and you should enter only those properties that are shown on the page.

{

"@context": "https://schema.org",

"@graph": [

{

"@type": "Organization",

"@id": "https://example-group.co.uk/#organization",

"name": "Example Dealer Group",

"url": "https://example-group.co.uk/"

},

{

"@type": "WebPage",

"@id": "https://example-group.co.uk/dealers/example-town/#webpage",

"url": "https://example-group.co.uk/dealers/example-town/",

"name": "Example Town Dealership",

"mainEntity": {

"@id": "https://example-group.co.uk/dealers/example-town/#dealer"

}

},

{

"@type": "AutoDealer",

"@id": "https://example-group.co.uk/dealers/example-town/#dealer",

"name": "Example Town Dealership",

"url": "https://example-group.co.uk/dealers/example-town/",

"parentOrganization": {

"@id": "https://example-group.co.uk/#organization"

},

"telephone": "VISIBLE-TELEPHONE-ONLY",

"address": {

"@type": "PostalAddress",

"streetAddress": "VISIBLE-ADDRESS-ONLY",

"addressLocality": "VISIBLE-TOWN-ONLY",

"postalCode": "VISIBLE-POSTCODE-ONLY",

"addressCountry": "GB"

}

}

]

}

Treat it as a model, not simply as something to copy and paste. Each URL, organisation name, address and phone number must be taken directly from the page itself. Ensure that the same @id values are used so that a location, service or group entity is not recreated inconsistently in different templates. Do not include any ratings, reviews, availability, prices or opening hours unless they are both visible on the page and supported.

Create content which addresses the questions people have when they are about to make a decision.

AEO/GEO content works best when it helps a person to make their next decision rather than when it forces each keyword to be used as a question heading; in the case of a dealer group such questions generally concern a specific model, local service, offer conditions, department routes, or online buying or booking.

Use a repeatable publishing brief for priority pages:

Brief element	Question for the page owner
Customer intent	What does a customer need to know or do after searching for this subject?
Primary entity	Is the page principally about the group, a brand, a location, a department, an offer or a service?
Evidence	Which approved data, terms, source pages or real process supports the answer?
Required facts	Which address, model, offer, eligibility, contact or action information must be present as visible text?
Connected pages	Which group, brand, location, department or service pages should a customer be able to reach next?
Review owner	Which team is responsible for detecting material changes and updating the page?

It is advisable to use an FAQ component rather than producing a large number of general frequently asked questions. You ought to employ such a component whenever customers actually pose questions, when the questions are clearly answered on the page, and when the particular format is required as part of the customer journey; in all other cases, short explanatory sections together with clearly labelled links will be more effective.

Evaluate the quality of the implementation at the group, franchise, dealership, and page levels

The measurement model ought to distinguish between technical availability and commercial outcomes. Google includes traffic from its AI features within the standard Web search category in Search Console, so you should consider this traffic alongside the broader search and analytics data rather than treating it as a separate set of metrics.

Citation and grounding query data for supported AI experiences are now available in the AI Performance preview in Bing Webmaster Tools. Microsoft has made it clear that citations do not indicate ranking, placement, authority, or a page's importance, but you can use them to verify that the content is clear and complete. Further information on AI performance in Bing Webmaster Tools can be found here.

Measure	Group-level use	Location or page-level use
Index coverage and crawl diagnostics	Detect template-wide indexing or access problems.	Investigate why a priority page is excluded, redirected or canonicalised elsewhere.
Canonical consistency	Check that platform templates agree on preferred URL rules.	Confirm the page’s canonical, sitemap entry, internal links and schema URL are aligned.
Landing pages and search queries	Identify which content areas support group objectives.	Test whether each page attracts searches that match its stated customer purpose.
Engagement and conversion paths	Compare useful journeys across group sites and channels.	Check whether the relevant enquiry, booking, call or location action is clear.
Citation activity, where available	Identify subjects or page types for review.	Use as a prompt to improve clarity or completeness, not as a rank position.

Have a realistic action plan for implementation

To implement an AEO and GEO strategy on your dealer website, it’s best to avoid trying to resolve every technical issue across the group within a single project. Start with priority customer journeys and turn the method into a reusable operating standard. The outcome should be an easier-to-govern website that answers questions more clearly.

When you can trace a public fact to its source, explain the role of each URL, connect customers to the right next action and detect when content has drifted, your group website becomes more useful in search, more dependable for customers and easier to improve over time.

Extend your AEO & GEO Team with Autoweb Design

If you are looking to develop an AEO/GEO strategy for your dealership or automotive group, we would love to talk to you. Our digital marketing team have specialised skills and experience that can complement your in-house marketing team to make sure that your plans are delivered quickly and produce the results you are looking for – more enquiries starting with AI search or Agents like ChatGPT, Anthropic Claude, Google Gemini and more. Contact our team for an informal chat today.