SEO Técnico que resiste AI Overviews, reconstrucciones headless y tu próxima actualización de algoritmo.

El SEO técnico es la capa de trabajo que determina si los motores de búsqueda y los asistentes de IA pueden rastrear, renderizar y confiar en tus páginas — antes de que el contenido o los enlaces de retroceso tengan efecto. Cubre comportamiento HTTP, semántica HTML, datos estructurados, hreflang, canonicalización, Core Web Vitals y renderizado de JavaScript. Si lo haces mal, el resto de tu inversión es peso muerto.

En 2026 la definición se ha ampliado. Dos cambios lo impulsaron. Primero, AI Overviews y la búsqueda potenciada por ChatGPT ahora se interponen entre la mayoría de usuarios y las páginas subyacentes, lo que significa que la preparación para citación importa tanto como el posicionamiento. Segundo, el sitio modal ya no es una instalación de WordPress — es alguna versión de front-end headless que extrae contenido de Sanity, Strapi, Payload, Storyblok, Contentful o un backend WordPress headless. Cada uno de esos stacks introduce sus propios modos de fallo en SEO técnico que el antiguo manual de estrategias no cubre.

Mi definición de trabajo para clientes en 2026: SEO técnico es todo lo que una ejecución de Lighthouse, un reporte de rastreo de Search Console, una verificación de citación de AI Overview y un validador de schema detectan — en cada locale, cada plantilla, cada ruta de renderizado. Si alguno de esas cuatro señales está fallando en una URL representativa, el compromiso comienza ahí.

En un sitio headless o Jamstack, tu framework front-end es responsable del renderizado y tu CMS es responsable del contenido — y el SEO puede caer en el vacío entre ambos. El modelo clásico de WordPress + Yoast asumía un servidor, un renderizador, un motor de reglas. Cuando sacas contenido de WordPress hacia Next.js o Astro, no heredas nada de eso automáticamente.

WordPress headless emparejado con Next.js o Astro

La configuración más común que vemos en 2026: WP REST o WPGraphQL exponiendo posts y páginas, Next.js App Router o Astro jalando contenido en tiempo de compilación o vía ISR. Los beneficios son reales — las páginas se entregan sin hinchazón de plugins, Core Web Vitals son fáciles de mantener en verde, y los editores conservan un admin familiar. Los obstáculos también son reales. Los canonicals y meta descripciones de Yoast necesitan transportarse cruzando el límite de la API; los redirects definidos en WordPress necesitan aterrizar en vercel.json o Netlify _redirects; los sitemaps usualmente necesitan regenerarse en la compilación del front-end, no del lado de WordPress; y la verificación de Search Console necesita suceder en el origen público, no en el dominio wp-admin.

Stacks modernos puros

Una compilación Next.js + Sanity, una compilación Astro + Storyblok, una compilación Nuxt + Strapi, una compilación Next.js + Payload — todos saltan WordPress por completo. El trabajo de SEO técnico se desplaza a asegurar que el esquema de tu CMS modele los campos SEO que el front-end necesita (canonical override, redirect map, hreflang group, schema-extension JSON), y asegurar que la revalidación bajo demanda se dispare cuando el contenido cambia. El envenenamiento de caché ISR es el asesino silencioso — una página se sirve obsoleta durante horas después de publicar porque revalidatePath nunca fue conectado.

Qué realmente se rompe primero

En aproximadamente 200 auditorías headless que hemos ejecutado, el problema que rompe producción más común es el conflicto de canonical — el front-end emitiendo una URL canonical mientras los metadatos del CMS o el sitemap emiten otra. Google elige una, casi siempre no la que quisiste, y la URL equivocada termina en el índice. Lo atrapamos con un linter en tiempo de compilación que compara canonical-emitido-desde-template contra canonical-almacenado-en-CMS para una muestra de páginas y falla la compilación si no coinciden.

WordPress te entrega la mayor potencia de plugins y la mayor cantidad de formas de dispararte a ti mismo. El playbook de SEO técnico en un sitio clásico de WordPress es mayormente cuestión de sustracción — remover canonicals duplicados, eliminar peleas de schema entre Yoast y RankMath y un tercer plugin que nadie recuerda haber instalado, domar page builders que envían 2 MB de CSS, y limpiar cadenas de redirects que han crecido durante ocho años.

El stack por defecto que recomendamos en 2026: un único plugin SEO (RankMath o Yoast, nunca ambos), un host administrado con proper edge caching (Cloudways, Kinsta, WP Engine), Bricks Builder para nuevas compilaciones donde el rendimiento importa o Gutenberg nativo con Kadence o Blocksy, un administrador de redirects que exporte a un formato portátil, y Perfmatters o FlyingPress para limpieza de assets. El trabajo de auditoría es encontrar cuál de esas decisiones fue tomada diferente en tu sitio y deshacer las consecuencias.

En el lado headless, el trabajo pasa de la sustracción a la construcción. No hay Yoast, así que el meta clamping tiene que construirse. No hay schema de plugin, así que JSON-LD tiene que templarse. No hay sitemap integrado, así que tiene que generarse y transmitirse. El volumen de código que agregamos a un proyecto headless para SEO es generalmente de tres a cinco veces lo que un sitio WordPress ya te da gratis — pero ese código es propio, versionado, testeable, y no se rompe en la próxima actualización de plugin.

GEO y AEO son los nombres de dos formas diferentes en que las características de IA consumen tráfico de búsqueda. AEO (Answer Engine Optimisation) es el término más antiguo — cubre características de Google como Featured Snippets, People Also Ask, y Knowledge Panels que extraen un fragmento de tu página y lo muestran como la respuesta. GEO (Generative Engine Optimisation) es el término más nuevo — optimizar para AI Overviews, ChatGPT search, Perplexity, y Bing Copilot, donde el asistente genera un párrafo y cita tu página como fuente.

Qué significa eso estructuralmente

Ambas superficies quieren lo mismo: un fragmento listo para citar. Las reglas estructurales que funcionan en todas ellas son las mismas. Usa una pregunta como tu H2, no una etiqueta de tema. Pon la respuesta en la primera o dos oraciones después del encabezado. Mantén esa respuesta bajo 250 palabras. Asegúrate de que la respuesta se renderice del lado del servidor, no dentro de un componente JavaScript que se hidrate después de que cargue la página. Los rastreadores de IA y los extractores de Google generalmente no ejecutan JavaScript — si tu respuesta necesita JS para aparecer, eres invisible.

Dónde GEO se diferencia de AEO

Tres cosas importan más específicamente para GEO. Entity authority — Google y los LLMs construyen un grafo de quién tiene permitido hablar sobre qué, y las menciones de marca no vinculadas lo alimentan. Schema con arrays about y mentions — hacen que tu página sea analizable como parte de un grafo de entidad en lugar de un muro de texto. Y llms.txt — un archivo estándar emergente en /llms.txt que le da a las herramientas de IA un mapa curado de tu sitio, de la misma manera que robots.txt y sitemap.xml ayudan a los rastreadores de búsqueda. Desplegamos llms.txt en cada sitio que construimos y lo actualizamos cada vez que llega una página importante.

Necesitas menos tipos de schema que los que emiten la mayoría de plugins, pero los que envíes tienen que ser válidos y consistentes. Una lista corta cubre nueve de cada diez proyectos.

• Organization — un único grafo en todo el sitio en tu layout, con logo, sameAs (solo cuentas sociales reales), address, y contactPoint. Nunca dupliques esto por página.
• WebSite — una sola vez, en el layout, con potentialAction para búsqueda de sitelinks si tienes búsqueda en el sitio.
• BreadcrumbList — en cada página que no sea inicio, con URLs localizadas correctamente (una página en francés debe apuntar a ancestros /fr/, no /en/).
• Article o BlogPosting — en contenido de largo formato, con arrays about y mentions para refuerzo del entity-graph.
• Service — en páginas comerciales, con serviceType, provider, areaServed, audience, y offers.priceSpecification cuando puedas publicar un rango de precios.
• Product — en ecommerce, con offers.priceCurrency, availability, y aggregateRating solo si tienes reseñas reales.
• FAQPage — cuando hay al menos dos preguntas genuinas en la página. Inventar FAQs para ganar marcado schema es el disparador de acción manual más común que limpiamos.
• LocalBusiness o uno de sus subtipos — en páginas de ubicación física, con coordenadas geográficas y openingHoursSpecification.

Tres cosas matan schema en producción. Inventar propiedades que schema.org no define. Inventar valores para sameAs (URLs falsas de LinkedIn, handles de Twitter abandonados). Y enviar grafos Organization conflictivos desde múltiples plugins. Ejecutamos validadores schema en el linter de compilación y fallamos la compilación en cualquiera de esos tres patrones.

Hreflang falla a escala porque la restricción es bidireccional y el dataset es disperso. Cada variante de locale de una página debe auto-referenciarse, debe referenciar cada otra variante, y debe ser referenciada de vuelta por cada otra variante. Pierde una dirección en una página en un locale y Google silenciosamente degrada el cluster.

El patrón que escala

Almacena un content_group_id (o equivalente) en cada fila traducible. Cada variante local de una página comparte un ID. El emisor de hreflang, el emisor de sitemap y el emisor de canonical derivan su cluster de ese ID. Nunca calcules hreflang solo a partir de coincidencia de patrones de URL — se desmorona en casos extremos (una página en español que no tiene traducción al hindi rompe el cluster si tu código asume "si pageX existe en la locale A, existe en la B").

Lo que mata hreflang en la práctica

Tres patrones que vemos repetidamente. Orden de regex de locales — poner "zh" antes de "zh-Hant" en tu regex de detección de locale, que captura la locale equivocada y escribe un hreflang roto. Olvidar x-default — cada cluster necesita un fallback x-default, usualmente apuntando a la versión en inglés. Desvío de cluster ID — una traducción obtiene un ID nuevo en lugar de heredar el ID de la fuente, dividiendo silenciosamente un único cluster en dos no relacionados, ninguno de los cuales tiene un conjunto recíproco completo.

Siempre agregamos un linter de hreflang en tiempo de construcción que rastrea una muestra de páginas, recorre los clusters de hreflang que referencian, y falla la construcción si algún cluster está incompleto o es asimétrico.

SEO programático es generar miles de páginas a partir de una fuente de datos estructurados más una plantilla — directorios, páginas de comparación, páginas de ubicación, páginas de glosario. Hecho correctamente puede impactar la cola larga en una escala que un contenido de autor único no puede igualar. Hecho incorrectamente dispara una acción manual y elimina la mayoría de tus páginas indexadas de la noche a la mañana.

Qué separa una construcción programática limpia de una delgada

Tres cosas. Datos reales por página — cada URL tiene al menos un hecho, número o detalle único para ella; las páginas programáticas delgadas comparten el 95% de su contenido. Una plantilla significativa — la plantilla agrega contexto, comparación, recomendación o agregación alrededor de los datos únicos, no solo un envoltorio optimizado para búsqueda. Y filtrado de calidad — las páginas con datos únicos insuficientes se mantienen fuera del sitemap, se bloquean del índice, o se mantienen en estado de borrador hasta que la capa de datos se complete.

Lo que hemos aprendido al ejecutar esto a escala

Construí HostList.io como una plataforma de SEO programático con alrededor de 28,000 páginas de empresas de hosting web en Next.js más Supabase. Las páginas que sobrevivieron dos años de actualizaciones de Google fueron las que tenían al menos tres puntos de datos únicos por URL más una plantilla que comparaba, puntuaba o recomendaba basándose en esos datos. Las páginas que desindexamos fueron aquellas donde el único dato único era un nombre y un precio. El costo de sacar páginas delgadas del índice fue pequeño; el costo de dejarlas fue una penalización de ranking en todo el sitio cuando llegó la actualización de contenido útil de marzo de 2024.

Llevamos ese manual operativo a las construcciones programáticas de clientes — frontend en Next.js o Astro, datos en Supabase o Postgres, un pipeline de ingesta que califica páginas por unicidad antes de publicar, un sitemap que se transmite en fragmentos porque más de 50,000 URLs no pueden caber en un único sitemap.xml, y un gráfico de enlaces internos que extrae cada página hoja hacia un cluster temático.

Pasa Core Web Vitals en el percentil 75 de datos de campo, no en una ejecución controlada de Lighthouse. Los datos de campo de CrUX son lo que Google usa; Lighthouse es una herramienta de depuración. Los dos a menudo discrepan en un 30% o más en sitios reales.

A DÓNDE VA REALMENTE EL PRESUPUESTO

LCP es casi siempre la imagen hero y casi siempre se resuelve recodificando a WebP con 80% de calidad, dimensionando a las dimensiones reales de visualización más 2x retina, agregando una etiqueta preload en el head, y estableciendo fetchpriority="high". Una imagen hero de 1 MB que se convierte en un WebP de 30 KB es el cambio de mayor impacto en la mayoría de proyectos. CLS proviene de imágenes y anuncios sin dimensiones explícitas — atributos width y height explícitos en cada imagen, slots de anuncios de altura fija, y espacio reservado para cualquier widget del lado del cliente. INP proviene de JavaScript pesado en la interacción — generalmente un gestor de etiquetas de terceros o una librería de análisis demasiado entusiasta. La solución es debouncing, lazy-loading, o reemplazar con un equivalente más ligero.

DÓNDE LA MAYORÍA DE PROYECTOS SE QUEDA CORTO

Dos patrones. Primero, una imagen LCP dentro de un componente Carousel o un layout impulsado por JavaScript — la imagen solo se renderiza después de que se ejecuta el JS, y tu LCP es el esqueleto de carga del carousel, no la foto. Segundo, fuentes web cargadas sin font-display: swap y sin preload — el texto es invisible durante 200-400 ms mientras se descargan las fuentes, y tu LCP se empuja más allá del umbral de 2.5 s aunque la imagen sea rápida. Ambos se detectan en una revisión de datos de campo de CrUX, no en una única ejecución de Lighthouse.

Un linter de SEO en tiempo de compilación es un script que se ejecuta al final de tu compilación, toma una muestra de archivos HTML renderizados del directorio de salida, y falla la compilación si encuentra patrones que degradarían el SEO en producción. Es el hábito de mayor impacto que agregamos a los codebases de clientes.

Lo que nuestras verificaciones controlan

• Cada página tiene exactamente un H1.
• La meta descripción en cada URL indexable tiene entre 120 y 155 caracteres.
• El atributo html lang coincide con la ruta de locale (una página /fr/ tiene lang="fr").
• Los clusters de hreflang están completos y son bidireccionales en rutas traducibles.
• El JSON-LD en cada página es válido según las definiciones de schema.org.
• Sin patrones de contenido prohibido — URLs falsas de redes sociales en sameAs, texto de placeholder de prueba codificado, palabras de copywriting genéricas prohibidas.
• La URL canónica emitida por la plantilla coincide con la canónica almacenada en el CMS.
• Verificación de WebP en imágenes y dimensiones explícitas en una muestra de plantillas.

El linter se ejecuta como el último paso de npm run build. Cualquier violación detiene la compilación, lo que detiene el deploy. Sin él, cada regresión — una meta descripción que creció por encima del límite, un campo SEO que alguien olvidó configurar, un emisor de schema que se rompió cuando una propiedad fue renombrada — se envía silenciosamente. Con él, la regresión se detecta antes de que abandone la laptop del desarrollador.

Consigue citas escribiendo cada página relevante como un conjunto de pasajes listos para citar. Un pasaje listo para citar es un H2 en forma de pregunta, una respuesta directa de una o dos oraciones inmediatamente después, matices de apoyo en los siguientes 100-200 palabras, y cero contenido renderizado con JavaScript en el bloque de respuesta. Los extractores de IA toman esa oración inicial y citan la página.

Qué ayuda más allá de la estructura de pasajes

• Autoridad de entidad — presencia en Wikipedia, schema de organización consistente, cuentas reales de sameAs, menciones de marca en toda la web abierta.
• llms.txt en la raíz del sitio — un mapa curado del sitio para herramientas de IA, separado del robots.txt y sitemap.xml que sirven a los rastreadores tradicionales.
• Schema con about y mentions en contenido de formato largo — declara el gráfico de entidades dentro del cual se sitúa la página.
• Lista de permitidos de robots.txt para rastreadores de IA — permite explícitamente GPTBot, PerplexityBot, ClaudeBot, OAI-SearchBot, Google-Extended, Applebot-Extended, CCBot y Anthropic-AI. Bloquear incluso uno de estos es un apagón de citas autoinflíngido.
• Propiedad schema speakable en las secciones ricas en respuestas de páginas de formato largo — una indicación a extractores de voz e IA de que este es el pasaje que se puede citar.

El seguimiento de citas es la parte que la mayoría de los equipos omiten. Otterly, Profound y AthenaHQ rastrean la cuota de citas de AI Overview y Perplexity por dominio. Añadimos seguimiento de citas semanal además de cada engagement y lo reportamos junto con el tráfico orgánico. Si no estás midiendo citas no puedes saber si tu trabajo de GEO está haciendo algo.

Los crawlers de IA pueden leer tu sitio solo si tu robots.txt permite explícitamente su user-agent y tu capa de hosting no los bloquea en el perímetro de la red. Ambas verificaciones deben pasar. La configuración predeterminada de Cloudflare, las reglas predeterminadas del WAF de Vercel y los plugins de seguridad WordPress predeterminados rutinariamente bloquean bots de IA sin previo aviso.

La lista de permiso robots.txt que entregamos

GPTBot y ChatGPT-User y OAI-SearchBot para productos ChatGPT y búsqueda OpenAI. PerplexityBot y Perplexity-User. ClaudeBot y Claude-Web y anthropic-ai. Google-Extended para Bard y AI Overviews. Applebot-Extended. CCBot para Common Crawl, que alimenta muchos modelos de código abierto. Cohere-AI. Meta-ExternalAgent. Bytespider —el crawler de TikTok— generalmente bloqueado porque es agresivo y la mayoría de proyectos no quieren que TikTok use su contenido.

Lo que también tienes que hacer

Robots.txt es necesario pero no suficiente. Tres verificaciones adicionales. Cloudflare bot fight mode y bot management —desactiva los que bloquean agentes de IA, o agrégalos a la whitelist por IP y user-agent. Vercel WAF y Edge Middleware —asegúrate de que no coincidan con user agents de IA en una regex genérica. Plugins de seguridad WordPress como Wordfence —a menudo incluyen reglas que bloquean GPTBot y PerplexityBot por defecto; agrega explícitamente a la whitelist. Prueba haciendo curl de cada user agent contra tres URLs representativas y confirma una respuesta 200.

Construimos bases técnicas de SEO alineadas con el UK Government Digital Service Standard y el GOV.UK Design System. El Estándar GDS es el conjunto más rigurosamente documentado de principios de calidad de servicios digitales en el dominio público: mejora progresiva, accesibilidad WCAG 2.2 AA, rendimiento, HTML semántico y degradación elegante cuando JavaScript falla. Lo seguimos en cada engagement de SEO técnico de Seahawk.Government Digital Service Standard and the GOV.UK Design System. The GDS Service Standard is the most rigorously documented set of digital-service quality principles in the public domain: progressive enhancement, accessibility to WCAG 2.2 AA, performance, semantic HTML, and graceful degradation when JavaScript fails. We follow it on every Seahawk technical SEO engagement.

Por qué importa esto específicamente para SEO: los sitios alineados con GDS pasan Core Web Vitals consistentemente, clasifican bien en búsqueda orgánica clásica, y están únicamente bien posicionados para citas en AI Overview porque la claridad estructural que GDS exige es la misma claridad estructural que los extractores de búsqueda de IA obtienen. El estándar es anterior a la era de búsqueda por IA pero se mapea perfectamente en ella.

Para clientes empresariales del Reino Unido, sector público e industrias reguladas, la alineación con GDS es una señal real de adquisición. Para todos los demás, es un marcador de calidad que distingue el trabajo de las agencias que entregan con un estándar más bajo.

De tres a diez semanas, tres fases, precio fijo. La fase uno es auditoría — crawl completo, revisión de GSC y Ahrefs, validación JSON-LD, verificación de clúster hreflang, extracción de datos de campo de Core Web Vitals, línea base de citas de IA. La fase dos es remediación — enviamos las correcciones, tu equipo o el nuestro. La fase tres es la capa de linter y monitoreo que previene regresiones.

Los entregables de la fase de auditoría

• Crawl completo de Screaming Frog en CSV más un brief escrito sobre los problemas que importan, clasificados por impacto.
• Exportación de Search Console — reporte de cobertura, consultas, rendimiento a nivel de página — con anotaciones sobre qué es anómalo.
• Pasada de validador de schema sobre una muestra de plantillas y una nota escrita sobre cada tipo que está roto o falta.
• Reporte de integridad del cluster hreflang en las rutas traducibles.
• Extracción de datos de campo de Core Web Vitals desde CrUX con un gráfico de las últimas 25 semanas por métrica.
• AI Overview y línea base de citas de Perplexity — participación actual, análisis de brecha contra tres competidores nombrados.

La fase de remediación

Trabajo de alcance fijo. Cada ticket tiene un estado anterior claro y un estado posterior claro. Los entregamos en orden de prioridad y puedes detener el engagement en cualquier hito si se agota el presupuesto. El primer lote que entregamos son siempre los elementos que fallan el linter de compilación — tienen el camino más corto al valor porque regresarán sin el linter, y una vez que el linter esté en su lugar, cada corrección se mantiene.

La fase de monitoreo

Linting automatizado semanal en staging y producción, reporte mensual de Core Web Vitals, seguimiento mensual de citas AI, y un canal de Slack mantenido activo donde respondo a cualquier cosa que Google o tu equipo señale. Entregamos los dashboards al cierre para que mantengas visibilidad sin importar si renuevas o no.