Generative Engine Optimization (GEO) has crept into conversations in every SEO team, but most projects are applying it wrong. It’s not a plugin to install or a new tag in the head. It’s a discipline that changes the rules of how authority is built and how information is structured. Here are the mistakes I see repeating over and over, along with the concrete way to fix them.
Confusing GEO with classic SEO and expecting everything to be solved with keywords
The first mistake is treating GEO as a denser layer of keywords. Generative engines don’t rank pages: they synthesize answers from fragments of multiple sources. If your content isn’t structured as self-contained response units, the model has nothing to extract from.
A recurring pattern: 3,000-word articles with the answer to the main question buried in the twelfth paragraph, after an emotional introduction. An LLM looking for information on “how long a shipment to the Canary Islands takes” isn’t going to navigate that maze; it prefers a table or a paragraph that starts directly with the figure and the context.
How to avoid it
- Place the direct answer in the first 60-80 characters of the block, not after a preamble.
- Use headings that phrase the user’s real question, not wordplay.
- Fragment the content into sections that can be cited independently.
Ignoring that the generative engine doesn’t see your JavaScript
This is the most expensive technical mistake. Many teams assume that if Google renders their SPA, AI crawlers will too. That’s not the case. Most generative engine bots (and assistants that feed answers) don’t execute JavaScript to the same depth. According to the official documentation of the main providers, crawling is done on served HTML, and when there is JS, rendering is limited or nonexistent.
I’ve seen ecommerce cases with product pages rendered on the client that disappear completely from generative answers. The content exists for the user, but not for the model. The solution isn’t to rewrite the entire frontend: it’s to ensure that critical sections (description, specifications, FAQ, contact details) are in the initial HTML or in an endpoint accessible without script execution.
How to avoid it
- Audit what the server sees with curl or with the source code view, not with the browser inspector.
- Prioritize SSR or SSG for pages with informational or transactional intent.
- If you use hydration, serve at least one static content block per section.
GEO rewards traceability. A model that has to decide between two sources that say different things about a technical topic tends to favor the one with clear authorship, an update date, and editorial context. The classic mistake: corporate blogs with articles signed by “the team” and no bio, no links to primary sources, and no visible date.
This isn’t a matter of decorative E-E-A-T. It’s that the engine needs signals to disambiguate. If your page on data protection regulations doesn’t indicate who wrote it or when it was reviewed, the model has no reason to cite you over an institutional source.
How to avoid it
- Sign content with a real name and a link to an author page with verifiable credentials.
- Include publication and last review dates visible in the HTML.
- Link to primary sources (organizations, official documentation) when you state data.
Believing that structured data is the silver bullet
Here we have to be honest: schema helps, but it doesn’t guarantee you’ll be cited. Many projects invest weeks implementing FAQPage, HowTo, and Article with every possible field, and then the content doesn’t answer anything specific. Markup describes; it doesn’t replace substance.
There’s also a nuance worth acknowledging: we don’t know with certainty what exact weight each generative engine gives to each type of schema. What we do know is that inconsistent markup (for example, an FAQPage whose answers don’t match the visible text) creates noise and can penalize trust. Transparency here is key: use schema to clarify, not to inflate.
How to avoid it
- Implement only the types that reflect real, visible content.
- Validate with the rich results testing tool and check that the text matches.
- Don’t invent FAQs that don’t appear on the page.
Neglecting entity consistency across the entire website
Generative engines build representations of entities (your brand, your products, your authors) from multiple signals. If your legal name appears in three different forms, your address changes between the contact page and the footer, and your business profile has a phone number that doesn’t match, the model has difficulty consolidating the entity.
This is especially noticeable in local or brand queries. A typical case: a company based in Madrid that lists one address on the “About us” page, another in the schema, and a third in Google Business Profile. The result is that generative answers mix data or avoid recommending the brand due to lack of coherence.
How to avoid it
- Document the canonical NAP and use it without variations on the website, in schema, and in external profiles.
- Use sameAs in the organization schema to link official profiles.
- Periodically check that external sources haven’t diverged.
Forgetting that the generative engine also reads forums and reviews
A strategy mistake: focusing only on your own domain. Generative engines feed on public conversations, reviews, and communities. If your brand doesn’t appear in those conversations, or appears badly, the model has no material to recommend you.
This isn’t about fabricating reviews (that’s fraud and it gets detected). It’s about participating in communities where your product category is discussed, answering real questions, and making it easy for satisfied customers to leave their opinion on relevant platforms. According to industry studies, a significant portion of generative answers about products includes references to third-party opinions.
How to avoid it
- Monitor brand mentions on forums and review platforms.
- Respond publicly to criticism with useful information, not with templates.
- Facilitate feedback without incentives that contaminate authenticity.
Measuring GEO with the same old metrics
This is the mistake that generates the most frustration. The team looks at Google positions, impressions, and CTR, and concludes that GEO “doesn’t work.” But generative answers don’t appear in the classic SERP ranking in the same way. You need other metrics: frequency of your domain being cited in assistant answers, brand presence in generative summaries, referral traffic from AI interfaces.
I acknowledge an important limitation: GEO measurement is poorly standardized. Commercial tools offer estimates, but there’s no equivalent to Search Console for generative engines. Anyone who promises an exact citation dashboard is oversimplifying. The honest approach is to combine manual tests with representative prompts, referral data in analytics, and mention tracking.
How to avoid it
- Define a set of test prompts and run them periodically on the main assistants.
- Segment referral traffic coming from AI domains in your analytics.
- Don’t compare GEO metrics with classic SEO metrics; they’re different dimensions.
Promising guaranteed results (and believing them)
No provider can guarantee that a generative engine will cite your brand. Models change, corpora are updated, and selection criteria aren’t public. Any proposal that assures “appearing in ChatGPT in 30 days” is selling smoke.
What you can control: the clarity of your content, technical accessibility, the consistency of your entity, and presence in sources that models consult. That improves the probability, not the certainty. And it’s worth saying so in the client proposal.
A concrete case that illustrates the problem
In a technical content project about management software, the team had published extensive guides with excellent traditional SEO. When testing prompts in assistants, the model responded with information from a competitor. The reason: our guides explained the “why” but buried the “how” in long paragraphs without structure, while the competitor had a comparison table and numbered steps in plain HTML. It wasn’t a matter of domain authority; it was a matter of extractability. We restructured the guides into direct response blocks and, without touching the linking, we started appearing in the answers. It wasn’t immediate or universal, but the change was measurable.
Quick checklist to avoid falling into the same mistakes
- Is the main answer of each page in the first visible block?
- Is critical content served without JavaScript?
- Is there real authorship with a review date?
- Does the schema match the visible text?
- Is the NAP identical on the website, in schema, and in external profiles?
- Are you measuring citations in assistants, not just positions?
- Have you avoided promising results you can’t control?
GEO isn’t magic or a passing fad: it’s the logical consequence of people searching for answers, not links. The mistakes above are fixed with editorial judgment and technical work, not with shortcuts.