Mitos GEO para agencias WordPress: qué funciona y qué no

#¿Qué es la GEO para una agencia WordPress?

La GEO en la práctica es citabilidad más retrieval, no un nuevo pack de plugins. Un modelo o buscador generativo debe: (1) saber que existís como entidad, (2) tener una URL con frases que pueda citar, (3) tratar esa URL como creíble frente a la competencia. Un post de LinkedIn que dice «optimizamos para IA» sin cambiar landings, sin lastVerified, sin un texto coherente en llms.txt y sin tablas que un extractor pueda levantar no cumple ninguna de esas condiciones.

Para una agencia WordPress el problema se duplica. El cliente tiene cientos de URL (portfolio, ciudades, páginas de plugins), mientras un asistente de IA cita pocas fuentes por respuesta. Una GEO sensata concentra el esfuerzo en pilares de oferta y artículos expertos, no en pegar llmCard en cada página de ciudad de 2019. En wppoland.com agrupamos el trabajo en desarrollador WordPress, WooCommerce, mantenimiento, migración headless, MCP y contenido LLMO. El resto del sitio sigue viviendo de SEO clásico e indexación.

Joe Hall recordó en un hilo de finales de septiembre de 2026 que el hype va delante de la infraestructura: empresas compran audits GEO antes de arreglar URL canónicas y el primer párrafo de la página que pagan en Ads. Vemos el mismo patrón en España cuando una agencia instala un plugin de «AI SEO» en un sitio Elementor con LCP por encima de 4 s y espera citas en ChatGPT. En WordCamp Madrid 2026, las conversaciones de pasillo repetían ese guion: paneles brillantes de IA sobre checkouts WooCommerce lentos.

#¿Sirve llms.txt para aparecer en ChatGPT?

Mito: publicar un /llms.txt al estilo community hace que el modelo elija vuestra marca frente a la competencia.

Hecho: llms.txt es un documento orientador para rastreadores y agentes (lista de servicios, contacto, reglas de cita). No es un estándar W3C registrado, y no hay un parser garantizado en cada producto de OpenAI o Google. Google Search Central sigue hablando de HTML, enlaces internos y datos estructurados, no de llms.txt como señal de ranking.

La guía de optimización para IA de Google (actualizada por última vez el 10 de julio de 2026) incluye los archivos llms.txt, trocear el contenido en fragmentos pequeños y las menciones no auténticas entre las tácticas que puedes ignorar para la Búsqueda de Google, que no usa esos archivos. La misma página dice que mantener un llms.txt para otros servicios no ayuda ni perjudica a la visibilidad en la Búsqueda de Google.

Lo que hacemos: mantenemos /llms.txt con un párrafo de entidad (ingeniería WordPress senior, headless Astro/Next.js, WooCommerce, MCP, GEO/LLMO) y un bloque Services (English canonical URLs) que enlaza pilares que los agentes deben encontrar sin adivinar desde el menú. Es un atajo para bots, no un duplicado de todo el sitio. La actualización del 2026-10-02 añadió headless, MCP y GEO/LLMO junto a servicios anteriores.

Caso real: un cliente SaaS quería «solo llms.txt», sin tocar /pricing/. El archivo apuntaba a precios, pero el landing seguía abriendo con la historia de la empresa de 2014. Perplexity seguía citando la documentación de un competidor con una tabla de planes above the fold. Tras mover BLUF y una tabla comparativa al HTML, mejoraron las citas por paráfrasis. Nada se movió por un poder de ranking de llms.txt que no existe en Google orgánico.

#¿Conviene servir Markdown a los bots de IA en vez de HTML?

Mito: publicar /ai/ o content.md en Markdown limpio y dejar la página humana en un slider Divi.

Hecho: En la mayoría de pipelines de retrieval el HTML indexado va primero. Un Markdown separado sin link rel="canonical" y sin paridad con MDX o WordPress crea dos fuentes de verdad. Una semana después los precios del .md están obsoletos mientras el HTML está al día. El modelo cita cifras erróneas o salta la página por inconsistencia.

El patrón mejor en Astro o WordPress headless: un flujo de contenido, HTML semántico (article, h2, listas, tablas), frontmatter con llmCard.facts y FAQ en YAML renderizado tanto en JSON-LD como en FAQ visible al final. Markdown como formato de autoría en el repo (.mdx) está bien. Markdown como publicación bot separada rara vez compensa.

En pilares MDX de wppoland.com mantenemos speakable, howTo donde encaja, y no duplicamos artículos en /raw.md. Para agentes MCP exponemos APIs separadas (agent.json, herramientas MCP). Eso es un índice de capacidades, no un clon del blog.

Medido en otro sitio, octubre de 2026: Amir Pournasserian revisó 18 días de registros de Cloudflare de un sitio personal (del 30 de septiembre al 17 de octubre de 2026). Las copias en Markdown de ese sitio viven en direcciones .md, se generan a partir de los mismos archivos de contenido que el HTML, llevan noindex y cada página señala la copia correspondiente con <link rel="alternate" type="text/markdown">. Los rastreadores verificados empezaron a pedirlas el día siguiente al lanzamiento. En ocho días, 143 de las 152 peticiones que no salieron de las herramientas del propio autor llegaron de siete rastreadores verificados, con Amazonbot a la cabeza. Googlebot y Bingbot no pidieron ninguna copia. El llms.txt del sitio no recibió en 17 días ninguna petición de un rastreador verificado de IA o de búsqueda, y la única petición verificada de IA vino de Claude-User, que trae la página cuando una persona lo pide. El aviso sobre dos fuentes de verdad vale, por tanto, para un archivo Markdown mantenido a mano, y una copia generada desde la misma fuente lo evita. Las cifras cuentan peticiones en un sitio personal pequeño y no dicen qué hizo el rastreador con el contenido. En wppoland.com, la versión en Markdown sale de la misma fuente que el HTML y se sirve en la propia URL de la página cuando la petición pide Accept: text/markdown; la cabecera HTTP Link la señala con rel="alternate"; type="text/markdown", y no hay direcciones .md separadas (comprobado el 23 de octubre de 2026).

Actualización del 24 de octubre de 2026: la especificación abierta AgentReady, versión 2.0 (octubre de 2026), elaborada con el laboratorio de investigación ora.ai a partir de ejecuciones de agentes rastreadas, apunta en la misma dirección. Sus requisitos MUST para leer una web son la respuesta en el HTML inicial, renderizado en servidor o de antemano y no inyectado por JavaScript, y respuestas HTTP honestas: 404 para una página que no existe en lugar de 200, y 429 con Retry-After cuando limitas el tráfico. Las páginas de documentación propias, llms.txt y JSON-LD son requisitos SHOULD, y la especificación señala que los agentes solo llegan a los archivos pensados para máquinas cuando una página que ya han descargado enlaza a ellos. Una copia en Markdown es MAY, para cuando el HTML ya funciona. Un servidor MCP o una CLI solo pasa a ser obligatorio en productos donde el agente debe completar una tarea, no solo leer, y la especificación desaconseja montar uno vacío para cumplir el requisito.

Nota de campo: Barry Schwartz cubrió en Search Engine Roundtable en 2026 cómo AI Overviews empuja más respuestas de AI Mode. La historia de tráfico sigue siendo URL HTML en el índice de Google, no un sitio Markdown sombra en un subdominio sin enlaces. En tiendas que envían a Canarias con reglas de IVA distintas, un .md bot sin actualizar suele llevar plazos de envío incorrectos mientras la página legal en HTML sí está al día. Eso mata citabilidad antes que cualquier debate sobre llms.txt.

#¿Sirve el schema FAQPage para salir en la IA?

Mito: un plugin inyecta schema FAQ y Google AI o ChatGPT citan cada pregunta.

Hecho: FAQPage ayuda a los parsers a ver estructura Q&A. No garantiza: (a) indexación de la URL, (b) inclusión en conjuntos de fuentes de overviews, (c) elección del modelo en un chat sin browsing. Google documenta resultados enriquecidos FAQ para tipos de página elegibles; en 2026 seguimos viendo JSON-LD válido sin extensiones FAQ visibles en la SERP.

Lo que funciona junto al schema:

1. Preguntas en lengua de la query («cuánto cuesta migración headless WooCommerce»), no fraseo corporativo.
2. Respuestas cortas, con un hecho (fecha, alcance, excepción legal). Mismo copy en <div class="faq-answer"> que en JSON-LD.
3. lastVerified y fuentes en llmCard.sources en guides YMYL.

Nuestro audit de elegibilidad generativa (estilo Lumar, octubre 2026) en pilares de oferta comprueba FAQ o llmCard más señales de credibilidad. Fallamos el pilar headless en inglés hasta añadir fecha lastUpdated explícita en Astro. Schema solo, sin fechas y fuentes, pasaba el validador, no nuestra comprobación credibility_signals.

Medido con una muestra grande, octubre de 2026: SISTRIX (22 de octubre de 2026) comparó 48.527 páginas de la región DACH citadas por ChatGPT, Google AI Mode o AI Overviews en el segundo trimestre de 2026, cada una con una página no citada del mismo dominio: 96.418 URL de 17.380 dominios, 43 características por página, regresión logística condicional. Las páginas con schema FAQPage recibieron 1,5 veces más citas, siempre que las preguntas sean reales. Un índice de contenidos visible obtuvo 1,7 y el schema Article 1,6, mientras que el marcado Breadcrumb, HowTo y QAPage no mostró diferencia (1,0). Con llms.txt la comparación tuvo que hacerse entre dominios: el 11,7 % de las URL citadas procedía de dominios con el archivo, frente a una cuota del 14,0 % entre todos los dominios. No hay ventaja medible. Los autores hablan de correlación, no de causa, no probaron Perplexity, Claude ni el chat de Gemini y vieron cómo el efecto del FAQ cambiaba de signo en sus propias pruebas por debajo de unas 5.000 URL. Cómo lo abordamos en webs de clientes, con cualquier CMS: optimización GEO y LLMO.

#¿Importa el ranking en Google con AI Overviews?

Mito: como la IA responde en la SERP, las posiciones 1-3 son irrelevantes.

Hecho: El retrieval sigue dependiendo del índice y la calidad, y los AI Overviews ampliados se comen clics, no siempre citas. En nuestro artículo sobre AI Overviews documentamos filas de Search Console: posición 1,7 en una query de precios y cero clics porque la respuesta queda encima del enlace. Eso no hace irrelevante el ranking. Significa que top rank sin copy citável da visibilidad sin visitas.

La cobertura en búsquedas comerciales también sube. Semrush (21 de octubre de 2026) siguió 400 palabras clave con modificadores comerciales (alternativas, best X for Y, precio, opiniones, marca vs marca) en resultados de escritorio de EE. UU.: en agosto de 2026 el 88 % mostraba un AI Overview, frente al 45,75 % de septiembre de 2025.

Para una agencia WordPress:

• Long tail informativo sigue generando clics y entrada al embudo.
• Cabeza comercial (precios, «desarrollador WooCommerce») necesita BLUF, tablas, entidad en las primeras frases. Si no, el overview gana sin visita.
• Sin rank sigue significando que modelos con browsing a menudo no tienen de dónde tirar vuestra URL.

GEO sin SEO es intentar citar una página que Google no promueve en queries de dinero.

#¿Puede la GEO sustituir al SEO?

Mito: contratar un «especialista GEO» y dejar el SEO congelado desde 2018.

Hecho: GEO se solapa con SEO técnico y contenido. Apagar SEO implica: noindex de staging filtrando a producción, cero enlaces internos a pilares, canonicalUrl sin actualizar tras migración Astro. Entonces ningún arreglo de llmCard arregla retrieval.

Las cifras de tráfico van en la misma dirección: en el estudio de The SEO Works con 95 sitios (septiembre de 2025 a agosto de 2026), la búsqueda orgánica trajo 39 veces más tráfico que los asistentes de IA.

Terreno mínimo compartido para agencias:

Entregar solo GEO sin audit de Core Web Vitals en WooCommerce es relaciones públicas, no ingeniería. Vimos una tienda con 40 plugins y «optimizado para ChatGPT» en el footer: TTFB 1,8 s, sin lastVerified, FAQ copiado 1:1 de un competidor. El asistente seguía citando Shopify Help Center.

#Checklist GEO para una web WordPress

Checklist concreto de octubre 2026 para separar hype de trabajo:

1. public/llms.txt - entidad más URL canónicas de servicio EN (headless, MCP, GEO/LLMO añadidos en este pase de orquestación).
2. Script npm run audit:generative-eligibility-pillars - seis comprobaciones (BLUF, title, cobertura de query, un objetivo por página, credibilidad, FAQ/llmCard) en seis pilares; --check para CI.
3. Frontmatter GEO (llmCard, faq, speakable, lastVerified) en guides y pilares MDX, no copiado en miles de páginas de ciudad.
4. Páginas about (PL, EN, DE, NB, PT-PT) - frase de entidad alineada con llms.txt (ingeniería senior, headless, MCP, GEO/LLMO).
5. Artículos LLMO y AI Overviews - línea educativa separada. Este post desmonta mitos; no repite un tutorial de bots.

No prometemos «#1 en ChatGPT en 30 días», sitios Markdown separados ni schema FAQ masivo en páginas de ciudad que deberían quedar noindex.

#¿Merecen la pena los plugins AI SEO para WordPress?

El directorio de plugins en 2026 lista decenas de extensiones con «AI», «GEO» o «LLMO» en el título. La mayoría envuelve llamadas a API de OpenAI para meta descriptions o generación masiva de FAQ. Ninguna sustituye higiene de rastreo.

Antes de instalar otro panel:

• Leed si el plugin escribe FAQ visible en HTML o solo JSON-LD. Schema oculto sin copy en body falla nuestras comprobaciones de duplicado y credibilidad.
• Comprobad si genera seis variantes de locale como plantillas 1:1. Ese patrón dispara nuestro gate de retórica AI-slop en sitios traducidos.
• Medid INP en checkout tras activar. Un cliente en Barcelona perdió 0,4 s en checkout móvil cuando un plugin de «AI schema» encoló un segundo bundle jQuery sobre WooCommerce ya cargado con scripts legacy del tema.

Preferid reescribir un pilar antes que diez toggles de plugin.

#GEO en webs WordPress multilingües

wppoland.com publica seis locales. Los errores GEO se multiplican cuando cada idioma recibe la misma frase de entidad en inglés pegada en llmCard.entity.

Reglas que seguimos:

• Mismo wpId, ejemplos de practitioner distintos por locale (normativa regional, WordCamp local, contexto de moneda en landings de precios solo donde está permitido).
• llms.txt sigue EN-first para URL de servicio, con páginas humanas localizadas. Los agentes a menudo resuelven slugs de servicio en inglés primero; los landings localizados siguen necesitando BLUF en idioma de mercado.
• hreflang y canonical siguen siendo trabajo SEO. GEO no arregla una página en portugués que canonicaliza a una URL que no existe.

Make WordPress Slack y el grupo Advanced WordPress en Facebook siguen sacando historias de rotura en producción más rápido que los decks de vendors. Enlazamos esas comunidades en onboarding, no como citas, sino como recordatorio de que WordPress en producción es desordenado.

#Ayuda un dominio .es a las citas en IA para B2B

Aleyda Solis lo midió en Local vs Global AI Citations, publicado el 8 de octubre de 2026: citas de ChatGPT, Gemini y AI Mode en diez temas, con una misma biblioteca de prompts localizada para Estados Unidos, Reino Unido, España y Brasil. Los dominios nacionales (.uk, .es, .br) se llevaron el 38,3% de las citas en Reino Unido, el 24,0% en España y el 41,4% en Brasil. España es el mercado con menor cuota local de los tres, y el B2B es el tema más bajo:

«El software B2B y el SaaS tienen una cuota local baja en los tres países: 14,3% en Reino Unido, 10,5% en España y 15,9% en Brasil.»

Aleyda Solis, Local vs Global AI Citations, 8 de octubre de 2026, traducción propia

En España la plataforma también cambia el resultado: la cuota local es del 24,8% en ChatGPT, 22,6% en AI Mode y 16,6% en Gemini. Dentro de B2B y SaaS en España, AI Mode llega al 15,7% local, ChatGPT al 10,4% y Gemini al 9,4%. Nuestra lectura:

• En B2B, la extensión del dominio por sí sola es una palanca débil. Solis usa el ccTLD como señal de segmentación por país y advierte que los dominios genéricos como .com también publican contenido local. Pasar una instalación WordPress B2B de la subcarpeta /es/ a un .es pensando en la visibilidad en IA no tiene respaldo en estos datos. Lo que controlas es el contenido escrito para cada mercado.
• Mide cada mercado y cada plataforma por separado. Google y YouTube suponen entre el 19 y el 45% de las citas de AI Mode, y la coincidencia normalizada de URL con los resultados de Estados Unidos va del 1,7% al 35,7%. Una muestra de prompts para España no sirve para México o Argentina: el estudio no cubre ningún mercado de Latinoamérica, y Brasil no es hispanohablante. Polonia, Alemania, Noruega y Portugal tampoco se estudiaron.

#Plan GEO de 90 días para WordPress y WooCommerce

Días 1-14: entidad y pilares

• Una frase: quién, audiencia B2B/B2C, tres servicios canónicos.
• Coherencia: footer, about, llms.txt, LinkedIn. Mismo núcleo, ejemplos localizados, no seis traducciones copy-paste.
• Elegid 3-6 URL pilar. El resto del sitio solo enlaza hacia dentro.

Días 15-45: copy citável

• El primer párrafo de cada pilar responde la query más nombre de empresa.
• Una tabla comparativa o banda de alcance sin romper reglas de voz (la página de precios lleva rangos de mercado; pilares usan bandas «desde» en EUR por mercado).
• Cinco a ocho ítems FAQ en lenguaje de cliente, reflejados en JSON-LD.

Días 46-70: técnico

• Canonicals, indexación, CWV en checkout WooCommerce.
• lastVerified y dos o tres fuentes externas (Wikidata, docs WooCommerce, WordPress Developer Handbook) en llmCard.sources.
• llms.txt solo si lo actualizáis en cada servicio nuevo.

Días 71-90: medición

• Search Console en la propiedad https://wppoland.com/es/ (sin mezclar locales en un filtro del dominio raíz): queries con posición por debajo de 5 y CTR por debajo del 1 % (señal de overview, no un «GEO score»).
• Conjunto manual de prompts (véase docs/plans/prompt-sampling-core-2026-q4.json en nuestro repo): cinco repeticiones, registrar si aparece URL o marca.
• No cambiéis prompts núcleo a mitad de trimestre.

Si el único entregable tras 90 días es un PDF de «AI readiness» sin cambios HTML en pilares, ganaron los mitos.

#Cómo evaluar una auditoría GEO

Un buen entregable de audit GEO nombra URL y muestra diffs: primer párrafo antes y después, FAQ añadido al frontmatter, entrada en llms.txt. Uno malo termina en un mapa de calor «AI visibility score» sin Search Console, fechas de rastreo ni comprobación de que el pilar está en el sitemap.

Preguntas para vendor o equipo interno:

1. ¿Cuáles son las tres URL comerciales prioritarias y qué cambió en HTML?
2. ¿canonicalUrl tras migración Astro apunta a una página que existe en el build? (Cargamos cientos de canonicals de portfolio obsoletos como dato histórico, no como patrón para pilares.)
3. ¿FAQ duplica copy del body, o acorta respuestas de frontmatter frente a párrafos MDX más largos? (Regla: nunca borrar texto más rico del body.)
4. ¿Se actualizó llms.txt en el mismo commit que un cambio de oferta MCP o headless?

Respuestas vagas significan que comprasteis un informe, no GEO.

#GEO en catálogos grandes de WooCommerce

Una instalación WooCommerce mid-market con 12 000 SKU y navegación facetada genera ruido de rastreo que ningún llmCard en un landing de ciudad arregla. El trabajo GEO pertenece a historias de categoría, páginas de envíos y devoluciones, y tres pilares de servicio, no a cada URL de variante.

Usamos un filtro simple con comerciantes:

• Si la URL es noindex o existe solo para combinaciones long-tail de SKU, saltad frontmatter GEO. Arreglad canonicals.
• Si la URL gana queries de dinero en GSC (marca más servicio, implementación, rescate), recibe BLUF, FAQ y lastVerified trimestral.
• JSON-LD de producto sigue para lógica de Google Shopping. Schema FAQ en fichas de producto rara vez compensa el mantenimiento salvo que preguntas de soporte se repitan en tickets.

Un retailer outdoor nórdico siguió añadiendo schema FAQ a 400 plantillas de producto vía plugin bulk. Las respuestas vivían en Zendesk, no en WordPress. Las citas no se movieron. Mover cinco URL de política a lenguaje llano con fechas y enlaces about Wikidata hizo más por paráfrasis en IA en ocho semanas que un año de schema a nivel SKU. En España, tiendas con envío peninsular vs Canarias obtienen más citas útiles cuando la página de envíos tiene plazos, excepciones aduaneras y lastVerified visibles, no cuando hay FAQ schema en cada variación de talla.

#Cómo medir la visibilidad de marca en respuestas de IA

Los decks de vendors adoran un único «GEO visibility score». Medimos algo más estrecho:

• Cinco prompts de marca desde docs/plans/prompt-sampling-core-2026-q4.json, cinco veces al mes, registrados en hoja de cálculo con fecha y versión de modelo.
• Filas de query en Search Console donde la posición media es mejor que 5 pero el CTR está por debajo del 1 %. Ese emparejamiento suele marcar absorción por overview, no un sitio roto.
• Comprobaciones manuales en Perplexity con browsing activado vs desactivado, porque los caminos de retrieval difieren.

No tratamos trackers third-party aleatorios de «AI rank» como verdad absoluta. Rotan modelos, geos y estado de login. Usadlos solo para picos direccionales, siempre junto a vuestra lista de URL y fechas de rastreo de URL Inspection en GSC en la propiedad /es/ (no un filtro multilocale en el dominio raíz).

Cuando un conjunto de prompts muestra vuestra marca pero nunca vuestra URL, el arreglo casi siempre es copy de pilar, no otra línea en llms.txt.

#Resumen

GEO para WordPress es disciplina de entidad y citabilidad en pilares que deben rankear y seguir indexados de todos modos. llms.txt ayuda a agentes a encontrar las URL correctas. No sustituye el copy. Markdown solo para bots sin HTML es deuda técnica. Schema FAQ sin BLUF y fechas de verificación es teatro de validador, no estrategia. Los rankings siguen condicionando si entráis en el pool de fuentes. AI Overviews cambian clics, no la necesidad de estar en el índice. SEO y GEO van juntos, o pagáis por una palabra de moda.

Más lectura en wppoland.com: resumen estratégico LLMO, Google expande AI Overviews, pilar SEO, GEO y AEO en WordPress. La orquestación del audit vive en docs/plans/2026-10-02-geo-orchestration.md en el repositorio.