SEO técnico: guía completa y checklist para 2026

Puedes tener el mejor contenido de tu sector y un puñado de enlaces envidiables y aun así no aparecer. Si Google no llega a tus páginas, no las entiende o decide que no merece la pena guardarlas, todo lo demás da igual. Esa capa invisible —la que decide si tu web es siquiera candidata a posicionar— es el SEO técnico.

Esta guía recoge todo lo que revisamos en una auditoría técnica, en el mismo orden en que lo revisamos, con los errores que encontramos una y otra vez y cómo se corrigen. Sirve tanto si tu web está en WordPress como si está hecha a medida.

Qué es el SEO técnico (y qué no)

El SEO técnico es todo lo que hace que un buscador pueda encontrar, rastrear, entender e indexar tu web sin obstáculos. No se ocupa de qué dices ni de quién te enlaza: se ocupa de que nada impida que esas dos cosas cuenten.

La forma más útil de situarlo es como una pirámide de tres pisos:

1. Técnica. Que tus páginas sean accesibles, indexables y comprensibles. Es la base.
2. Contenido. Que respondan mejor que las demás a lo que la gente busca.
3. Autoridad. Que otros te avalen con enlaces y menciones.

El orden importa porque los pisos superiores no compensan los inferiores. Un artículo excelente en una URL con noindex vale cero. Un enlace desde un medio importante hacia una página que devuelve un 404 se evapora. En cambio, arreglar la base multiplica lo que ya tienes: es el tipo de trabajo cuyo resultado se ve en todas las páginas a la vez.

Conviene decir también qué no es. El SEO técnico no consiste en "meter palabras clave", ni en instalar un plugin y darlo por hecho, ni en perseguir el 100 en todas las métricas. Es un trabajo de fontanería: buscar dónde se pierde el agua y taparlo.

La cadena: descubrir, rastrear, indexar, servir

Casi cualquier problema de SEO técnico se puede colocar en uno de estos cuatro eslabones. Identificar cuál está roto ahorra semanas de trabajo mal dirigido:

Un ejemplo de por qué esto importa: si una página no aparece en Google, la reacción habitual es reescribir el contenido. Pero si el problema está en el eslabón "rastrear", puedes reescribirla diez veces sin que cambie nada. Primero se diagnostica el eslabón, después se actúa.

Rastreo: que Google pueda llegar

robots.txt

Es un archivo de texto en la raíz del dominio que le dice a los rastreadores por dónde no pasar. Simple, poderoso y peligroso: una línea mal puesta puede borrarte del mapa.

User-agent: *
Disallow: /wp-admin/
Disallow: /carrito/
Disallow: /*?orderby=
Allow: /wp-admin/admin-ajax.php

Sitemap: https://tudominio.com/sitemap.xml

Tres reglas que evitan la mayoría de los desastres:

• Nunca bloquees CSS ni JavaScript. Google necesita renderizar la página como la ve un usuario; si le escondes los estilos, puede interpretar que tu web no es apta para móviles.
• robots.txt no desindexa. Impide el rastreo, no la aparición en resultados. Volveremos sobre esto porque es el error número uno.
• Comprueba el de producción, no el de tu portátil. El Disallow: / que protegía el entorno de pruebas y se subió a producción por error es un clásico que sigue arruinando lanzamientos.

Presupuesto de rastreo

El crawl budget es la cantidad de recursos que Google dedica a rastrear tu sitio. Antes de preocuparte: si tu web tiene menos de unos pocos miles de URLs, esto no es tu problema. Google rastreará todo sin dificultad y el tiempo invertido aquí rinde más en otro sitio.

Empieza a importar en catálogos grandes, portales y ecommerce con filtros. Lo que lo malgasta casi siempre es lo mismo:

• Facetas y parámetros combinables, que generan millones de URLs equivalentes (?color=azul&talla=m&orden=precio).
• Paginaciones infinitas o calendarios que crean páginas hasta el año 2099.
• Cadenas de redirecciones, donde cada salto consume una visita del rastreador.
• Errores 5xx intermitentes, que hacen que Google reduzca el ritmo por prudencia.

Capacidad y demanda: las dos fuerzas que lo determinan

El presupuesto no es un número que Google te asigne por sorteo: sale de multiplicar dos cosas que puedes influir por separado.

• Capacidad de rastreo. Es cuánto está dispuesto a pedirte Googlebot sin hacerte daño. La calcula midiendo tus tiempos de respuesta y tus errores: si el servidor contesta rápido y estable, sube el número de conexiones en paralelo; si empieza a tardar más de un segundo o a devolver 5xx y timeouts, baja el ritmo inmediatamente para no tumbarte. Un hosting lento no solo te penaliza en Core Web Vitals: te reduce el rastreo.
• Demanda de rastreo. Es cuántas ganas tiene de volver. Depende de la popularidad de la URL (enlaces que recibe) y de su frescura (con qué frecuencia cambia de verdad). Una portada de noticias se rastrea cada pocos minutos; un aviso legal que no cambia desde 2019, un par de veces al año.

De ahí la conclusión práctica: acelerar el servidor y eliminar ruido sube el presupuesto disponible, y el enlazado interno decide en qué se gasta.

Cómo domar la navegación facetada

En un ecommerce, la mayor parte del desperdicio viene de los filtros. No hay una sola solución: cada tipo de parámetro pide un tratamiento distinto.

Un marco que ayuda a decidir en sitios grandes es clasificar cada plantilla de URL en una de cuatro categorías antes de tocar nada:

1. Indexable prioritaria: lo que genera ingresos o capta demanda. Debe rastrearse a menudo y estar enlazada desde arriba.
2. Indexable de apoyo: contenido que sostiene a la anterior sin ser el objetivo.
3. Rastreable pero no indexable: páginas por las que fluye el enlazado interno pero que no aportan nada en resultados. Llevan noindex y se dejan rastrear.
4. Bloqueada: ruido puro (facetas combinadas, búsquedas internas, sesiones). Disallow en robots.txt.

Si una plantilla no encaja en ninguna, normalmente es que no debería existir.

Análisis de logs: la única fuente que no estima

Las herramientas simulan; Search Console agrega y muestrea; los logs registran. El log de accesos del servidor (access.log en Apache o NGINX) anota cada petición con su hora exacta, la IP de origen, el user-agent, la URL pedida, el código de respuesta y los bytes servidos. Es el único sitio donde ves lo que Googlebot hizo de verdad, no lo que una herramienta cree que haría.

Es también, con diferencia, el diagnóstico más rentable en sitios grandes. Y desde que los buscadores de IA rastrean por su cuenta, ha dejado de ser una técnica de nicho: es la única forma de saber si ChatGPT, Claude o Perplexity pasan por tu web.

Lo habitual es trabajar con una ventana de 30 a 90 días —menos no da patrones fiables— con Screaming Frog Log File Analyser, un stack tipo Kibana o Splunk si ya lo tienes montado, o directamente desde la terminal.

Qué buscar, en cinco pasos

1. Aísla y verifica a los bots. Primero filtras el tráfico humano y te quedas con los user-agents de rastreadores. Luego —y esto se salta casi siempre— verificas que son quienes dicen ser: falsificar un user-agent es trivial, y una parte del tráfico que se presenta como Googlebot son scrapers. La comprobación es una consulta DNS inversa: la IP debe resolver a un dominio del buscador y ese dominio debe resolver de vuelta a la misma IP.

# URLs más rastreadas por Googlebot, ordenadas por número de visitas
grep "Googlebot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -50

# Verificación de que una IP es realmente de Google
host 66.249.66.1        # → crawl-66-249-66-1.googlebot.com
host crawl-66-249-66-1.googlebot.com   # → debe devolver 66.249.66.1

2. Mide el desperdicio. Agrupa las peticiones por patrón de URL y mira el reparto. El resultado suele ser incómodo: una parte enorme del rastreo se va en JavaScript antiguo, parámetros de filtros y redirecciones obsoletas, mientras los directorios que facturan reciben una visita al mes. Ese porcentaje es la métrica que justifica todo el trabajo de robots.txt y canónicas del apartado anterior.

3. Encuentra las páginas huérfanas. Cruza la lista de URLs que aparecen en los logs con las que descubre un rastreador siguiendo enlaces. Lo que está en los logs pero no en el rastreo es huérfano: existe, Google lo recuerda, pero ningún camino interno lleva hasta ahí. Después decides: si no aporta nada, se elimina con un 410; si tiene tráfico o enlaces externos, se reintegra enlazándolo desde donde corresponda, y recuperas autoridad que ya tenías.

4. Caza los fallos que no se ven en frío. Una auditoría simulada hace peticiones lentas y ordenadas que cualquier servidor aguanta. Los logs enseñan lo que pasa bajo carga real: 302 usadas donde debería haber 301, cadenas que se comen el margen de tolerancia del rastreador, 500 esporádicos a horas concretas y 429 que le están diciendo a Googlebot que deje de pedir. Un pico de 5xx a las 3 de la madrugada coincidiendo con el backup no se ve de ninguna otra forma.

5. Mira qué se llevan los bots de IA. Segmentar el rastreo por user-agent revela qué secciones prefiere cada uno. Es información accionable: si los rastreadores de IA vuelven una y otra vez a tu glosario, a tus tablas comparativas o a tu documentación, esa es la estructura que están usando para responder, y merece la pena replicarla en el resto del sitio.

La distinción importa a la hora de decidir: bloquear GPTBot limita el uso de tu contenido para entrenar, pero bloquear OAI-SearchBot te saca directamente de las respuestas de ChatGPT. No son la misma decisión.

Indexación: que Google quiera guardarla

noindex vs. robots.txt: el error más caro

Merece su propio apartado porque lo vemos constantemente y su lógica es contraintuitiva:

• Disallow en robots.txt dice: no visites esta página.
• <meta name="robots" content="noindex"> dice: visítala, pero no la guardes.

Si haces las dos cosas a la vez, ocurre la paradoja: Googlebot no visita la página, por tanto nunca lee el noindex, y la URL puede seguir apareciendo en resultados —sin descripción, con un título tomado de los enlaces que apuntan a ella—. Ese famoso "Indexada aunque bloqueada por robots.txt" de Search Console nace justo aquí.

El orden correcto para eliminar una página del índice:

1. Permite el rastreo.
2. Añade noindex en la página (o cabecera X-Robots-Tag si es un PDF u otro archivo).
3. Espera a que desaparezca del índice.
4. Solo entonces, si quieres ahorrar rastreo, bloquéala en robots.txt.

Qué significan de verdad los estados de Search Console

El informe de indexación es tu panel de control, pero sus etiquetas son crípticas. Traducción práctica:

Qué no debería estar indexado

Casi toda web arrastra páginas en el índice que solo diluyen. Revisa estos sospechosos:

• Resultados de búsqueda interna (/?s=...): generan infinitas páginas de baja calidad.
• Carritos, checkout y páginas de "gracias por tu compra".
• Entornos de pruebas y staging, sobre todo si son subdominios accesibles.
• Etiquetas y categorías vacías o casi vacías de WordPress, un clásico generador de duplicados.
• Versiones en PDF del mismo contenido que ya está en HTML.
• Páginas de agradecimiento de formularios, que si se indexan falsean tus conversiones.

Renderizado: qué ve Googlebot de verdad

Este es el bloque que más ha cambiado en la última década y el peor cubierto en la mayoría de guías, que siguen escritas asumiendo que toda web es HTML servido desde un CMS clásico.

Googlebot procesa las páginas en dos olas. Primero descarga el HTML y extrae lo que hay en él. Si el contenido depende de JavaScript, la página entra en una cola de renderizado donde espera a que haya recursos disponibles para ejecutarlo: puede tardar horas o semanas, y si los scripts tardan demasiado o fallan, esa segunda ola simplemente no llega. Todo lo que dependa de ella llega tarde y compite peor.

El detalle que casi nadie cuenta es que los rastreadores de IA son mucho menos pacientes que Google. Google al menos tiene una cola de renderizado; la mayoría de los bots de modelos de lenguaje leen el HTML que reciben y se van. Una web en renderizado de cliente puede acabar indexada en Google con retraso y ser, a la vez, completamente invisible para ChatGPT o Perplexity.

De ahí que la arquitectura de tu web tenga consecuencias directas:

Las tres primeras filas resuelven el problema; la cuarta lo resuelve además a baja latencia. La quinta, para contenido público, no es una opción defendible en 2026. El CSR puro tiene su sitio —una aplicación tras autenticación no necesita indexarse— pero no en las páginas que quieres posicionar.

El caso intermedio más útil es el incremental: páginas estáticas con una ventana de revalidación (60 segundos, 5 minutos, lo que pida el negocio). El bot recibe siempre HTML completo desde caché, el TTFB se mantiene en mínimos y la base de datos no se entera de que existe Googlebot. Para un catálogo con precios o stock que cambian, es el equilibrio más razonable.

Hay además tres patrones que Googlebot no resuelve nunca, hagas lo que hagas:

• Contenido que solo aparece tras interactuar. El bot no hace clic, no despliega acordeones cargados por JavaScript ni pulsa "ver más". Si el texto no está en el DOM tras la carga, no existe. (Un acordeón cuyo contenido sí está en el HTML y solo se oculta con CSS, en cambio, sí se indexa.)
• Enlaces que no son enlaces. Un <div onClick="..."> o un <button> que navega con JavaScript no transmite nada. Los enlaces internos deben ser <a href="/ruta/">, punto.
• Rutas con almohadilla (/#/productos), herencia de las primeras SPAs: para Google todo eso es la misma URL.

Cómo comprobarlo en dos minutos: usa la Inspección de URL de Search Console y mira la pestaña de HTML renderizado; si tu texto no aparece ahí, Google no lo tiene. Para una comprobación rápida, curl https://tudominio.com/pagina te devuelve el HTML crudo, sin JavaScript: es aproximadamente lo que ve la primera ola.

En nuestro caso, esto es una de las razones por las que trabajamos con generación estática: el contenido va en el HTML desde el primer byte, y no hay una segunda ola de la que depender. Lo comparamos en detalle en Next.js vs WordPress.

Arquitectura, URLs y enlazado interno

Profundidad de clic

Cuenta cuántos clics hacen falta para llegar desde la portada a cada página. Cuanto más profunda, menos autoridad recibe y menos se rastrea. La regla práctica —nada importante a más de tres clics— no es un dogma, pero sí un buen detector de problemas: si tu servicio estrella está a cinco clics, tu arquitectura está trabajando en tu contra.

Páginas huérfanas

Son las que no reciben ningún enlace interno. Existen, están en el sitemap quizá, pero ningún camino lleva a ellas. Google las considera irrelevantes por omisión: si tú no las enlazas, ¿por qué iban a importar? Se detectan cruzando la lista de URLs del sitemap con las que encuentra un rastreador siguiendo enlaces.

URLs que se entienden

Una URL es una promesa de contenido. Estas reglas cubren el 95% de los casos:

• Cortas y descriptivas: /servicios/posicionamiento-seo/ mejor que /index.php?p=42&cat=7.
• Guiones para separar palabras, nunca guiones bajos ni espacios codificados.
• Minúsculas siempre (en muchos servidores /Servicios y /servicios son URLs distintas: duplicado instantáneo).
• Sin fechas en los blogs si el contenido se actualiza: /blog/seo/guia/ envejece mejor que /2026/07/guia/.
• Estables: cambiar una URL que ya posiciona cuesta tráfico. Si no hay más remedio, redirección 301 y a vivir.

Enlazado interno

Es la palanca más infravalorada del SEO técnico y una de las pocas que controlas al 100%. Los enlaces internos hacen tres cosas: descubren páginas nuevas, reparten autoridad y le dicen a Google de qué trata el destino a través del texto ancla.

• Enlaza con texto descriptivo, no con "haz clic aquí". El ancla es una etiqueta temática.
• Enlaza desde el cuerpo del contenido, no solo desde menús y pies: los enlaces contextuales pesan más.
• Enlaza hacia lo que quieres posicionar, no solo hacia lo último publicado.
• Revisa que no apunten a URLs que redirigen: cada salto diluye y ralentiza.

Migas de pan

Las migas de pan resuelven a la vez navegación, contexto y presentación en resultados. Márcalas con BreadcrumbList y Google podrá mostrar la jerarquía en lugar de la URL desnuda.

Duplicados y canónicas

Las cuatro versiones de tu dominio

Toda web nace con cuatro direcciones potencialmente distintas:

http://tudominio.com
http://www.tudominio.com
https://tudominio.com
https://www.tudominio.com

Solo una debe responder con 200; las otras tres, redirigir con 301 hacia ella. Súmale la barra final (/pagina vs /pagina/): elige una convención y sé consistente. Son duplicados triviales de arreglar y sorprendentemente frecuentes.

La etiqueta canónica

<link rel="canonical" href="..."> le dice a Google cuál es la versión buena de un contenido que existe en varias URLs. Dos matices que casi nadie explica:

• Es una sugerencia, no una orden. Google puede ignorarla si las señales le dicen otra cosa (por ejemplo, si todos tus enlaces internos apuntan a la URL que declaraste como duplicada). Cuando eso pasa, lo verás en Search Console como "Google eligió otra canónica".
• Debe ser autorreferente. Cada página original debería declararse canónica de sí misma, con URL absoluta. Evita que parámetros de campaña (?utm_source=) generen duplicados accidentales.

Errores habituales: canónicas apuntando a la portada desde todas las páginas (destruye la indexación del sitio entero), canónicas hacia URLs que redirigen, y canónicas relativas que se resuelven mal.

Paginación

Desde que Google retiró el soporte de rel="next" y rel="prev", la recomendación es simple: cada página de la serie es autocanónica, todas indexables, y desde la página 2 en adelante no hace falta más. Lo que no debes hacer es canonicalizar todas hacia la página 1: escondes el contenido de las siguientes.

Canibalización

Ocurre cuando varias páginas tuyas compiten por la misma intención de búsqueda. El resultado es que ninguna consolida: Google alterna entre ellas y todas rinden por debajo.

Cómo detectarla: en el informe de rendimiento de Search Console, filtra por una consulta concreta y mira la pestaña de páginas. Si tres URLs se reparten impresiones para la misma búsqueda, tienes canibalización.

Cómo resolverla: casi nunca borrando. Elige la URL que debe ganar, fusiona en ella lo mejor del resto, redirige las demás con 301 y actualiza los enlaces internos para que todos apunten a la ganadora. Si las páginas responden a intenciones distintas y solo el enfoque se parecía, a veces basta con reescribir títulos y encabezados para separarlas.

Redirecciones y migraciones

Una redirección le dice al navegador y al buscador que el contenido se mudó. Elegir mal el tipo tiene consecuencias:

• 301 (permanente): el estándar para cambios definitivos. Transmite prácticamente toda la autoridad.
• 302 (temporal): solo para lo que de verdad es temporal. Usada por error en migraciones, hace que Google mantenga la URL antigua indexada durante meses.
• 307/308: equivalentes modernos de 302 y 301 que conservan el método HTTP. Relevantes con HSTS y formularios.
• Redirecciones por JavaScript: funcionan, pero se procesan tarde y mal. Evítalas si puedes hacerlas en servidor.

Dos patologías que hay que cazar en cualquier auditoría: las cadenas (A → B → C → D, donde cada salto pierde tiempo y algo de señal) y los bucles, que directamente hacen la página inaccesible.

Checklist mínima de migración

Las migraciones son el momento en que más tráfico se pierde de golpe, casi siempre por descuidos evitables:

1. Mapa 1:1 de URLs antiguas a nuevas, hecho antes de tocar nada, a partir de un rastreo completo del sitio actual.
2. Redirecciones 301 directas, sin escalones intermedios.
3. Mantén las redirecciones al menos un año, idealmente para siempre: hay enlaces externos que tardan en actualizarse o no lo harán nunca.
4. Actualiza los enlaces internos al destino final, en lugar de dejar que pasen por la redirección.
5. Sitemap nuevo enviado en Search Console el día del cambio.
6. Vigila 15 días: errores de rastreo, cobertura de indexación y las páginas que más tráfico traían.

Códigos de estado que importan

Cada respuesta del servidor es una señal. Estas son las que aparecen en una auditoría y su lectura en clave SEO:

Mención especial al soft 404: una página que devuelve 200 pero muestra "no hay resultados" o está prácticamente vacía. Google la detecta y la excluye igualmente, pero mientras tanto gasta rastreo en ella. Si algo no existe, dilo con el código correcto.

Sitemaps XML

Un sitemap es una lista de las URLs que quieres que Google conozca. No garantiza indexación, pero acelera el descubrimiento, y en sitios grandes o con poco enlazado externo es determinante.

Reglas de un sitemap sano:

• Solo URLs indexables, canónicas y que devuelvan 200. Nada de noindex, redirecciones ni 404: un sitemap sucio resta credibilidad.
• lastmod honesto. Actualizar la fecha de todo el sitio cada noche sin cambiar nada enseña a Google a ignorar el campo.
• Máximo 50.000 URLs o 50 MB por archivo; por encima, se parte en varios con un índice de sitemaps.
• Segmentado por tipo (páginas, entradas, productos) en sitios grandes: así el informe de Search Console te dice qué sección tiene problemas.
• Declarado en robots.txt y enviado en Search Console y Bing Webmaster Tools.

Si trabajas con Next.js, el sitemap se genera en el propio build y nunca se queda obsoleto:

// src/app/sitemap.ts
import type { MetadataRoute } from 'next';

export default function sitemap(): MetadataRoute.Sitemap {
    return getAllPosts().map((post) => ({
        url: `https://tudominio.com/blog/${post.slug}/`,
        lastModified: post.updatedAt,
        changeFrequency: 'monthly',
        priority: 0.7,
    }));
}

Datos estructurados

Los datos estructurados son un vocabulario estándar (Schema.org) que traduce tu contenido a algo que una máquina entiende sin interpretar: esto es una empresa, esto un artículo, esto un precio.

No suben posiciones por sí solos —Google lo ha repetido— pero cambian cómo apareces y ayudan a que los buscadores entiendan qué entidad eres. Con la llegada de las respuestas generadas por IA, ese segundo efecto ha ganado peso: un contenido bien marcado es más fácil de citar.

Los tipos que rinden en la mayoría de webs:

• Organization en la portada: nombre, logo, perfiles sociales, datos de contacto. Es la base de tu identidad como entidad.
• BreadcrumbList en todas las páginas internas.
• Article en el blog, con autor y fechas de publicación y modificación.
• Service o Product según lo que vendas.
• FAQPage cuando haya preguntas reales en la página. Google recortó mucho su visualización en resultados, pero sigue siendo útil para comprensión y para los asistentes de IA.
• Person para las fichas de equipo, que conectan autores con contenido.

Dos errores que penalizan de verdad: marcar contenido que no está visible en la página (es motivo de acción manual) y inventar valoraciones o datos. El marcado describe lo que hay; no lo sustituye.

Valida siempre con la prueba de resultados enriquecidos de Google y con el validador de Schema.org, que cubre más tipos.

Tu web como entidad: sameAs y knowsAbout

Aquí es donde el marcado ha cambiado de función. Un modelo de lenguaje que tiene que citar un dato concreto —un precio, una dirección, una metodología— compara varias fuentes que dicen lo mismo y se queda con la que se lo pone fácil: la que declara sin ambigüedad qué es cada cosa. El JSON-LD ha pasado de decorar el resultado a ser la vía por la que una máquina te identifica.

Eso convierte dos propiedades poco usadas en las más rentables del vocabulario:

• sameAs conecta tu entidad con sus perfiles verificados en otros sitios: LinkedIn, X, Instagram, GitHub, Crunchbase, la ficha de Wikidata si la tienes. Es lo que le dice a un modelo que la empresa de tu web y la de esos perfiles son la misma, y consolida en un solo sitio señales que están repartidas por media internet.
• knowsAbout declara de qué sabe una persona. Lo interesante es que admite URIs además de texto: en lugar de escribir "SEO" puedes apuntar a la ficha de Wikidata de ese concepto (Q180711), y ahí desaparece cualquier ambigüedad sobre a qué te refieres. Es la forma más directa de traducir a código lo que Google llama experiencia y conocimiento.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://tudominio.com/#organization",
  "name": "Tu Empresa",
  "url": "https://tudominio.com/",
  "logo": "https://tudominio.com/logo.png",
  "vatID": "ESB12345678",
  "sameAs": [
    "https://www.linkedin.com/company/tuempresa/",
    "https://github.com/tuempresa",
    "https://www.wikidata.org/wiki/Q00000000"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer service",
    "email": "hola@tudominio.com",
    "availableLanguage": ["es", "en"]
  },
  "founder": {
    "@type": "Person",
    "@id": "https://tudominio.com/equipo/#persona",
    "name": "Nombre Apellido",
    "jobTitle": "Directora técnica",
    "knowsAbout": [
      "https://www.wikidata.org/wiki/Q180711",
      "https://www.wikidata.org/wiki/Q845921",
      "SEO técnico"
    ],
    "sameAs": ["https://www.linkedin.com/in/perfil/"]
  }
}

Tres reglas para que esto funcione de verdad:

• Un @id estable por entidad, y el resto del marcado referenciándolo. Sin identificadores, cada página declara una empresa nueva.
• Enlaza Article con su Person autora, y esa Person con una ficha real en tu web. Un autor que solo existe como cadena de texto en el JSON-LD no acredita nada.
• Coherencia absoluta en nombre, dirección y teléfono entre la web, el marcado y los perfiles externos. Una discrepancia rompe la resolución de entidad y no la ves en ningún informe.

FAQPage: pocas preguntas y respuestas cortas

El marcado de preguntas frecuentes es de los más útiles para que un asistente extraiga una respuesta literal, y también de los más abusados. Inyectar treinta preguntas artificiales que no están en la página es exactamente el patrón que los buscadores han aprendido a ignorar —y a penalizar cuando el marcado no se corresponde con el contenido visible.

Lo que funciona:

• De seis a diez preguntas, tomadas de lo que te preguntan los clientes de verdad, no de un listado de keywords.
• Redactadas como las diría una persona a un chatbot, en lenguaje natural y completo.
• Respuestas de dos a cuatro frases, con el dato concreto en la primera. Sin florituras comerciales: si la respuesta empieza con "en nuestra dilatada experiencia", no la va a citar nadie.
• Idénticas al texto visible de la página. El marcado documenta; no añade.

Internacionalización: hreflang sin dolor

Si tu web existe en varios idiomas o para varios países, hreflang le dice a Google qué versión mostrar a cada usuario. Bien hecho evita que tu versión inglesa canibalice a la española; mal hecho no hace nada o mezcla las dos.

<link rel="alternate" hreflang="es-ES" href="https://tudominio.com/servicios/" />
<link rel="alternate" hreflang="en" href="https://tudominio.com/en/services/" />
<link rel="alternate" hreflang="x-default" href="https://tudominio.com/servicios/" />

Las reglas que evitan el 90% de los fallos:

• Bidireccionalidad. Si A declara a B como alternativa, B debe declarar a A. Sin reciprocidad, Google ignora todo el bloque.
• Autorreferencia. Cada página se incluye a sí misma en su lista.
• Códigos correctos. Idioma en ISO 639-1 y país opcional en ISO 3166-1 alfa-2, separados por guion: es-ES, es-MX, en-GB. Ni es_ES ni es-ESP.
• URLs absolutas y sin redirecciones ni noindex en el destino.
• x-default para quien no encaje en ninguna versión.
• Traduce de verdad. Dos páginas idénticas con hreflang distinto siguen siendo duplicados.

Rendimiento y Core Web Vitals

La velocidad es parte del SEO técnico, pero merece su propio manual: qué mide exactamente cada métrica, cómo diagnosticarla y qué optimizaciones tienen impacto real. Lo desarrollamos en Core Web Vitals 2026: guía práctica.

El resumen para esta guía: LCP por debajo de 2,5 s, INP por debajo de 200 ms y CLS por debajo de 0,1, medidos sobre usuarios reales en el percentil 75 y con una ventana de 28 días. Pesan menos que el contenido, pero funcionan como desempate y afectan mucho a la conversión.

Imágenes: formato, peso y comprensión

Las imágenes son casi siempre el elemento más pesado de una página y, a la vez, el más fácil de optimizar. En la mayoría de webs que auditamos son la causa número uno de un LCP suspendido y una fuente constante de saltos de diseño. Merecen su propio apartado porque tocan tres cosas a la vez: velocidad, indexación y accesibilidad.

Formato: WebP y AVIF

Servir JPEG y PNG en 2026 es dejar entre un 25% y un 50% del peso sobre la mesa:

• WebP es hoy la opción por defecto: soporte universal en navegadores desde hace años, transparencia como PNG y compresión mucho mejor. Una foto que pesa 400 KB en JPEG suele quedarse en 150-250 KB en WebP con la misma calidad percibida.
• AVIF comprime todavía más (otro 20-30% sobre WebP) a costa de más tiempo de codificación. Vale la pena en catálogos con muchas imágenes.
• SVG para logotipos, iconos y diagramas: es vectorial, pesa poco y escala sin perder nitidez.
• PNG solo cuando necesites transparencia sin pérdida y WebP no encaje; JPEG, únicamente como respaldo.

La conversión no tiene por qué ser manual. Con cwebp conviertes y redimensionas en un comando, y es trivial automatizarlo por lotes:

cwebp foto.jpg -resize 1080 0 -q 84 -m 6 -o foto-1080w.webp

En un CMS, un plugin de optimización hace lo mismo al subir. Y en frameworks modernos como Next.js, el componente de imagen convierte y sirve el formato adecuado según el navegador sin que toques nada.

Peso y dimensiones reales

El error más caro no es el formato: es servir una imagen de 3.000 px en un hueco de 600. El navegador la descarga entera y luego la reduce, así que pagas todo el peso para no ver ninguna de esas ventajas.

• Genera varios tamaños de cada imagen y deja que el navegador elija con srcset y sizes.
• Ajusta la calidad al 80-85%: por encima, el peso sube mucho y la diferencia visual es imperceptible.
• Fija width y height (o aspect-ratio) en todas las imágenes: es lo que reserva el hueco y evita los saltos de CLS.
• Aplica loading="lazy" a las imágenes que quedan bajo el pliegue, y nunca a la del LCP.

<img src="/imagenes/servicio-828w.webp"
     srcset="/imagenes/servicio-640w.webp 640w,
             /imagenes/servicio-828w.webp 828w,
             /imagenes/servicio-1080w.webp 1080w"
     sizes="(max-width: 768px) 100vw, 50vw"
     width="1080" height="720" loading="lazy"
     alt="Equipo revisando una auditoría SEO en pantalla" />

Que además se entiendan

Optimizar el peso resuelve la velocidad; falta que el buscador sepa qué hay en la imagen:

• Nombre de archivo descriptivo: auditoria-seo-tecnico.webp, no IMG_20260726_final2.webp.
• Atributo alt informativo en toda imagen que aporte contenido, describiendo lo que se ve, no repitiendo la keyword. Las decorativas llevan alt="" para que los lectores de pantalla las ignoren.
• Contexto alrededor: el texto cercano y el pie de foto ayudan a Google a interpretar la imagen.
• Sitemap de imágenes si el buscador visual es un canal para ti (moda, decoración, turismo, recetas).

Es de las pocas optimizaciones que mejoran a la vez Core Web Vitals, accesibilidad, consumo de datos del visitante y visibilidad en Google Imágenes.

Móvil, HTTPS y accesibilidad

Indexación mobile-first. Google indexa la versión móvil de tu web, no la de escritorio. Si escondes contenido en móvil "para simplificar", ese contenido no cuenta. Comprueba que el texto, los enlaces y los datos estructurados son los mismos en ambas versiones.

HTTPS bien terminado. Certificado válido y renovado, redirección desde HTTP, sin contenido mixto (recursos cargados por HTTP dentro de una página HTTPS) y, si puedes, HSTS con TLS 1.3. Es requisito de entrada, no una ventaja.

Entrega eficiente. Comprueba que el servidor sirve HTML, CSS y JavaScript comprimidos con Brotli (o al menos gzip) y con cabeceras de caché razonables. Es una casilla de configuración que suele estar sin marcar y que mejora a la vez el LCP y la capacidad de rastreo, porque cada petición del bot cuesta menos.

Accesibilidad. No es un factor de ranking directo, pero se solapa tanto con el SEO técnico que conviene tratarlos juntos: un alt descriptivo en cada imagen informativa, una jerarquía de encabezados coherente (un solo <h1>, sin saltos de <h2> a <h4>), contraste suficiente y navegación posible con teclado. Lo que ayuda a un lector de pantalla ayuda a un rastreador: ambos leen estructura, no diseño.

SEO técnico para buscadores de IA

Cada vez más búsquedas terminan en una respuesta generada en lugar de en una lista de enlaces. Los estudios del sector publicados a lo largo de 2025 apuntan en la misma dirección: los resúmenes de IA aparecen ya en la mayoría de las búsquedas informativas —y en sectores como salud o finanzas se han medido porcentajes por encima del 80%—, con caídas de clics que en consultas puramente informativas llegan a ser de dos dígitos altos.

La lectura útil no es "se acabó el tráfico", sino que cambió el intermediario. La misma consulta que antes terminaba en un clic ahora termina en una respuesta que cita fuentes, y estar entre esas fuentes es una cuestión mayoritariamente técnica: si un modelo no puede leer tu HTML, identificar quién eres y extraer un dato sin ambigüedad, no te cita. A esa disciplina se la llama GEO (Generative Engine Optimization), y descansa sobre tres cosas que ya has visto en esta guía.

• Contenido en el HTML inicial. Es el requisito de entrada. Los bots de IA no esperan a una segunda ola de renderizado.
• Identidad declarada. Organization, Person, sameAs, @id estables. Es lo que permite a un modelo saber que la fuente eres tú y no un agregador que te copió.
• Respuestas extraíbles. Encabezados en forma de pregunta, el dato en la primera o segunda frase del párrafo, cifras concretas, tablas. Un párrafo que se explica solo se puede citar; uno que necesita los tres anteriores, no.

A eso se suma la parte de control de acceso, que ahora es una decisión de negocio y no solo técnica:

• Decide conscientemente a quién dejas pasar en robots.txt, distinguiendo entre los bots de entrenamiento y los de búsqueda: bloquear GPTBot o Google-Extended limita el uso de tu contenido para entrenar modelos; bloquear OAI-SearchBot o PerplexityBot te borra de sus respuestas. Revisa también el firewall del CDN, que a veces los bloquea sin que nadie lo haya decidido.
• Publica un llms.txt con un mapa legible de tu web para modelos de lenguaje.
• Comprueba en los logs si realmente están pasando y por dónde. Es la única verificación que existe.

Lo desarrollamos con más detalle en SEO para IA: cómo aparecer en ChatGPT y Perplexity.

Tres casos que enseñan lo que se juega aquí

El SEO técnico se explica mal en abstracto y muy bien con cifras. Estos tres casos públicos cubren los tres fallos más caros que existen: una migración sin redirecciones, un sitio ahogado en páginas inútiles y un ecommerce bloqueándose a sí mismo.

Una migración sin mapa de redirecciones. El portal inmobiliario ChatVal rehízo su marca en 2024 y desplegó la nueva estructura de URLs sin implantar las redirecciones 301. Alrededor de 324.000 páginas —un tercio del catálogo— empezaron a devolver 404, y con ellas se evaporó la autoridad de años de enlaces entrantes. Tras reconstruir el mapa de redirecciones con reglas por expresión regular, las sesiones orgánicas semanales pasaron de 974 a más de 12.000 en tres semanas (caso completo). Ningún plan de contenidos habría arreglado eso.

Demasiadas páginas, ninguna importante. El portal turístico oficial de Seattle acumulaba más de 58.000 errores técnicos y casi 6.000 páginas de contenido pobre, con duplicidades por parámetros y canibalización severa. La intervención no consistió en publicar más: se podó cerca del 70% de las páginas y se arreglaron las cadenas de redirecciones. El resultado fue recuperar y superar los niveles de tráfico previos (caso completo). Densidad por encima de volumen.

Un ecommerce bloqueándose a sí mismo. Tras migrar su tienda, Quality Woven Labels perdió un 33% de sesiones. La auditoría encontró cuatro cosas de manual: un robots.txt heredado por copia y pega que impedía rastrear categorías comerciales, miles de URLs sin canónica, perfiles de usuario indexándose por falta de noindex y un sitemap lleno de URLs rotas. Corregido todo eso, sin añadir una línea de contenido nuevo, los ingresos orgánicos subieron un 118% (caso completo).

El patrón se repite: en los tres, el trabajo consistió en quitar obstáculos, no en producir. Es la característica que hace del SEO técnico la inversión de mayor retorno cuando hay algo roto, y también la que explica por qué no se nota cuando está bien hecho. En nuestro propio caso, el crecimiento que mostramos en la página de posicionamiento SEO viene de ese mismo orden de trabajo.

Cómo hacer una auditoría técnica

Las herramientas

Search Console y un rastreador cubren la práctica totalidad de un diagnóstico. Las suites de pago aportan seguimiento en el tiempo y comparación con la competencia.

Sobre los rastreadores conviene detenerse, porque es la herramienta que más vas a usar. Screaming Frog es el estándar del sector, pero su versión gratuita se corta en 500 URLs, lo que en un sitio mediano se agota en el primer rastreo. LibreCrawl es una alternativa de código abierto con licencia MIT que no impone ese límite: rastrea sin tope de URLs, integra Playwright para renderizar JavaScript —imprescindible si auditas una SPA hecha con React, Vue o Next.js— y analiza metadatos, hreflang, datos estructurados y etiquetas sociales. Al poder alojarlo tú mismo, los datos del rastreo no salen de tu máquina, que en proyectos de cliente no es un detalle menor.

El proceso, en seis pasos

1. Rastrea el sitio completo con Screaming Frog o LibreCrawl y exporta todo: códigos de estado, títulos, canónicas, profundidad, enlaces entrantes internos.
2. Cruza con Search Console: qué URLs conoce Google, cuáles indexó y cuáles descartó, y con qué motivo.
3. Comprueba el renderizado de una plantilla de cada tipo (portada, categoría, ficha, artículo) con la inspección de URL.
4. Revisa los logs de los últimos 30-90 días: dónde gasta Googlebot su tiempo, qué páginas huérfanas aparecen y qué bots de IA están entrando.
5. Clasifica los hallazgos por eslabón roto (descubrir, rastrear, indexar, servir), no por herramienta.
6. Prioriza por impacto y esfuerzo, y arregla en ese orden.

Prioriza bien

No todos los hallazgos valen lo mismo. Este orden funciona en la inmensa mayoría de los casos:

1. Bloqueantes: noindex accidentales, Disallow en producción, errores 5xx, cadenas de redirecciones en páginas clave. Se arreglan hoy.
2. Estructurales: duplicados, canibalización, arquitectura y enlazado interno. Semanas de trabajo, el mayor retorno.
3. De refinamiento: datos estructurados, optimización de imágenes, detalles de rendimiento. Continuo.

La trampa habitual es empezar por el punto 3 porque es el más cómodo de medir, mientras un noindex olvidado mantiene media web fuera del índice.

Checklist de SEO técnico

El resumen accionable. Si solo te llevas una cosa del artículo, que sea esto:

Rastreo

• robots.txt revisado en producción, sin bloquear CSS ni JS
• Sitemap declarado en robots.txt y enviado en Search Console
• Sin errores 5xx recurrentes en el informe de estadísticas de rastreo
• Tiempo de respuesta medio del servidor por debajo del segundo
• Parámetros y facetas bajo control en sitios grandes
• Cada plantilla de URL clasificada: indexable, noindex o bloqueada
• Logs revisados: en qué gasta Googlebot el rastreo y qué bots de IA pasan

Indexación

• Ninguna página importante con noindex
• Nada bloqueado en robots.txt que además lleve noindex
• Páginas técnicas (carrito, búsqueda interna, gracias) fuera del índice
• Entorno de staging inaccesible o desindexado
• Informe de indexación revisado mensualmente

Renderizado

• El contenido clave aparece en el HTML renderizado de la inspección de URL
• El contenido clave aparece también en el HTML crudo (curl), no solo tras renderizar
• Todos los enlaces internos son <a href> reales
• Nada esencial oculto tras una interacción del usuario

Arquitectura

• Nada importante a más de tres clics de la portada
• Sin páginas huérfanas (cruzando logs y rastreo, no solo el sitemap)
• URLs cortas, en minúsculas, con guiones y estables
• Enlazado interno contextual con anclas descriptivas
• Migas de pan implementadas y marcadas

Duplicados y redirecciones

• Una sola versión del dominio responde 200; el resto redirige con 301
• Criterio único con la barra final
• Canónicas autorreferentes y absolutas
• Sin cadenas ni bucles de redirección
• Sin canibalización en las consultas prioritarias

Imágenes

• Servidas en WebP o AVIF, no en JPEG/PNG
• Varios tamaños con srcset y sizes, sin servir imágenes sobredimensionadas
• width y height declarados en todas
• loading="lazy" salvo en la imagen del LCP
• Nombres de archivo descriptivos y alt informativo

Comprensión y experiencia

• Organization, Article y BreadcrumbList implementados y validados
• @id estables por entidad y sameAs hacia tus perfiles verificados
• Artículos vinculados a una Person autora con ficha real en la web
• FAQPage con preguntas reales, respuestas cortas y coincidentes con el texto visible
• hreflang recíproco, autorreferente y con x-default si hay varios idiomas
• Core Web Vitals en verde sobre datos de campo
• Misma versión de contenido en móvil y escritorio
• HTTPS sin contenido mixto
• Decisión consciente sobre los rastreadores de IA, separando entrenamiento de búsqueda

Cómo lo trabajamos en yuGraphik

Nuestro punto de partida es que el SEO técnico se hereda de la arquitectura: es mucho más barato construir una web que nace indexable que arreglar una que no lo es. Por eso trabajamos con generación estática, HTML completo desde el primer byte, datos estructurados en plantilla y sitemap generado en cada build, todo servido desde CDN.

Cuando entramos en un proyecto existente, el orden es el de esta guía: rastreo completo, cruce con Search Console, verificación de renderizado y una lista priorizada por impacto, no por facilidad. Puedes ver el enfoque completo en nuestro servicio de posicionamiento SEO, y si quieres una primera lectura sin compromiso, tienes nuestro informe SEO gratuito.

Conclusión

El SEO técnico no es la parte glamurosa del posicionamiento, pero sí la que decide si el resto de tu trabajo llega a contar. La buena noticia es que es finito y verificable: a diferencia del contenido o los enlaces, aquí hay una lista cerrada de cosas que revisar y cada una tiene un estado objetivo, correcto o incorrecto.

Empieza por el diagnóstico, no por la solución: identifica qué eslabón de la cadena está roto antes de tocar nada. Arregla primero lo que bloquea, después lo que estructura y por último lo que refina. Y recuerda que en esta capa una sola línea mal puesta puede costar más tráfico que meses de contenido: por eso merece la pena revisarla con método y volver a hacerlo cada cierto tiempo.