GEO for TYPO3: Where Consulting and Engineering Meet

Generative Engine Optimisation, usually shortened to GEO, is often presented as a new marketing discipline. The typical recommendations focus on content: answer more questions, organise information more clearly and publish material that AI-supported search systems can understand and cite.

All of this matters, but it only covers part of the problem.

Before ChatGPT, Gemini, Google AI Mode or another system can use information from a website, it must be able to access the content, identify what the information represents and understand how companies, people, products, services and locations relate to one another.

On a complex TYPO3 website, these questions cannot be answered by content optimisation alone. They require a semantic concept that also reflects the architecture and data model of the website.

This is where consulting and engineering meet.

The consultant needs to understand what the customer’s information means. The engineer needs to understand how that information is represented, updated and delivered by TYPO3. In many cases, these are not two separate phases. The concept and implementation need to be developed hand in hand.

For agencies, this creates an opportunity to offer customers more than an SEO checklist. It also creates a need for technical partners who can participate in the analysis instead of waiting for a finished specification.

GEO does not replace technical SEO

GEO is sometimes described as a completely new discipline with its own rules. In practice, much of it builds on familiar SEO foundations.

Google states that established SEO best practices remain relevant for AI Overviews and AI Mode. A page still needs to be accessible, indexable and eligible for Google Search before it can be considered for these generative features. There is no special markup that guarantees inclusion in an AI-generated answer.^[1]

This distinction is important when discussing GEO with customers. An agency cannot responsibly promise that a particular AI system will recommend a company or cite a particular page. What we can do is improve the technical and semantic basis on which these systems interpret the website.

The work therefore still begins with familiar questions:

• Can crawlers access the relevant pages?
• Is the intended content indexable?
• Are canonical URLs and language variants configured correctly?
• Is important information available in the rendered HTML?
• Are the company, its products, services, experts and locations represented consistently?
• Can the implementation remain accurate as the content changes?

A website with unclear page structures, contradictory information or inaccessible content will not become AI-ready by adding an llms.txt file or installing another extension.

Crawler access is a business decision

Technical access is the first layer of GEO, but the decision is no longer limited to allowing or blocking Googlebot.

Different providers may use different crawlers for search, model training and user-triggered access. OpenAI, for example, distinguishes between OAI-SearchBot, which supports ChatGPT search, GPTBot, which relates to model training, and ChatGPT-User, which can access a page following a user request. These controls are independent of one another.^[2]

A general rule blocking all AI crawlers may therefore have consequences the customer did not intend. A company may want to restrict training use while remaining discoverable in AI-supported search.

This is not a decision that developers should make silently while editing robots.txt. It requires a conversation with the customer about the intended use of the content, followed by a technically correct implementation.

For a TYPO3 project, we would normally review:

• robots.txt and robots meta instructions;
• CDN and web application firewall rules;
• HTTP-level bot protection;
• canonical URLs;
• redirects and status codes;
• XML sitemaps;
• language-specific URLs and hreflang;
• content rendered through JavaScript;
• staging, archive and legacy domains;
• expired records that remain indexable.

TYPO3 already provides a good technical foundation. Its system SEO extension supports canonical URLs, robots instructions, metadata and XML sitemaps.^[3]

The engineering task is not simply to activate these functions. They need to be configured according to the project’s sites, languages, extensions and content lifecycle.

Machines need more explicit context

A human visitor can infer a great deal from navigation, design and images. A machine processing an isolated passage may not have the same context.

A page may refer to “our upgrade service,” while the surrounding website makes it obvious that the company provides TYPO3 upgrades for digital agencies. If the passage is retrieved separately, the provider, technology and intended customer may no longer be clear.

Important information should therefore remain understandable outside the complete visual context of the page:

• Which organisation provides the service?
• What technology, product or industry does it concern?
• Who is it intended for?
• Where is the service available?
• What experience supports the claim?
• Who wrote or reviewed the information?
• When was it last verified?

This does not mean repeating keywords unnaturally. It means representing relevant entities and relationships clearly enough that people and machines can interpret them.

On a TYPO3 website, these entities may already exist as domain records. In other projects, they may be embedded in generic content elements or distributed across several extensions. Before structured data can be generated reliably, we need to understand what information exists and which source should be authoritative.

That requires both consulting and technical analysis.

Structured data is not a list of tags

Structured data, typically implemented as JSON-LD with the Schema.org vocabulary, can help machines identify what a page represents. It can describe organisations, people, articles, products, offers, services, events, locations and many other entities.

The difficult part is not generating the JSON-LD syntax. The difficult part is deciding what should be represented and how the entities relate to one another.

A page can contain several valid schema types without providing a coherent description of the underlying business. Conversely, a technically correct implementation can become misleading when the structured data is no longer synchronised with the visible content.

Google requires structured data to correspond to information that visitors can see.^[4]

Schema selection therefore cannot be treated as a purely editorial decision, while implementation cannot be reduced to a development ticket. The concept needs to reflect both the semantic meaning of the information and the way the data behaves inside TYPO3.

What Yoast SEO for TYPO3 contributes

Yoast SEO for TYPO3 can be a useful part of this setup, particularly for editorial work.

It integrates content analysis into the TYPO3 backend and helps editors review page titles, descriptions, focus phrases and aspects of readability. For larger editorial teams, this can improve consistency and make incomplete optimisation work easier to identify.^[5]

Yoast also provides a basic structured-data implementation. Its standard output includes WebSite and BreadcrumbList, while its provider-based architecture can be extended through configuration.^[6]

These are useful building blocks, but they do not provide a complete GEO concept.

Yoast cannot know what a degree programme represents in the customer’s organisation, how a vehicle offer relates to a location or which TYPO3 record is the authoritative source of a service description. It cannot decide whether two visually similar pages represent the same semantic entity.

We therefore see Yoast as an editorial and technical foundation. The project-specific model still requires analysis, consulting and engineering.

Selecting structured data for a university

We worked with a partner agency to select suitable primary and supporting Schema.org types for a university website.

At first glance, the task could have been approached by assigning a schema type to each page category. In practice, the work required a more detailed understanding of the university’s information architecture.

The website contained different concepts: the institution itself, collections of degree programmes, individual programmes, advisory information, events and physical or virtual locations. Some of these pages used similar layouts, but they did not represent the same thing.

One important distinction was between a programme overview and an individual degree programme.

An overview containing several programmes can be represented as a CollectionPage with an ItemList. The detail page represents a particular programme and may instead be described as an EducationalOccupationalProgram, with relationships to the institution, a qualification, an offer or supporting documents.

The difference is semantic rather than visual. Recognising it requires consulting: someone must understand the content, the user journey and the meaning of the underlying information.

Turning that distinction into a reliable TYPO3 implementation is an engineering task. The implementation needs to identify where the programme data comes from, how the relationships are maintained and how the resulting JSON-LD is generated.

We encountered a similar distinction between physical and online university events. Both can be represented as events, but a physical open day may refer to a Place, while an online information session requires a VirtualLocation.

These examples represent only a selected part of the concept. The complete mapping included further page categories and project-specific rules delivered to the customer. The important lesson is not the final list of schema types, but the process used to select them.

We also considered the difference between the wider Schema.org vocabulary and the structured-data features currently displayed by Google. A type may express useful semantics without producing a dedicated rich result. Rich-result support was therefore relevant, but it was not the only reason to select or reject a schema type.^[7]

Schema.org types referenced:CollegeOrUniversity · CollectionPage · ItemList · EducationalOccupationalProgram · Event · Place · VirtualLocation

Modelling a vehicle sales portal

In another project, we supported a partner agency as consultants in defining the structured-data strategy for a vehicle sales portal.

Here, the information was already highly structured. Every vehicle contained many technical characteristics, but an advertisement could remain available for only a short period. The model had to describe the vehicle in detail while remaining consistent with changing prices and availability.

The selected approach combined several perspectives:

• Organization or an appropriate LocalBusiness subtype for the company and its locations;
• Vehicle for vehicle-specific properties;
• Product and Offer for the commercial offer, including price and availability;
• Service for related services offered by the company.

No single schema type described the complete situation.

Vehicle expressed what the item was. Product and Offer represented the fact that a specific vehicle was available under defined commercial conditions. The seller, its locations and related services were separate entities that needed to be connected without being incorrectly merged.

Selecting these relationships required an understanding of their semantic differences. Keeping them accurate required an understanding of the application and its data flows.

For a vehicle portal, freshness is as important as completeness. A JSON-LD block may remain syntactically valid while presenting information that is no longer true. If a vehicle has been sold, the visible advertisement, its availability, the sitemap and any cached structured data should not contradict one another.

This introduced further implementation questions:

• Which system is authoritative for availability and price?
• How quickly are changes reflected on the website?
• What happens to the URL when a vehicle is sold?
• When should it be removed from the XML sitemap?
• Can cached structured data become outdated?
• How can the output be validated after template or integration changes?

Google can use Product and Offer structured data to understand information such as price and availability. Correct markup may create eligibility for certain search appearances, but it does not guarantee that Google will display them.^[8]

Schema.org types referenced:Organization · LocalBusiness · Vehicle · Product · Offer · Service

This project demonstrated particularly clearly why GEO cannot be separated from application engineering. The structured data was not a static addition to a template. It was another representation of rapidly changing business data.

Where consulting and engineering meet

Structured-data projects are often divided into two isolated phases. A consultant produces a list of recommended schema types, and an engineer is later asked to implement them.

For straightforward websites, that may be sufficient. For complex TYPO3 projects, we do not believe it produces the best results.

Implementation decisions already begin during the conceptual work.

To select the right schemas, the team needs to understand the semantic differences between the available types. At the same time, it needs to know how the customer’s information is stored, which system owns it, how often it changes and which relationships TYPO3 can generate reliably.

A programme overview and an individual programme may look similar, but they do not mean the same thing. A vehicle is not the same entity as the commercial offer under which it is sold. An organisation is not identical to one of its locations. A physical event location is different from a virtual one.

Recognising these distinctions is part of the consulting work. Mapping them to records, integrations and frontend output is part of the engineering work. The final concept becomes reliable only when these perspectives are developed together.

For a partner agency, this does not mean giving up the customer relationship or its strategic role. We can join the analysis where specialised TYPO3 and semantic knowledge is needed, contribute to customer-facing discussions and translate the agreed concept into an implementation that fits the existing system.

The visible output may eventually be a JSON-LD block. The real value lies in the decisions and data relationships behind it.

How agencies should approach a TYPO3 GEO project

When a customer asks an agency to “add GEO” to a TYPO3 website, the first deliverable should not be a generic list of Schema.org types.

Before choosing the markup, the agency needs to understand what the customer’s information represents and how it exists within the system. For each relevant entity, the project needs to clarify:

• which TYPO3 record or external system is the authoritative source;
• whether the information is structured or embedded in editorial content;
• how the entities relate to one another across pages and extensions;
• how language and site variants affect those relationships;
• what should happen when records change, expire or disappear;
• how the generated output will be validated;
• what the customer expects GEO to achieve and which outcomes cannot be guaranteed.

These questions often reveal that the semantic concept and technical architecture cannot be designed independently.

If a service is maintained separately on several pages, there may be no reliable source for a consistent Service entity. If a location exists only as formatted text inside a content element, it cannot be connected reliably to the organisation, events and offers. If vehicle availability is imported from an external system, the structured data needs to follow the same update cycle rather than relying on a separately maintained TYPO3 field.

The solution does not necessarily require rebuilding the complete content model. In many projects, a small number of carefully selected structural changes are enough. The objective is to establish a reliable source for the important information and create only those relationships that can be kept accurate.

A schema mapping may be one output of this analysis, but it is not yet an implementation concept. The concept also needs to explain where the information comes from, how TYPO3 transforms it into visible and machine-readable output, and how both representations remain consistent when the underlying data changes.

This is why we prefer to join a GEO project during the conceptual phase. Together with the partner agency, we can understand the customer’s requirements, challenge or refine the semantic model and translate it directly into a maintainable TYPO3 implementation.

If one of your customers is asking about GEO, structured data or visibility in AI-supported search, we can join the project before the technical specification has already been fixed. The agency retains its customer relationship, while gaining a specialised partner in the area where semantic consulting and TYPO3 engineering overlap.

References

1. Google Search Central — AI features and your website. developers.google.com/search/docs/appearance/ai-features↩
2. OpenAI — Overview of OpenAI crawlers. platform.openai.com/docs/bots↩
3. TYPO3 Documentation — SEO features (EXT:seo). docs.typo3.org — cms-seo Features↩
4. Google Search Central — Structured data general guidelines. developers.google.com — sd-policies↩
5. TYPO3 Documentation — Yoast SEO for TYPO3. docs.typo3.org — yoast_seo↩
6. Yoast SEO for TYPO3 — Structured data configuration. docs.typo3.org — Yoast StructuredData↩
7. Google Search Central — Structured data markup that Google Search supports. developers.google.com — search-gallery↩
8. Google Search Central — Product (Product, Review, Offer) structured data. developers.google.com — product↩