Marketing / Analítica / Web / Tecnología

SEO técnico: del rastreo a una arquitectura coherente.

El SEO técnico comprueba si los buscadores pueden descubrir, descargar, procesar e indexar las páginas que quieres hacer visibles. También revisa la coherencia entre URLs, estados HTTP, contenido y versiones de idioma. Una web puede tener textos excelentes y seguir encontrando dificultades si sus páginas no son accesibles o envían instrucciones contradictorias. El SEO técnico diagnostica dónde falla el proceso y define la solución; programar es una forma de implementarla, no un sinónimo de esta disciplina.

SEO técnico en un minuto

Imagina una biblioteca con buenos libros, pasillos cerrados y referencias duplicadas en el catálogo. El contenido existe, pero cuesta encontrar la versión correcta. El SEO técnico mejora el acceso y la organización. Empieza por el descubrimiento y las respuestas del servidor; sigue con el renderizado y las instrucciones de indexación, y después prioriza las mejoras de rendimiento. Superar estas comprobaciones no garantiza la indexación ni una posición determinada.

El SEO técnico sigue el recorrido del rastreo a la indexación

La guía general de SEO sitúa el rastreo y la indexación dentro del proceso de búsqueda. Aquí revisamos las condiciones técnicas que requiere cada etapa y por qué un fallo en una necesita una respuesta distinta de un problema en la siguiente.

Crawling o rastreo. Un rastreador solicita URLs y descarga sus recursos. Puede descubrirlas mediante enlaces internos, referencias externas o un sitemap. Que una dirección exista en una hoja de cálculo no significa que sea fácil encontrarla en la web. Comprueba la disponibilidad del servidor, los permisos de rastreo y las rutas hacia las páginas importantes. Descargar una página y decidir indexarla son procesos distintos.

Indexación. Después de descargar y procesar contenido, el buscador puede incorporar información sobre él a su índice. El rastreo correcto no garantiza esa inclusión. La calidad, las duplicidades y las instrucciones de indexación pueden influir. Utiliza el motivo concreto que muestra una herramienta como punto de partida. “No indexada” describe una situación, pero no explica por sí sola su causa ni demuestra que haga falta escribir más texto.

Estados HTTP y redirecciones. Una respuesta 200 suele indicar que el recurso se entrega correctamente; 301 y 308 comunican un traslado permanente. Una página eliminada puede responder adecuadamente con 404 o 410. Los errores 5xx exigen revisar el servidor. Evita mostrar “página no encontrada” acompañada de una respuesta de éxito que no corresponde. Redirige contenido trasladado a un sustituto pertinente, no todas las URLs antiguas a la portada, y reduce las cadenas innecesarias.

robots.txt y noindex. robots.txt regula el acceso de rastreadores a recursos determinados. No es una instrucción fiable para impedir que una URL aparezca en resultados. noindex se refiere a la indexación, pero el robot debe poder obtener la página o la respuesta para leerlo. Un bloqueo de rastreo puede impedir que descubra un cambio a noindex. Ninguna de estas opciones sustituye la autenticación cuando la información debe ser privada.

JavaScript y renderizado. El servidor puede entregar HTML completo o una estructura que JavaScript rellena después. Google puede procesar JavaScript, pero los recursos inaccesibles, los errores y el contenido dependiente de acciones del usuario introducen riesgos. Compara la respuesta inicial con la página renderizada, incluyendo texto, enlaces y metadatos. Que funcione en tu pantalla después de entrar en una cuenta o pulsar un botón no demuestra que el rastreador reciba el mismo contenido.

Coordinar arquitectura, versiones y señales de indexación

La arquitectura asigna una función y unas relaciones a cada página. Una categoría agrupa productos, una página central organiza conceptos y una ficha desarrolla una pregunta concreta. Las carpetas de la URL son solo una parte de esa estructura. Los enlaces y las migas de pan pueden expresar una jerarquía aunque se utilicen direcciones cortas. No dejes que una plantilla genere rutas para cualquier variación sin decidir antes qué utilidad tiene cada una.

Canonical y duplicidades. La etiqueta canonical indica la versión que se prefiere como representativa de contenidos iguales o muy similares. Es una señal, no una orden absoluta. Coordina enlaces internos, redirecciones y sitemap con esa URL preferida. No apuntes el canonical a una página diferente para ocultar un problema. La duplicación corriente no implica automáticamente una penalización, pero puede dispersar procesamiento e informes. Investiga parámetros, versiones de impresión y rutas alternativas de producto.

Sitemap XML. Es una lista de URLs que quieres dar a conocer a los buscadores. Incluye preferentemente páginas accesibles, canónicas y destinadas a indexarse. Retira errores persistentes y utiliza lastmod para reflejar cambios sustanciales. El sitemap no reemplaza la navegación. Puede tener una utilidad distinta en una pequeña web bien enlazada y en un catálogo amplio que incorpora páginas con frecuencia.

Navegación por facetas. Los filtros de talla, color, marca o precio pueden producir enormes combinaciones de URLs. Decide cuáles responden a una búsqueda propia y tienen información suficiente. “Calzado de trabajo impermeable” puede merecer una categoría estable; cada ordenación de resultados normalmente no. El espacio de rastreo innecesario requiere decisiones sobre URLs y acceso. Los canonicals por sí solos no son un freno eficiente para combinaciones ilimitadas. No mezcles robots.txt, noindex y canonical sin comprobar qué instrucciones seguirá pudiendo leer el robot.

Internacionalización. Cada idioma debe disponer de una URL accesible. Hreflang relaciona versiones equivalentes y necesita referencias recíprocas y coherentes. Una página neerlandesa suele tener canonical hacia su propia versión, no hacia una traducción elegida como única válida. La navegación de idiomas debe llevar al mismo tema. Hreflang no traduce contenido ni corrige una adaptación inglesa o española incompleta.

Ejemplo de diagnóstico · una instrucción heredada de pruebas
  1. Síntoma

    Una tienda ficticia publica una categoría con productos y una explicación útil. Los clientes pueden abrirla, pero Search Console informa de una instrucción noindex.

  2. Investigación

    La instrucción procede de la plantilla de pruebas. El desarrollador revisa plantillas relacionadas y cabeceras HTTP para delimitar el alcance antes de modificar la configuración.

  3. Corrección y seguimiento

    Se elimina únicamente el noindex accidental. La página conserva su acceso, recibe enlaces adecuados y aparece con la URL correcta en el sitemap. Después se inspecciona y se observa su evolución, sin prometer indexación inmediata.

Rendimiento, datos estructurados y un plan de trabajo verificable

Core Web Vitals. LCP se relaciona con la aparición del mayor elemento visible de contenido, INP con la respuesta a las interacciones y CLS con los desplazamientos inesperados del diseño. Revisa datos de usuarios reales cuando estén disponibles, además de pruebas de laboratorio. Una imagen principal pesada, scripts bloqueantes y dimensiones ausentes requieren soluciones distintas. Unas buenas métricas favorecen la experiencia, pero no convierten una categoría incompleta en una respuesta relevante para cualquier búsqueda.

Datos estructurados. Un marcado como JSON-LD describe información visible mediante una estructura definida. Elige tipos y propiedades que representen la página. Article describe un artículo, no una reseña inventada; Product requiere datos reales del producto. Valida sintaxis y exactitud. No todos los tipos de schema generan una presentación especial en Google, y el marcado válido no la garantiza. El SEO de entidades explica identidad y relaciones más allá del código.

El SEO técnico no equivale a programación. Una revisión puede detectar que ciertos filtros indexables no cumplen una función distinta. El desarrollador ajusta entonces rutas o plantillas, mientras un editor mejora las categorías útiles. La solución técnica responde a una decisión sobre información. “El código es válido” y “la página adecuada se puede encontrar” son comprobaciones diferentes; ambas pueden ser necesarias antes de dar un problema por resuelto.

  • Selecciona plantillas representativas: portada, servicio, categoría, producto y versión de idioma.
  • Comprueba acceso, estado HTTP, contenido renderizado y ruta de descubrimiento interno.
  • Contrasta canonical, noindex, robots.txt y sitemap para detectar contradicciones.
  • Revisa filtros, redirecciones, uso móvil, datos estructurados y rendimiento.
  • Prioriza bloqueos frente a detalles menores y registra responsable, evidencia y revisión posterior.

Mantén visible la relación con el SEO on-page. Una entrega técnica fiable permite acceder a la respuesta, pero el contenido debe seguir resolviendo una necesidad. A la inversa, reorganizar información puede requerir decisiones sobre redirecciones o equivalencias de idioma. Guarda una situación inicial y un registro de cambios. Si aparece un problema nuevo, podrás investigar qué se modificó en lugar de revertir ajustes al azar.