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

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

En 2026 la definición se ha ampliado. Dos cambios la impulsaron. Primero, AI Overviews y búsqueda potenciada por ChatGPT ahora se interponen entre la mayoría de usuarios y las páginas subyacentes, lo que significa que la disposición para ser citado importa tanto como el posicionamiento. Segundo, el sitio modal ya no es una instalación de WordPress, es alguna variante de front-end headless que obtiene 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 manual antiguo 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 esquema noten, en cada idioma, cada plantilla, cada ruta de renderizado. Si cualquiera de esas cuatro señales falla en una URL representativa, el trabajo comienza ahí.

En un sitio headless o Jamstack, tu framework front-end es responsable del renderizado y tu CMS es responsable del contenido, y SEO puede caer en el vacío entre ambos. El modelo clásico de WordPress + Yoast asumía un servidor, un renderer, un motor de reglas. Extrae contenido de WordPress hacia Next.js o Astro y 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 extrayéndolas en tiempo de compilación o vía ISR. Las ventajas son reales, las páginas se envían sin bloat de plugins, los Core Web Vitals son fáciles de mantener en verde, y los editores conservan un admin familiar. Los peligros también son reales. Las canonicalización y descripciones meta de Yoast necesitan transportarse a través del límite de la API; los redirects definidos en WordPress necesitan terminar en vercel.json o _redirects de Netlify; 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, todas omiten WordPress completamente. 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 (override canónico, mapa de redirects, grupo hreflang, JSON de extensión de esquema), 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 la publicación porque revalidatePath nunca fue conectado.

Qué realmente se rompe primero

En alrededor de 200 auditorías headless que hemos ejecutado, el problema más común que rompe la producción es conflicto canónico, el front-end emitiendo una URL canónica mientras los metadatos del CMS o el sitemap emiten otra. Google elige una, casi siempre no la que querías, y la URL incorrecta termina en el índice. Lo detectamos con un linter en tiempo de compilación que compara la canónica emitida por la plantilla contra la canónica almacenada en el CMS para una muestra de páginas y falla la compilación en caso de desajuste.

WordPress te entrega el máximo poder de plugins y la mayoría de formas de dispararte. El manual de SEO técnico en un sitio WordPress clásico es principalmente sobre resta, eliminando canonicalización duplicada, matando peleas de esquema entre Yoast y RankMath y un tercer plugin que nadie recuerda haber instalado, domando constructores de páginas que envían 2 MB de CSS, y limpiando 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 se mueve de resta a construcción. No hay Yoast, así que el pinzamiento meta tiene que ser construido. No hay esquema de plugin, así que JSON-LD tiene que ser templado. No hay sitemap integrado, así que tiene que ser generado y transmitido. El volumen de código que añadimos a un proyecto headless para SEO es usualmente 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 párrafo de tu página y lo muestran como respuesta. GEO (Generative Engine Optimisation) es el término más nuevo, optimización para AI Overviews, búsqueda en ChatGPT, 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 párrafo listo para ser citado. Las reglas estructurales que funcionan en todas ellas son iguales. Usa una pregunta como tu H2, no una etiqueta de tema. Coloca la respuesta en la primera o dos primeras 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 la página cargue. Los rastreadores de IA y los extractores de Google principalmente 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. Autoridad de entidad, Google y los LLMs construyen un gráfico de quién está autorizado a hablar sobre qué, y las menciones de marca sin enlace lo alimentan. Schema con arrays about y mentions, hacen que tu página sea analizable como parte de un gráfico de entidad en lugar de un muro de texto. Y llms.txt, un archivo de estándar emergente en /llms.txt que proporciona 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 gráfico en todo el sitio en tu layout, con logo, sameAs (solo cuentas sociales reales), dirección y contactPoint. Nunca lo dupliques 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 la inicio, con URLs correctas según la localidad (una página en francés debe apuntar a ancestros /fr/, no /en/).
• Article o BlogPosting, en contenido de formato largo, con arrays about y mentions para reforzar el gráfico de entidad.
• Service, en páginas comerciales, con serviceType, provider, areaServed, audience, y offers.priceSpecification cuando puedas publicar un rango de precio.
• 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. Fingir FAQs para ganar marcado de schema es el activador 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 de locale 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 desde coincidencia de patrón de URL, se rompe en casos especiales (una página en español que no tiene traducción al hindi rompe el cluster si tu código asume "si paginaX existe en locale A, existe en locale B").

Lo que mata hreflang en la práctica

Tres patrones que vemos repetidamente. Ordenamiento de regex de locale, poniendo "zh" antes de "zh-Hant" en tu regex de detección de locale, que captura el locale incorrecto y escribe un hreflang roto. Olvidar x-default, cada cluster necesita un fallback x-default, típicamente apuntando a la versión en inglés. Drift de cluster ID, una traducción recibe 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 genera miles de páginas desde 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 golpear la cola larga a una escala que el contenido de un solo autor no puede alcanzar. 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 en 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 control de calidad, las páginas con datos únicos insuficientes se mantienen fuera del sitemap, bloqueadas del índice o 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 playbook operativo a builds programáticos de clientes, front-end Next.js o Astro, datos en Supabase o Postgres, un pipeline de ingesta que califica páginas en unicidad antes de publicar, un sitemap que transmite en chunks porque más de 50,000 URLs no pueden caber en un único sitemap.xml, y un gráfico de links internos que trae cada hoja a 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 casi siempre es la imagen hero y casi siempre se resuelve re-codificando a WebP con 80% de calidad, dimensionando a las dimensiones de visualización real más 2x retina, agregando una etiqueta preload en el head, y estableciendo fetchpriority="high". Una imagen hero de 1 MB convirtiéndose en un WebP de 30 KB es el cambio con mayor impacto en la mayoría de proyectos. CLS viene de imágenes y ads sin dimensiones explícitas, atributos de width y height explícitos en cada imagen, slots de ad de altura fija, y espacio reservado para cualquier widget del lado del cliente. INP viene de JavaScript pesado en interacción, típicamente un tag manager de terceros o una librería de analytics 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 el JS corre, y tu LCP es el skeleton de carga del carousel, no la foto. Segundo, web fonts cargadas sin font-display: swap y sin preload, el texto es invisible durante 200-400 ms mientras las fonts descargan, y tu LCP se empuja pasado el umbral de 2.5 s aunque la imagen sea rápida. Ambos se capturan por una revisión de field-data de CrUX, no por 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 sociales falsas en sameAs, texto placeholder de prueba hardcodeado, 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 corre como el último paso de npm run build. Cualquier violación falla el build, lo que falla el deploy. Sin él, cada regresión, una meta description que creció más del límite, un campo SEO que alguien olvidó establecer, un emisor de schema que se rompió cuando una propiedad fue renombrada, se envía silenciosamente. Con él, la regresión se captura antes de que salga del 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, esquema de organización consistente, cuentas reales 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 de robots.txt y sitemap.xml que sirven a los rastreadores tradicionales.
• Esquema con about y mentions en contenido de formato largo, declara el gráfico de entidad dentro del cual se sitúa la página.
• Lista de permitidos de robots.txt para rastreadores de IA, permitir explícitamente GPTBot, PerplexityBot, ClaudeBot, OAI-SearchBot, Google-Extended, Applebot-Extended, CCBot y Anthropic-AI. Bloquear incluso uno de estos es una falta de citas autoinfligida.
• Propiedad de esquema speakable en las secciones ricas en respuestas de páginas de formato largo, una pista para extractores de voz e IA de que este es el pasaje citable.

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 OpenAI search. 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 rastreador de TikTok, generalmente bloqueado porque es agresivo y la mayoría de los proyectos no quieren que TikTok tome 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 coloca en lista blanca por IP y user-agent. Vercel WAF y Edge Middleware, asegúrate de que no coincidan con user agents de IA en una expresión regular genérica. Plugins de seguridad de WordPress como Wordfence, a menudo incluyen reglas que bloquean GPTBot y PerplexityBot por defecto; coloca en lista blanca explícitamente. Prueba haciendo curl a 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.

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.

Tres a diez semanas, tres fases, precio fijo. La fase uno es auditoría, rastreo completo, revisión de GSC y Ahrefs, validación JSON-LD, verificación de clúster hreflang, extracción de datos de campo 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, informe 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.
• Línea base de AI Overview y Perplexity citation, 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 inicial claro y un estado final claro. Los entregamos en orden de prioridad y puedes detener el compromiso en cualquier hito si se agota el presupuesto. El primer lote que entregamos siempre son los elementos que fallan el linter de compilación, tienen el camino más corto hacia el valor porque regresarán sin el linter, y una vez que el linter está en su lugar, cada corrección persiste.

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.