SEO técnico: qué es y en qué orden hacerlo

Casi todas las auditorías técnicas se leen igual: doscientos avisos ordenados por severidad, ninguno por retorno. El orden importa más que la lista, porque las capas dependen unas de otras y arreglar la sexta antes que la primera no cambia nada. Este es el orden, con lo que cuesta cada capa y en qué punto deja de compensar.

¿Qué es el SEO técnico y en qué orden se hace?

Es el trabajo que permite que un buscador rastree, indexe y entienda un sitio. Se hace en seis capas y en orden: rastreo, indexación, arquitectura, enlazado, rendimiento y datos estructurados. En un sitio nuevo las dos primeras resuelven casi todo; en uno de autoridad media manda el enlazado; en uno consolidado solo quedan márgenes.

Respuesta rápida

• El orden es rastreo, indexación, arquitectura, enlazado, rendimiento y datos estructurados.
• Se sube por las capas, nunca se baja. Optimizar lo que está bloqueado no cambia nada.
• En un sitio nuevo mandan las dos primeras; en uno con años, el enlazado.
• La severidad de un informe no es el retorno, porque la herramienta no ve tu tráfico.

El problema del informe ordenado por severidad

Una herramienta de auditoría no sabe qué sitio tienes. Marca en rojo lo que su modelo considera grave, y ese modelo es el mismo para una tienda de cincuenta mil URLs y para un sitio de veinte páginas.

El resultado es un documento donde una imagen sin atributo alt aparece al lado de un noindex heredado de un entorno de pruebas, y los dos parecen tareas. Uno cuesta cinco minutos y no cambia nada. El otro está borrando el sitio del índice mientras se lee el informe.

La severidad no es el retorno. Un aviso grave en una página que nadie visita rinde menos que un aviso menor en la plantilla que usan las trescientas páginas que sí reciben tráfico, y ninguna herramienta sabe cuál es cuál porque ninguna tiene tus datos de tráfico delante mientras rastrea.

Las seis capas y por qué el orden no se negocia

El SEO técnico no es una lista de comprobaciones sino una secuencia con dependencias. El recorrido que hace un buscador es siempre el mismo: encuentra la URL, la descarga, la interpreta, decide si la guarda, la relaciona con el resto del sitio y la muestra de una forma concreta.

Cada capa depende de que la anterior funcione. Una página que no se rastrea no se indexa; una que no se indexa no compite por nada; una que compite pero está mal enlazada compite sola contra el resto del sitio.

Esa dependencia explica una asimetría que conviene tener presente al repartir horas: los fallos de las capas bajas son binarios y los de las altas son graduales. Un bloqueo de rastreo no reduce el rendimiento de una página, lo anula. Un LCP mediocre resta un margen. Por eso las dos primeras capas se revisan enteras y las dos últimas se revisan donde haya algo que ganar.

De ahí sale el criterio que ordena todo el trabajo: se sube por las capas, nunca se baja. Optimizar el rendimiento de una página bloqueada en robots.txt es trabajo perfectamente medible y perfectamente inútil, y es el error que más veces se ve en informes hechos por herramienta.

Las columnas de escenario no son decorativas: la misma capa cambia de prioridad según el punto de partida, y ese es el dato que ningún informe automático incorpora.

Las seis capas, una a una

1. Rastreo, antes que nada

Google publica tres requisitos técnicos mínimos para que una página pueda aparecer: que Googlebot no esté bloqueado, que la página responda con un código HTTP 200 y que tenga contenido indexable en un formato admitido. Los tres son previos a cualquier otra conversación.

Lo que se revisa aquí es qué está bloqueando el robots.txt, que es un archivo pequeño con consecuencias grandes y cuyo funcionamiento real está en robots.txt. Después, qué URLs se están declarando, que es lo que hace el sitemap XML. Y por último qué devuelve el servidor de verdad, porque una página que responde con error no entra, y el tratamiento correcto de los que aparecen está en errores 404.

Un detalle que la documentación aclara y casi nadie aplica bien: bloquear en robots.txt impide el rastreo pero la URL puede seguir apareciendo en los resultados. Para que no se indexe hay que usar noindex, y son cosas distintas que se confunden constantemente.

2. Indexación: contar antes de opinar

La pregunta es cuántas páginas se publican y cuántas están indexadas. Si el segundo número es mucho menor, ahí está el problema y no en ninguna de las capas siguientes.

La comprobación no admite herramientas de terceros: se hace en el informe de páginas de Google Search Console, que dice el motivo de cada exclusión. Cuando el motivo no se entiende, el recorrido de diagnóstico está en por qué Google no indexa mi página.

Aquí viven además las dos causas más frecuentes de exclusión silenciosa: páginas que Google consolida por considerarlas equivalentes y declaraciones canónicas que apuntan a donde no deben, las dos tratadas en contenido duplicado.

Y la advertencia que la propia documentación incluye: cumplir los tres requisitos no garantiza la indexación. No hay derecho de entrada.

Esa frase cambia cómo se lee todo el informe. Un sitio nuevo con quinientas páginas correctas puede tener ciento cincuenta indexadas y no haber hecho nada mal: Google decide qué guarda, y en la práctica guarda menos de lo que se le ofrece cuando no tiene motivos para creer que el resto aporta algo. La respuesta a eso no es técnica sino editorial, y es retirar lo que sobra en lugar de insistir en que entre.

3. Arquitectura: un solo eje por taxonomía

Es la capa donde una decisión temprana ahorra o cuesta un año de trabajo, y por eso es la que más conviene tomar despacio.

El fallo característico es mezclar ejes en la misma taxonomía, por ejemplo categorías que combinan tipo de producto con ocasión de uso. Produce solapamiento, páginas casi idénticas y una limpieza que se pospone hasta que ya hay cientos de URLs. El caso desarrollado, con lo que costó arreglarlo, está en categorías y arquitectura.

Cuando la estructura ya está mal y hay que cambiarla, deja de ser una decisión de arquitectura y pasa a ser una migración, con su propio procedimiento y sus propias formas de salir mal, descritas en migrar una web sin perder posicionamiento.

4. Enlazado interno: donde suele estar el retorno

Es la capa con mejor relación entre esfuerzo y resultado en sitios que ya tienen contenido, y la que menos aparece en los informes automáticos porque no genera errores.

Lo que se mira son dos cosas: qué páginas no reciben ningún enlace interno, que son invisibles para la distribución de fuerza dentro del sitio, y qué proporción de los enlaces vive en plantillas repetidas en lugar de dentro del texto. El criterio completo, incluido qué texto usar en cada enlace, está en enlazado interno.

En un sitio nuevo esta capa importa poco, porque hay poca autoridad que repartir. En uno con años de contenido es habitualmente la que más mueve, y con diferencia. La comprobación que más rápido lo demuestra es contar cuántos enlaces internos apuntan a las diez páginas que más ingresos producen: en la mayoría de los sitios auditados esa cifra es cero o uno, mientras las páginas de aviso legal reciben uno desde cada plantilla.

5. Rendimiento: importa en el margen

Las tres métricas de experiencia de carga son umbrales, no escalas continuas de premio: por debajo del umbral no hay recompensa adicional. Qué mide cada una y cómo se leen los dos tipos de dato está en Core Web Vitals.

Cuando hay que actuar, cada métrica tiene su propio diagnóstico y no se parecen: el reparto en cuatro tramos de cómo mejorar el LCP, la mecánica de ráfagas de cómo arreglar el CLS y las tres fases de qué es INP. Si el contenido depende de JavaScript para existir, la capa previa es otra y está en JavaScript y SEO.

6. Datos estructurados: presentación, no posición

La documentación de Google no los presenta como factor de posicionamiento sino como el requisito para optar a resultados enriquecidos. Cambian cómo se ve el resultado, no dónde aparece, y esa distinción decide cuánto esfuerzo merecen: qué son y qué efecto tienen está en datos estructurados, y el recorrido operativo, en cómo implementar schema markup.

Cuándo esto NO es lo que toca

Cuando el sitio tiene veinte páginas y todas están indexadas. Ahí la capa técnica ya funciona y el trabajo está en el contenido.

Cuando el problema es que nadie busca lo que vendes. Ninguna capa técnica crea demanda.

Cuando la caída coincide con una actualización del algoritmo. Es otro diagnóstico y otro procedimiento.

Cuando se va a rehacer el sitio en tres meses. Optimizar lo que se va a tirar es gasto puro.

Las variables que cambian el resultado

El tamaño del sitio. Por debajo de unos cientos de URLs, el presupuesto de rastreo no es un problema real y buena parte de la literatura técnica no aplica. Por encima de decenas de miles, es la primera capa y condiciona todo lo demás.

La antigüedad. Un dominio nuevo tiene poca fuerza que repartir, así que la capa de enlazado rinde poco al principio y mucho a los dos años.

Quién controla el servidor. Si el tiempo hasta el primer byte es el problema y no hay acceso a la infraestructura, la conversación es con quien aloja el sitio y no con quien escribe el HTML.

Y qué genera las páginas. Un sitio estático y uno con contenido inyectado por JavaScript no fallan por lo mismo, y el segundo tiene una capa entera adicional entre el rastreo y la indexación.

Hay una quinta variable que no es del sitio sino de quien lo opera: si existe alguien que pueda desplegar un cambio esta semana. Una recomendación técnica correcta que tarda cuatro meses en aplicarse rinde menos que una peor que se aplica el viernes, y ese cálculo casi nunca aparece en las auditorías porque quien las escribe no suele ser quien las ejecuta.

Un punto que sigue en todas las listas y dejó de existir en 2024

Las checklists de auditoría técnica que ocupan esta consulta traen entre treinta y cuarenta puntos, y casi todas incluyen el mismo: comprobar que hay paridad de contenido y de enlaces entre la versión de escritorio y la móvil.

Ese punto ya no describe nada. El 5 de julio de 2024 Google terminó el paso a indexación mobile-first para todos los sitios y dejó de rastrear con el robot de escritorio, salvo una lista muy pequeña de sitios que no funcionan en móvil y que revisa unas pocas veces al año. Comprobado el 13 de agosto de 2026.

La diferencia no es de nomenclatura. Ya no hay dos versiones que comparar: lo que no está en la versión móvil no existe. El chequeo deja de ser "compara las dos" y pasa a ser "abre la móvil y mira si está todo", que es una tarea distinta y bastante más incómoda, porque lo que se suele esconder ahí son los enlaces del menú y bloques enteros de texto plegados que el robot sí ve pero que el diseño responsive a veces no renderiza.

Y el punto más general, que es el que hace que estas listas envejezcan sin avisar: una checklist de cuarenta puntos no tiene forma de decir cuáles caducaron. Todos ocupan una línea, todos parecen igual de vigentes, y el que dejó de aplicar hace dos años se sigue marcando cada trimestre porque marcarlo es más rápido que comprobar si todavía significa algo.

Errores que se repiten

• Ordenar la auditoría por severidad. La severidad no es el retorno.
• Optimizar el rendimiento de páginas bloqueadas. La capa anterior no funciona.
• Confundir robots.txt con noindex. El primero no impide que la URL aparezca.
• Dar por indexado lo publicado. Se cuenta, y la diferencia suele sorprender.
• Mezclar dos ejes en la misma taxonomía. Se paga años después, en una migración.
• Verificar sobre lo generado y no sobre lo servido. Lo que decide es lo que se sirve.

Datos y transparencia

Que el 5 de julio de 2024 Google completó el paso a indexación mobile-first para todos los sitios y dejó de rastrear con el robot de escritorio, manteniendo solo una lista reducida de excepciones que revisa unas pocas veces al año, procede de su propio anuncio, comprobado el 13 de agosto de 2026. Que las checklists de auditoría técnica mejor posicionadas en español siguen incluyendo la comprobación de paridad entre escritorio y móvil es una observación del mismo día y se recoge como punto caducado, no como fuente.

Los tres requisitos técnicos, la distinción entre robots.txt y noindex, la ausencia de garantía de indexación y que los datos estructurados no son factor de posición proceden de la documentación pública de Google, comprobada el 12 de agosto de 2026. El orden de capas es criterio operativo sobre una cartera con más de 300 millones de impresiones anuales.

Lo que esto cambia

El SEO técnico tiene mala fama de disciplina infinita, y esa fama viene del formato en que se entrega.

Un informe de doscientos avisos parece trabajo para un año y produce parálisis. Las mismas doscientas líneas ordenadas por capa suelen colapsar en cuatro tareas reales y ciento noventa y seis irrelevantes para ese sitio concreto. La diferencia no está en el conocimiento técnico: está en haber decidido el orden antes de abrir la herramienta, porque una vez abierta, el orden lo decide ella.

Preguntas frecuentes