Antes de empezar a ofrecer SEO técnico como servicio, hicimos lo que la mayoría de las agencias evita: apuntamos el proceso hacia nosotros mismos.
Hicimos una auditoría técnica completa de prixelo.com. No un entorno de staging, no un sitio de demostración — el sitio real, el que los clientes potenciales revisan antes de escribirnos. Esperábamos encontrar un puñado de problemas menores. Encontramos siete cosas que estaban jugando activamente en nuestra contra.
Este artículo es esa auditoría, sin editar. Sin cliente compuesto, sin caso de estudio inventado. Solo lo que encontramos en nuestro propio sitio y lo que cada error enseña sobre cómo los motores de búsqueda realmente ven una página frente a cómo un navegador te la muestra.
El sitemap no incluía la mayor parte del sitio
Abrimos sitemap.xml esperando encontrar una formalidad. En cambio, encontramos un archivo que listaba solo una fracción de nuestras páginas reales. Secciones enteras del sitio —páginas que ya habíamos publicado, enlazado internamente y que esperábamos que posicionaran— simplemente no estaban ahí.
Un sitemap no es un extra opcional. Es el mapa que le entregas a Google para que no tenga que adivinar la estructura de tu sitio rastreando enlaces a ciegas. Una página que está activa, enlazada internamente y ausente del sitemap puede terminar indexándose de todos modos, pero de forma más lenta, menos confiable, y le indica a los rastreadores que los metadatos de tu sitio no son fiables. Si el sitemap falla una vez, un rastreador tiene menos motivos para tratarlo como autoritativo en cualquier otro punto.
Nuestro JSON-LD de Organization estaba roto en todo el sitio
Revisamos los datos estructurados con un validador por costumbre. El nuestro falló. En todas las páginas.
La causa era un bug de escapado en la plantilla: un carácter dentro de nuestro schema de Organization se estaba codificando de forma incorrecta al renderizar, lo que dejaba el bloque JSON-LD sintácticamente inválido en cada página donde aparecía. Google no interpreta un JSON roto de forma parcial. O lo interpreta correctamente, o descarta el bloque completo. Así que, durante todo el tiempo que esto estuvo activo, no llegaba ningún dato estructurado a Google en todo el sitio, mientras nosotros creíamos tener el markup completo. Es el tipo de bug que no genera ningún error en el navegador —la página se ve perfectamente bien— y no da ninguna advertencia a menos que lo busques específicamente en un validador de schema o en el informe de resultados enriquecidos de Search Console.
Soft-404 devolviendo HTTP 200
Algunas URLs rotas o eliminadas del sitio no devolvían un estado 404. Estaban sirviendo contenido de respaldo —una página genérica— mientras el servidor le decía al navegador y a cualquier rastreador «200 OK, esta página existe».
Eso es un soft-404, y es peor que uno real. Un 404 verdadero le dice claramente a los motores de búsqueda: esta URL ya no existe, sácala del índice. Un soft-404 les dice: esta URL está bien, sigue rastreándola e indexándola, aunque aquí no haya nada. Si no se corrige, esto desperdicia presupuesto de rastreo en páginas que no existen y puede diluir cómo se evalúan tus páginas reales, porque el rastreador está gastando tiempo y confianza en callejones sin salida que dicen estar activos.
Etiquetas canonical apuntando al dominio equivocado
Varias páginas tenían etiquetas canonical que apuntaban a la versión sin «www» de nuestro propio dominio, la cual a su vez redirige a otro lugar —un resto de una configuración anterior. Una etiqueta canonical es una instrucción directa a los motores de búsqueda: «indexa esta URL como la versión autoritativa, no la que estás viendo ahora». Cuando apunta al lugar equivocado, le estás diciendo explícitamente a Google que atribuya tu propio contenido a otra URL. En el mejor de los casos, se ignora. En el peor, estás desviando activamente tus propias señales de posicionamiento lejos de la página que las necesita.
Meta descriptions cortadas a mitad de palabra
Es algo menor, pero es el tipo de cosa que erosiona la confianza en conjunto: varias meta descriptions se cortaban a mitad de palabra directamente en el HTML crudo, no solo truncadas al mostrarse en los resultados de búsqueda. Eso es un bug de plantilla o de límite de caracteres, no un artefacto de visualización, y aparece como oraciones inconclusas dentro de tus etiquetas <meta> —visibles para cualquiera que vea el código fuente, y una señal pequeña pero real de descuido en una página que intenta parecer creíble.
Un robots.txt obsoleto de un directorio anterior al sitio actual
Este fue el hallazgo más extraño. El robots.txt que se estaba sirviendo no era el que estaba en nuestro código actual. Venía de un directorio legado que había quedado en el servidor —un resto de una versión anterior del sitio que debería haberse retirado por completo. La aplicación en producción no tenía idea de que ese archivo existía, ni de que era el que los rastreadores realmente estaban leyendo.
robots.txt es uno de los primeros archivos que solicita un rastreador. Si la versión que se sirve está desactualizada, puede estar bloqueando rutas que deberían ser rastreables, permitiendo otras que no deberían serlo, o simplemente apuntando a un sitemap que ya no existe. Y como vive fuera de tu flujo normal de despliegue, resulta invisible para cualquiera que revise el código actual —hay que comprobar lo que realmente se está sirviendo en la URL, no lo que crees haber publicado.
Páginas que le decían a los rastreadores «no encontrado» por detectar el slug solo en el cliente
El último es un problema de renderizado en JavaScript, y es una trampa común para cualquier cosa construida con enrutamiento del lado del cliente. Ciertas páginas determinaban qué contenido mostrar según un slug que solo se resolvía en el navegador, después de que se ejecutara el JavaScript. Los rastreadores que no ejecutan completamente el JavaScript del cliente —o que agotan el tiempo de espera antes de que se resuelva— reciben la respuesta inicial del servidor, no encuentran ningún slug coincidente, y terminan viendo un estado de «no encontrado». La página funciona perfectamente para una persona. Es invisible o está rota para un rastreador que nunca llega lo bastante lejos como para ver el contenido real.
Lo que esto realmente enseña
Ninguno de estos bugs es exótico. Son los modos de falla estándar de cualquier sitio que ha crecido más allá de su primera versión: infraestructura legada que nadie dio de baja, un cambio de plantilla que rompió la codificación sin que nadie lo notara, un patrón de enrutamiento optimizado para personas pero nunca verificado contra el comportamiento real de los rastreadores. Cada uno de ellos era invisible en un navegador normal, e invisible a menos que alguien fuera a buscar específicamente cómo ve la página un rastreador, no cómo la ve una persona.
Ese es el verdadero trabajo. El SEO técnico no consiste en sugerir palabras clave ni en calendarios de contenido —consiste en encontrar la brecha entre cómo ves tu sitio y cómo lo ven los sistemas que deciden si indexarlo y posicionarlo. Corregimos los siete problemas en nuestro propio sitio como parte de la construcción de nuestro servicio de SEO, porque no íbamos a vender una auditoría que no hubiéramos aplicado primero sobre nosotros mismos.
Si quieres saber si tu propio sitio tiene versiones de estos mismos problemas, eso es exactamente lo primero que revisa nuestro equipo de SEO —antes de cualquier conversación sobre contenido o posicionamiento.
