Qué es el SEO técnico y qué incluye

Tenemos tendencia a estructurar estas tareas como una lista de comprobación. El inconveniente es que una lista presenta cuarenta puntos como si pesaran igual, y en la práctica dos de ellos deciden el resultado y los treinta y ocho restantes son ruido hasta que esos dos están resueltos. Este artículo se organiza por orden de diagnóstico.

Un buscador tiene que poder hacer tres cosas con una página antes de que su contenido entre en juego: llegar a ella, guardarla en su índice y entender de qué trata. El SEO técnico se ocupa de que esas tres cosas ocurran sin fricción.

La frontera con las otras disciplinas es útil aunque no sea exacta. El SEO de contenidos decide qué se dice y para qué consulta. El SEO externo trabaja lo que otros sitios dicen del tuyo. El técnico trabaja sobre el vehículo: si el vehículo no arranca, el destino da igual.

Eso explica la característica que más lo distingue. El trabajo de contenidos produce mejoras acumulativas y visibles. El técnico produce sobre todo la ausencia de problemas, que nadie percibe. Un sitio con el SEO técnico resuelto no destaca por nada en particular; un sitio con un fallo técnico serio puede perder meses de trabajo de contenido sin que nadie sepa por qué

El orden importa porque los problemas se anulan entre sí. Optimizar el rendimiento de una página que está bloqueada por robots.txt no produce ningún efecto, y sin embargo aparece en cualquier informe automático como una recomendación válida.

La secuencia que tiene sentido:

1. ¿Los rastreadores pueden acceder? Bloqueos en robots.txt, restricciones del servidor, cortafuegos que responden con error a los agentes de buscador, zonas protegidas por contraseña.
2. ¿Las páginas están indexadas? Etiquetas noindex heredadas de un entorno de pruebas, canónicas apuntando a otra URL, páginas huérfanas sin ningún enlace entrante.
3. ¿El contenido llega en el HTML? Si la respuesta solo aparece tras ejecutar código en el navegador, parte del proceso de rastreo se complica y otros sistemas directamente no la ven.
4. ¿Las redirecciones funcionan como redirecciones? Aquí es donde aparecen los fallos más caros y menos visibles.
5. ¿La arquitectura es coherente? Estructura de URLs, jerarquía, enlazado interno, duplicidades.
6. ¿El rendimiento acompaña? Medido con datos de usuarios reales, además de los de laboratorio.
7. ¿Las entidades están declaradas? Datos estructurados, autoría, coherencia entre versiones de idioma.

Los tres primeros pasos son binarios: se cumplen o no. Los cuatro siguientes admiten grados. Cualquier informe que empiece por el punto seis sin haber verificado los tres primeros está optimizando algo que quizá no se está mirando.

Es el bloque donde un fallo cuesta más y se detecta más tarde, porque el sitio sigue funcionando con normalidad para las personas.

Acceso

El archivo robots.txt gobierna qué puede pedir cada agente. Conviene revisarlo entero después de cada despliegue: un Disallow: / heredado de un entorno de pruebas es el error clásico y puede pasar semanas sin que nadie lo note. Los cortafuegos y los módulos de seguridad del servidor son la segunda fuente: bloquean por comportamiento y pueden estar respondiendo con error a rastreadores legítimos sin dejar rastro en la aplicación.

Indexación

La etiqueta noindex y la canónica hacen cosas distintas y se confunden a menudo. La primera pide que la página no entre en el índice. La segunda declara cuál es la versión preferida cuando hay varias URLs con contenido equivalente. Una canónica que apunta a otra página equivale a pedir que la propia no se indexe, y es un error frecuente en sitios con varios idiomas o con parámetros de filtrado.

Redirecciones

Una redirección tiene que ser una respuesta del servidor con código 301 o 302. Cuando en su lugar se sirve una página que carga y luego redirige por instrucción del navegador (una etiqueta meta refresh o un salto por código), el resultado para la persona es idéntico: acaba en el destino correcto. Para el buscador no lo es. Ese tipo de salto transmite mal las señales acumuladas, o directamente no las transmite, y las URLs antiguas pueden quedar en el índice compitiendo con las nuevas.

Un caso real: redirecciones que el servidor devolvía como 200

En un proyecto reciente migramos un sitio de WordPress a Strapi como gestor y Nuxt 4 en la capa visible. Se aprovechó para rediseñarlo acorde a su identidad y para rehacer la arquitectura completa, que era el problema de fondo, y se eliminó el contenido que no estaba alineado con el negocio y solo atraía consultas sin valor.

La nueva arquitectura produjo más de 800 URLs reescritas en dos idiomas, más las redirecciones de las URLs eliminadas. El mapa se planteó con cuidado y las redirecciones se declararon en Nuxt. El sitio se aloja en un servidor que no es puramente de renderizado en servidor, así que se optó por prerenderizar las páginas para ganar velocidad, con tres capas apiladas: Apache, Nginx como proxy inverso y Nitro.

Ahí apareció el problema. Cuando la URL de origen de una redirección está también en la lista de rutas a prerenderizar, Nitro la prerenderiza igualmente y genera un archivo HTML de unos cien bytes, sin contenido, que Nginx sirve con código 200. Para un buscador eso es un soft 404 y la pérdida completa de la señal de redirección, no un 301.

Lo difícil fue detectarlo, porque todas las comprobaciones habituales lo daban por bueno:

• La compilación sale en verde. Nitro trata la respuesta 3xx como un éxito: la ruta figura como prerenderizada en el registro, sin ningún aviso.
• curl -I devuelve 200 con content-type: text/html. Nada indica error.
• En el navegador funciona. La etiqueta meta http-equiv="refresh" lleva al destino en cero segundos. Comprobado a mano, el redirect parece correcto.
• Los rastreadores de auditoría también lo siguen. Las herramientas del sector traen activada por defecto la opción de seguir el meta refresh, así que informan de un 200 y después del destino. No aparece en el informe de redirecciones ni en el de errores.
• Solo se ve mirando el fichero (unos cien bytes, sin <body>) o semanas después en la consola de búsqueda, cuando esas URLs figuran como página con redirección ausente y suben los soft 404 y los duplicados sin canónica.

El daño es acumulativo y silencioso: la URL antigua sigue indexada, no consolida autoridad hacia la nueva y compite con ella.

La solución fue mover todas las redirecciones a Nginx, que es la capa por encima de Nitro. Así la petición se resuelve antes de llegar a la aplicación, el redirect apunta directo al destino y desaparece el soft 404.

De este caso salen dos criterios generales, aplicables fuera de este stack concreto. El primero es que las redirecciones se resuelven en la capa más alta posible del servidor, no en la aplicación, porque cada capa por debajo puede reinterpretarlas. El segundo es que una comprobación manual y una herramienta de auditoría pueden coincidir en un falso positivo: si las dos siguen el mismo tipo de salto, las dos informan de lo mismo y ninguna detecta nada.

La comprobación es sencilla y conviene automatizarla: pedir cada URL antigua sin seguir la redirección y verificar que el servidor devuelve 301 con la cabecera de destino correcta. Un listado de varios cientos de redirecciones se audita en minutos con un script y no se audita nunca a mano.

Aquí hay una confusión que conviene deshacer antes de nada, porque afecta a cómo se lee cualquier informe.

Existen dos mediciones distintas del mismo fenómeno. Una es de laboratorio: una herramienta carga la página una vez, en condiciones simuladas, y devuelve una puntuación. Otra es de campo: recoge lo que experimentaron usuarios reales durante los últimos veintiocho días.

Lo que un buscador utiliza como señal son los datos de campo. La puntuación de laboratorio es una herramienta de diagnóstico, no la señal.

Las dos pueden discrepar de forma llamativa. Un sitio puede devolver una puntuación de laboratorio de 90 sobre 100 y tener la evaluación de campo suspendida, con un tiempo de carga del elemento principal de tres segundos. No es contradictorio: la primera midió una carga en condiciones controladas y la segunda recogió miles de visitas reales con conexiones y dispositivos peores.

De ahí salen dos consecuencias prácticas:

• Una captura de pantalla con cuatro círculos verdes no demuestra que el rendimiento esté resuelto. Demuestra que una carga concreta salió bien.
• Un sitio sin tráfico suficiente no tiene datos de campo, así que su rendimiento real está sin medir por definición. Es normal en proyectos nuevos y conviene decirlo en lugar de presentar la puntuación de laboratorio como si fuera equivalente.

Sobre el peso de esta señal en el posicionamiento conviene ser sobrio: se ha descrito de forma consistente como criterio de desempate entre contenidos de calidad comparable, no como palanca de subida. Un sitio lento con el mejor contenido de su SERP no baja por eso; dos sitios equivalentes se ordenan por eso.

Lo que sí es incuestionable es el efecto sobre la conversión, que es un motivo suficiente por sí solo y no depende de ninguna interpretación sobre algoritmos.

El marcado declara de forma explícita lo que el contenido dice de manera implícita: que esto es un artículo, que lo firma esta persona, que esta organización lo publica, que este producto tiene este precio.

Tiene dos funciones que conviene separar. La primera es habilitar resultados enriquecidos en el buscador, que solo existen para ciertos tipos y con requisitos concretos. La segunda, cada vez más relevante, es establecer la entidad sin ambigüedad para los sistemas que recuperan y citan contenido.

Los criterios que evitan los fallos habituales:

• Marcar solo lo que está visible en la página. Un bloque de preguntas frecuentes declarado en el marcado pero ausente del contenido incumple las directrices.
• Referenciar por identificador en lugar de repetir el objeto. La organización se define una vez en el sitio y las demás páginas la referencian. Repetirla entera en cada página genera entidades que pueden contradecirse.
• Usar el tipo honesto. Un artículo que habla de un servicio se marca como artículo, y una página de caso como artículo o como obra, según lo que sea.
• No marcar reseñas sobre uno mismo. Un testimonio publicado en el propio sitio marcado como valoración es autorreferencial y contraviene las directrices.

Los rangos de precio se declaran como precio mínimo, no como precio.

Un apunte sobre el volumen: marcar más tipos no produce mejor resultado. Lo que rinde es un marcado correcto y mínimo, porque un solo error invalida el bloque entero en el que aparece.

La arquitectura es la parte del SEO técnico más cara de corregir a posteriori, y por eso la que más conviene decidir antes de construir.

Estructura de URLs

Estable, legible y con una jerarquía que refleje la del contenido. Cualquier decisión aquí es reversible solo a costa de un plan de redirecciones, así que el momento de tomarla es el diseño del proyecto.

Duplicidades

El mismo contenido accesible desde varias direcciones (con y sin barra final, con y sin www, con parámetros de orden o de filtro) reparte señales entre versiones. Se resuelve con canónicas coherentes y con una única forma servida por el servidor.

Enlazado interno

Es la parte que más se descuida y la que más rinde en sitios medianos. Determina qué páginas reciben autoridad y cómo se descubren. Dos comprobaciones que casi siempre devuelven trabajo: páginas sin ningún enlace entrante desde el propio sitio, y textos de anclaje que no dicen a dónde llevan.

Profundidad

Cuántos clics separan una página de la portada. Una página relevante a cinco niveles de profundidad está mal colocada, con independencia de su calidad.

Una migración es el único momento en que un sitio puede perder años de trabajo en una tarde. Sea un cambio de dominio, de tecnología o de arquitectura de URLs, el procedimiento es el mismo.

1. Inventario completo antes de tocar nada. Todas las URLs indexadas, con su tráfico, sus posiciones y sus enlaces entrantes. Sin esta foto previa no hay forma de saber después qué se ha perdido.
2. Mapa de correspondencias uno a uno. Cada URL antigua a su equivalente. Las que no tengan equivalente exacto van a la página más próxima en intención, nunca a la portada de forma masiva.
3. Redirecciones 301 servidas por el servidor, verificadas una a una antes del cambio.
4. Conservación de las señales: títulos, encabezados, datos estructurados y contenido de las páginas que ya posicionaban. Una migración no es el momento de rehacer los textos.

Vigilancia intensiva las primeras semanas: cobertura de indexación, errores de rastreo, evolución de posiciones.

La caída temporal en las semanas siguientes es esperable y suele recuperarse. Lo que no se recupera solo es una redirección mal planteada o un mapa incompleto.

El exceso de celo técnico consume presupuesto que rinde más en otro sitio.

1. Perseguir el 100 en una herramienta de laboratorio. Los últimos puntos cuestan mucho y no se traducen en datos de campo.
2. Corregir todos los avisos de un rastreador. Un informe de auditoría devuelve cientos de líneas y buena parte son informativas. Sin priorización, se trabaja en lo fácil de arreglar en lugar de en lo que importa.
3. Marcar tipos de schema que no habilitan nada ni aportan a la entidad.
4. Optimizar imágenes cuando el problema es el tiempo de respuesta del servidor. El diagnóstico primero, la optimización después.
5. Reescribir URLs que ya funcionan por un criterio estético. Todo cambio de URL es una redirección más y un riesgo añadido.

El criterio: una tarea técnica se justifica cuando resuelve un obstáculo identificado, no cuando aparece en una lista.