Cuando estás hablando con profesionales de tu mismo sector, hay conceptos que se tratan con total normalidad y son sencillos de entender. Sin embargo cuando estás con clientes ajenos a la disciplina, estos mismo conceptos pueden resultar bastante más complicado de explicar. En mi caso, el SEO técnico es sin duda uno de ellos, porque decir que hay que trabajar la indexación, revisar cómo rastrea Google la web o mejorar determinados aspectos del código puede ser perfectamente correcto, pero no necesariamente ayuda a entender qué estamos haciendo ni por qué es importante.
En esos casos suelo partir de una cuestión bastante más sencilla. Trato de explicar primero que podemos tener una web que aparentemente funciona bien, carga en el navegador, permite navegar por sus páginas y muestra todo el contenido que esperamos. Sin embargo, eso no significa necesariamente que un buscador pueda acceder a ella, recorrerla e interpretar su contenido de la misma manera.
Precisamente ahí, cuando he establecido esa diferencia, es donde empiezo ya a hablar de SEO técnico propiamente. Porque es también donde puedo ayudar a entender por qué está tan relacionado con el desarrollo web, hasta el punto de que en ocasiones resulta difícil establecer dónde termina uno y empieza el otro.
Qué es el SEO técnico
El SEO técnico es la parte del posicionamiento web que se ocupa de facilitar que los buscadores puedan acceder a una web, rastrearla, interpretar correctamente su contenido e incorporar a sus índices las páginas que nos interesa que aparezcan en los resultados de búsqueda. Para conseguirlo interviene sobre aspectos relacionados con la propia construcción y funcionamiento del sitio.
Esto hace que exista bastante terreno compartido con el desarrollo web. Utilizar correctamente el HTML, controlar las respuestas del servidor, gestionar las redirecciones, evitar enlaces rotos o cuidar el rendimiento son buenas prácticas de desarrollo, pero algunas de estas decisiones también condicionan la forma en que un buscador descubre y procesa una web.
Una página puede funcionar perfectamente para el usuario y, aun así, generar varias URLs para un mismo contenido, mantener páginas importantes prácticamente aisladas o indicar por error que determinadas URLs no deben indexarse. El problema no estaría en que la web «no funciona», sino en que su implementación está dificultando que el buscador haga correctamente su trabajo.
Por eso el SEO técnico puede abarcar cuestiones muy diferentes, desde la configuración del servidor y las respuestas HTTP hasta la estructura del HTML, las URLs, el enlazado interno, el rendimiento o la manera en que JavaScript genera determinados contenidos. Todas ellas forman parte de una disciplina que, a su vez, es solo una pieza dentro de un trabajo más amplio de posicionamiento web.
Rastreo e indexación
Para que una página pueda aparecer en los resultados de búsqueda tiene que producirse antes un proceso que habitualmente pasa desapercibido. El buscador debe descubrir que esa URL existe, acceder a ella y decidir qué hacer con el contenido que encuentra. No obstante, aquí conviene distinguir dos conceptos relacionados, pero que no significan lo mismo: rastreo e indexación.
El rastreo es el proceso mediante el que los buscadores recorren la web siguiendo enlaces y otras fuentes de información para descubrir y visitar URLs. La indexación viene después y supone procesar esas páginas y, cuando corresponde, incorporarlas al índice desde el que se generan los resultados de búsqueda. Que Google pueda rastrear una URL, por tanto, no significa necesariamente que vaya a indexarla.
Buena parte del SEO técnico consiste en asegurarnos de que durante ese recorrido estamos dando las indicaciones adecuadas. Un archivo robots.txt puede limitar el acceso a determinadas zonas, una directiva noindex puede indicar que una página no debe formar parte del índice y una etiqueta canonical puede ayudar a señalar cuál es la versión que consideramos principal cuando existen varias URLs con contenido igual o muy parecido. A esto se suman las respuestas HTTP y las redirecciones, que también proporcionan información sobre el estado de cada recurso y sobre dónde debe continuar el rastreo.
El sitemap XML cumple otra función dentro de este proceso. Permite proporcionar a los buscadores una relación de las URLs que consideramos relevantes y facilitar su descubrimiento, algo especialmente útil cuando la estructura del sitio hace más difícil llegar a determinadas páginas. No sustituye a una buena organización ni al enlazado interno, pero sí constituye una herramienta adicional para ayudar al buscador a conocer la web.
También puede darse la situación contraria. Una URL que ya está en el índice deja de tener sentido, contiene información que no queremos que continúe apareciendo o necesitamos gestionar su desaparición de los resultados. En esos casos existen distintas formas de retirar una URL de Google, y conviene distinguir entre ocultarla temporalmente y conseguir que termine desapareciendo del índice.
Hay que tener claro que el objetivo no consiste en conseguir que Google «vea todo», sino en procurar que pueda acceder a lo que debe encontrar y reciba información coherente sobre qué queremos que ocurra con cada URL. Y para que ese recorrido funcione bien no basta con configurar unas cuantas directivas, sino que la propia forma en la que organizamos y relacionamos las páginas de la web tiene mucho que decir.
Arquitectura, URLs y enlazado interno
La arquitectura de una web también tiene consecuencias sobre cómo la recorren los buscadores. Si una página importante solo puede alcanzarse después de atravesar varios niveles de navegación, apenas recibe enlaces internos o directamente queda aislada del resto del sitio, estamos haciendo más difícil su descubrimiento y dando pocas pistas sobre la importancia que tiene dentro del conjunto.
Una estructura clara ayuda a establecer relaciones entre los contenidos. Las secciones principales pueden conducir hacia páginas más específicas y estas, a su vez, relacionarse con otros contenidos que amplían o complementan la información. No se trata de construir una jerarquía rígida en la que cada página solo pueda pertenecer a una rama, sino de conseguir que los enlaces respondan a relaciones que tengan sentido tanto para quien navega como para quien intenta interpretar el sitio.
Las URLs forman parte de esa organización, aunque conviene no atribuirles más importancia de la que tienen. Una dirección comprensible y estable facilita identificar un recurso y evita algunos problemas de mantenimiento, pero cambiar URLs únicamente para hacerlas más adaptadas al SEO puede acabar siendo contraproducente si no existe una razón de peso. Cada cambio obliga a gestionar correctamente la redirección desde la dirección anterior y abre la puerta a errores que antes no existían.
También hay que prestar atención a las distintas formas en las que una misma página puede llegar a ser accesible. Parámetros, filtros, sistemas de paginación o determinadas configuraciones del CMS pueden multiplicar el número de URLs sin que exista realmente contenido diferente detrás de cada una. En sitios pequeños quizá apenas tenga consecuencias, pero en proyectos con miles de páginas puede complicar considerablemente el trabajo de los buscadores y obligarnos a decidir qué URLs queremos que formen parte de la estructura y cuáles tiene sentido que aparezcan en los resultados.
El enlazado interno termina siendo una de las herramientas que permiten ordenar todo ese conjunto. Además de facilitar la navegación, ayuda a descubrir páginas y aporta contexto sobre la relación entre unos contenidos y otros. Por eso tiene más sentido enlazar cuando existe una relación real que intentar alcanzar un determinado número de enlaces por página.
Una arquitectura bien planteada facilita así el recorrido antes de que tengamos que recurrir a soluciones para corregir sus carencias. Pero que un buscador pueda llegar sin problemas a una página es solo una parte del proceso. Cuando accede a ella, también tiene que encontrarse con una web capaz de responder y cargar de una forma razonable, que es donde entran en juego el rendimiento y la experiencia de carga.
Rendimiento y experiencia de carga
El rendimiento web engloba cuestiones muy diferentes, desde el tiempo que tarda el servidor en responder hasta el peso de las imágenes, la cantidad de recursos que hay que descargar o el trabajo que debe realizar el navegador para mostrar e interactuar con el contenido.
Aquí es fácil caer en una simplificación habitual y reducirlo todo a que una web rápida posiciona mejor. La relación no es tan directa. Google utiliza las Core Web Vitals como parte de sus sistemas para evaluar la experiencia de página, pero el rendimiento convive con muchas otras señales y no convierte automáticamente una página rápida en un buen resultado para una búsqueda. Optimizar una web que no responde a lo que el usuario necesita no va a solucionar el problema de fondo.
Eso no resta importancia al rendimiento dentro del SEO técnico. Una página excesivamente pesada, un servidor con tiempos de respuesta elevados o una implementación que depende de una gran cantidad de JavaScript pueden dificultar el acceso al contenido y, sobre todo, empeorar notablemente la experiencia del usuario. En sitios grandes, además, el comportamiento del servidor puede influir en la forma y frecuencia con la que los buscadores recorren sus páginas.
Las soluciones dependen mucho de dónde se encuentre el problema. Puede ser necesario optimizar imágenes, revisar la caché, reducir recursos innecesarios, mejorar la respuesta del servidor o replantear cómo y cuándo se cargan determinados elementos. Por eso prefiero entender el rendimiento como una cuestión que atraviesa tanto el desarrollo como el SEO técnico, y no como una puntuación que haya que perseguir de forma aislada. Las herramientas de medición son muy útiles para detectar problemas y comprobar mejoras, pero el objetivo sigue siendo que la página funcione de manera eficiente en condiciones reales.
Y una vez que la página ha podido ser descubierta y cargada correctamente, todavía queda otra cuestión técnica importante: que su contenido esté construido de forma que pueda interpretarse adecuadamente. Ahí es donde el propio HTML y la información que incorporamos a él adquieren especial relevancia.
HTML, contenido interpretable y datos estructurados
El HTML no sirve únicamente para conseguir que el navegador muestre textos, imágenes, enlaces o formularios. También aporta estructura y significado, y esa información ayuda a los buscadores a interpretar qué están encontrando.
La elección de los elementos adecuados permite distinguir un encabezado de un simple texto destacado, identificar un enlace como tal o establecer la estructura principal de un documento. Lo mismo ocurre con elementos aparentemente sencillos como el atributo alt de una imagen. No se trata de añadir información pensando exclusivamente en Google, sino de construir un documento que describa correctamente aquello que contiene. De hecho, muchas de estas decisiones tienen también implicaciones directas en accesibilidad.
Sobre esa base podemos proporcionar información todavía más explícita mediante los datos estructurados. Con ellos es posible indicar que determinados datos de una página corresponden, por ejemplo, a un producto, una organización, un evento o una receta y describir las propiedades asociadas a esa entidad utilizando un vocabulario que los buscadores pueden interpretar.
Esto no significa que añadir datos estructurados vaya a mejorar por sí mismo la posición de una página. Su utilidad está en ayudar a comprender determinados contenidos y, cuando se cumplen los requisitos correspondientes, hacer posible que sean aptos para ciertas presentaciones enriquecidas en los resultados de búsqueda. Una de las formas de incorporar esta información al propio HTML es mediante microdatos, aunque existen otras maneras de implementar datos estructurados.
Hasta aquí hemos partido de un escenario relativamente sencillo en el que el contenido que queremos mostrar está disponible en el documento que recibe el navegador. Sin embargo, las aplicaciones web actuales pueden construir una parte importante de la página después de esa primera respuesta, modificarla mediante JavaScript o incluso ofrecer experiencias distintas según el dispositivo. En esos casos, la forma en que se genera el contenido pasa a ser también una cuestión relevante para el SEO técnico.
Móvil, JavaScript y otras dificultades de rastreo
La presencia de JavaScript no supone por sí misma un problema para el posicionamiento. Forma parte del desarrollo web actual y los buscadores han avanzado mucho en su capacidad para procesar páginas que lo utilizan. La cuestión está en qué dependemos de él para hacer visible el contenido y qué ocurre si ese proceso de renderizado no se desarrolla como esperamos.
En una web tradicional, buena parte del contenido llega ya incluido en el HTML que devuelve el servidor. En otros desarrollos, ese primer documento puede contener muy poca información y depender de JavaScript para solicitar datos, construir elementos o completar la navegación. Para el usuario la diferencia puede resultar prácticamente invisible, pero estamos introduciendo pasos adicionales antes de que todo el contenido esté disponible para ser procesado.
Esto obliga a prestar atención a cómo se generan elementos importantes como enlaces, textos o metadatos y a comprobar qué acaba recibiendo y renderizando realmente el buscador. Dependiendo de la tecnología y del proyecto, puede ser preferible generar determinadas partes en el servidor, recurrir a sistemas de renderizado híbrido o simplemente asegurarnos de que la implementación actual no está ocultando involuntariamente información relevante.
Algo parecido ocurre cuando pensamos en dispositivos móviles. Hace tiempo que no tiene demasiado sentido considerar la versión móvil como una adaptación secundaria de la web. Google utiliza la versión que rastrea con su agente de usuario para smartphones para la indexación, por lo que eliminar contenido, enlaces o información relevante únicamente en determinados tamaños de pantalla puede tener consecuencias que van más allá de la experiencia visual. Un diseño responsive no consiste solo en conseguir que los elementos quepan en una pantalla más estrecha, sino en mantener accesible y funcional aquello que realmente importa.
JavaScript y móvil son buenos ejemplos de por qué el SEO técnico no puede reducirse a aplicar una configuración estándar. Dos páginas que visualmente parecen ofrecer lo mismo pueden estar construidas de maneras muy distintas y presentar problemas diferentes para un buscador. Detectarlos requiere mirar más allá de lo que vemos en pantalla y entender cómo está funcionando realmente la web.
Y esa diferencia entre comprobar una lista de requisitos y entender lo que sucede en un proyecto es especialmente importante cuando pasamos de la teoría al trabajo cotidiano.
Cómo se trabaja el SEO técnico en un proyecto real
Esta es una de las diferencias que más se perciben cuando trabajas con proyectos de clientes. En un proyecto real rara vez nos encontramos con todos los problemas que hemos visto a la vez ni tienen todos la misma importancia. Una auditoría puede devolver decenas o incluso cientos de avisos, pero eso no significa que debamos resolverlos en el orden en el que aparecen ni que todos tengan una repercusión significativa. Parte del trabajo consiste precisamente en separar los problemas reales de aquello que simplemente podría hacerse de otra manera.
El punto de partida también cambia mucho. Si estoy desarrollando una web desde cero, muchas decisiones pueden tomarse antes de que se conviertan en problemas. Es posible definir correctamente la arquitectura, controlar qué URLs se generan, decidir cómo se renderiza el contenido o incorporar determinadas necesidades de rendimiento durante el propio desarrollo. Cuando recibo una web que lleva años funcionando, la situación es distinta: antes de modificar nada hay que entender qué existe, por qué se ha hecho así y qué consecuencias puede tener tocarlo.
Por eso una auditoría técnica no debería quedarse en una colección de puntuaciones y recomendaciones automáticas. Las herramientas permiten detectar redirecciones, errores, páginas duplicadas, tiempos de respuesta elevados o determinadas características del HTML, pero no conocen necesariamente la función que cumple cada página ni las decisiones que han dado lugar a esa implementación. Un aviso puede ser irrelevante en un proyecto y convertirse en un problema importante en otro.
También hay que valorar el coste y el riesgo de cada intervención. Cambiar la estructura de miles de URLs, modificar el sistema de renderizado de una aplicación o sustituir una parte importante de la plantilla puede tener sentido si existe un problema que lo justifica. Hacerlo únicamente porque una herramienta propone una solución técnicamente más limpia puede introducir más problemas de los que pretendíamos resolver.
En la práctica, trabajar el SEO técnico consiste en observar cómo está funcionando la web, identificar qué está dificultando realmente que los buscadores accedan a ella y comprendan su contenido, y establecer prioridades. Después hay que implementar los cambios y comprobar sus efectos, porque una corrección técnica no termina en el momento en que modificamos el código.
Detectar un problema es solo una parte del trabajo. Muchas veces hay que comprender cómo está construida la web para encontrar una solución que encaje con el proyecto y no se limite a corregir el síntoma. Y eso también ayuda a poner en perspectiva hasta dónde puede llegar esta parte del SEO.
El SEO técnico pone la base, pero no posiciona una web por sí solo
Después de todo lo anterior, es fácil entender por qué una web con problemas técnicos puede estar limitando sus posibilidades en buscadores. Si estos encuentran dificultades para descubrir determinadas páginas, acceden a distintas URLs con el mismo contenido o no pueden interpretar correctamente una parte importante de la información, tenemos obstáculos que conviene resolver. Pero eliminar esos obstáculos no significa que hayamos resuelto el posicionamiento.
Podemos tener una web rápida, perfectamente accesible para los buscadores, con una arquitectura coherente y un HTML bien construido y, aun así, no aparecer para las búsquedas que nos interesan. Para hacerlo necesitamos también ofrecer un contenido que responda a esas búsquedas, plantear correctamente qué páginas deben cubrir cada necesidad y competir con otras webs que persiguen objetivos similares.
Por eso no entiendo el SEO técnico como una fase independiente que se completa y se da por terminada. Algunas decisiones se toman durante el desarrollo inicial y otras aparecen con la evolución del proyecto. Añadir nuevas secciones, cambiar una plantilla, modificar el funcionamiento de un CMS o incorporar una nueva tecnología puede alterar una base técnica que hasta entonces funcionaba correctamente.
El papel que tiene dentro del posicionamiento web es bastante concreto y se centra en conseguir que la tecnología no se convierta en un impedimento para aquello que queremos hacer con el contenido y con la propia web. Cuando esa base se trabaja conjuntamente con la estructura, el contenido y el resto de decisiones del proyecto, dejamos de pensar en el SEO como una serie de correcciones posteriores y pasa a formar parte de la manera en la que construimos y mantenemos la página web.
Deja una respuesta