Perdimos el 95% de nuestro tráfico de Google en una noche. Bing nos sigue teniendo en el top 3.

Entre el 16 y el 17 de abril de 2026, nuestro tráfico orgánico de Google cayó alrededor de un 95% — de la noche a la mañana, literalmente. Sin penalización, sin aviso. Y lo más extraño: Bing seguía posicionando exactamente las mismas páginas en su top 3. Este es el post-mortem honesto — qué se rompió (fue nuestro propio código), cómo lo rastreamos hasta la hora exacta y qué sigue sin recuperarse.

Nos dedicamos profesionalmente a construir módulos de SEO, rendimiento y seguridad para PrestaShop. Que un desplome de tráfico golpeara a nuestra propia tienda fue una cura de humildad y, al final, algo revelador. Así que lo dejamos por escrito como es debido — incluidas las partes que aún no hemos arreglado.

Lo que NO fue (las pistas falsas que descartamos)

La mayoría de los consejos sobre “desplomes de tráfico” te mandan primero a estos sitios. Nosotros también fuimos, y los descartamos:

• No fue una penalización. Ninguna acción manual en Search Console, ningún aviso de enlaces artificiales. La API de inspección de URLs seguía mostrando nuestras páginas clave como “Enviada e indexada”. Fue una degradación de posiciones, no una desindexación.
• No fue (solo) una actualización del algoritmo. La core update de marzo de 2026 sí había terminado alrededor del 8 de abril — ocho días antes de nuestro precipicio — y no vamos a fingir que ese contexto de reprocesamiento fuera irrelevante. Pero una core update que se despliega durante semanas no explica que las impresiones diarias colapsen entre dos días consecutivos. Algo nuestro encajaba con la hora exacta.
• No fue principalmente “thin content” — aunque el reproche es justo. En todo caso teníamos más contenido del que nuestra autoridad justificaba: ~150 páginas de módulos en seis idiomas, más blog, documentación y FAQ. Creemos que esa huella hizo la recuperación más difícil, y tratamos la percepción de “contenido escalado y de bajo valor” como una hipótesis viva y sin resolver, no como algo que se pueda despachar sin más.
• No fue lo técnico obvio. robots.txt estaba limpio, el sitemap respondía, los canonicals y el hreflang (seis idiomas + x-default) eran correctos.

La pista que lo reencuadró todo: Bing posicionaba exactamente el mismo contenido en su top 3 — con un perfil de dominios de referencia tan escaso que nuestra puntuación de “autoridad” de terceros es prácticamente cero. Las mismas páginas, dos buscadores, resultados opuestos. Esa es la huella de un veredicto de confianza y autoridad disparado por un fallo técnico — no de un problema aislado de calidad de contenido o de velocidad.

La causa raíz: el bug lo desplegamos nosotros (confianza de en torno al 80%)

Aquí viene la parte que la mayoría de los post-mortems corporativos enterraría. El detonante fue nuestro propio despliegue.

Entre el 13 y el 18 de abril estábamos modificando nuestro módulo de productos digitales — un nuevo controlador de descargas, un arreglo del “duplicate slug on install”, un botón de descarga renderizado en servidor. En algún punto de ese trabajo, la generación de URLs de producto empezó a lanzar la excepción Invalid product vars de PrestaShop (en classes/Link.php). Nuestros logs de excepciones muestran la correlación con la hora exacta:

El momento no pudo ser peor. Acabábamos de despegar en la “luna de miel” de sitio joven — en torno a 4,000–5,400 impresiones al día, aproximadamente en la posición 10, a principios de abril. Justo cuando Google nos estaba evaluando con más dureza. Y en esa ventana, Googlebot se topaba con ~1,000 enlaces internos de producto rotos al día. Para un rastreador, un grafo de enlaces internos que de repente apunta a URLs de producto rotas durante el pico de evaluación es una señal fuerte de “este sitio acaba de degradarse”.

Hablamos de ~80% de confianza y no de certeza porque todo cayó en una ventana genuinamente ruidosa — la core update ya terminada, una spam update, el fin de la luna de miel y caídas recurrentes de servidor y base de datos por nuestra parte (mediados de marzo, 14–16 de abril y de nuevo en junio). Cualquiera de ellas agrava un golpe a la confianza. Pero solo el recuento de errores de Link.php encaja día a día con el precipicio. El veredicto honesto: un detonante técnico autoinfligido, estallando en el contexto de un sitio joven, de baja autoridad, justo después de una core update.

La categoría que de verdad explica un −95%: “Rastreada: actualmente sin indexar”

Si te llevas una sola lección de diagnóstico de todo esto, que sea esta. En el informe de cobertura del índice de Search Console, la categoría que importa no es “404” ni “5xx”. Es “Rastreada: actualmente sin indexar” — unas 22,800 URLs.

Un matiz honesto, porque revisamos nuestro propio historial: esta categoría no se “infló” la noche del desplome. La vimos por primera vez en febrero de 2025, tocó techo cerca de 60k y desde entonces se ha ido vaciando lentamente hasta ~22.8k. El precipicio nocturno en sí fue una degradación de posiciones de páginas que siguieron indexadas — impresiones diarias de ~5,400 en la posición ~10 que cayeron a 161 al día siguiente, en la posición 27. La categoría “rastreada, sin indexar” no es el mecanismo de la caída nocturna; es donde el veredicto de confianza a largo plazo se hace visible. Verificamos que una muestra de esas 22.8k páginas devuelve 200, index,follow, self-canonical y con contenido sólido. Google rastreó decenas de miles de páginas técnicamente limpias y decidió no indexarlas.

Recuperación, parte 1: dejar la parte técnica de verdad limpia

No puedes pedirle a Google que reevalúe un sitio que sigue tropezando con errores. Así que la fase uno fue higiene implacable — cada defecto técnico corregible, corregido y verificado en producción, no solo “desplegado” (la categoría de confianza de la siguiente sección es un problema aparte, no técnico):

• El detonante de Link.php: corregido lo primero — 0 errores desde mayo, los productos renderizan HTML 200 completo.
• 404: separados los 404 genuinos de los slugs renombrados; los slugs antiguos con 301 hacia los canonicals actuales (un solo salto, localizado).
• URLs de facetas: combinaciones válidas en 200 + noindex,follow, las obsoletas en 301 — las personas filtran, los rastreadores no se ahogan.
• 5xx: un fatal de autoload entre idiomas por un desajuste de mayúsculas, corregido con un mecanismo de seguridad.
• Cadenas de redirección: reducidas a un único salto, resueltas en el momento de emitirse.
• Datos estructurados: exactamente un brand por producto y longitud de descripción limitada (los dos errores que de verdad nos costaban resultados enriquecidos).
• Assets: eliminado el cache-busting ?v= por archivo para que funcione el combinado y minificado nativo de PrestaShop.
• Jerarquía de encabezados: un solo <h1> por página, H1 → H2 → H3 limpios.

Recuperación, parte 2: no relanzar el rastreo sobre un desastre — el “freeze gate”

Esta es la disciplina que la mayoría de las historias de recuperación se salta. Antes de volver a enviar nada a Google, tratamos el sitemap y el pipeline de indexación como una compuerta: nada se propone para indexar si no está demostrablemente limpio.

• El sitemap se regenera y cada URL se verifica de forma independiente — 200, index,follow, self-canonical, hreflang correcto, schema válido. El nuestro se estabilizó en 4,952 URLs en seis idiomas.
• La cola de indexación solo envía URLs que son canonicals indexables en este momento, con una comprobación por URL en el instante del envío — no una manguera abierta a ciegas.

Auditar cada URL del sitemap a través de esa comprobación destapó tres bugs que habrían desperdiciado en silencio todo el re-rastreo: a nuestro registro interno de páginas le faltaban 918 URLs del sitemap — incluido el conjunto completo de documentación de 882 URLs; tres páginas de FAQ estaban marcadas noindex por error debido a una fila de asociación de tienda ausente; y las entradas del blog se desviaban a noindex por un clasificador que casaba palabras clave de soporte antes que la ruta del blog. Exigimos un resultado de cero bloqueadas — cada una de las 4,952 URLs superando la comprobación — antes de dar la compuerta por cerrada.

La lección: recuperar la confianza significa que lo siguiente que vea Google tiene que ser impecable. Otra ronda de “por favor, indexad nuestras páginas rotas” solo cava el hoyo más hondo.

Sobre qué alertamos ahora

El fallo fue invisible durante días porque nada gritó. Lo que monitorizamos ahora:

• Alertas de excepciones de clase crítica sobre Link.php / slug fallido del dispatcher — cualquier pico nos avisa al instante, en lugar de una lectura semanal de logs.
• Tendencia de estadísticas de rastreo de GSC + Bing revisada cada semana, lado a lado — la divergencia Bing/Google es nuestra señal de confianza más temprana.
• Watchdog de disponibilidad sobre el origen — nuestras caídas fueron parte de la herida, así que el uptime es ahora una métrica SEO de primera clase.
• Comprobación de paridad sitemap/registro — la salvaguarda que encontró las 918 ausentes se ejecuta de forma continua.

Lo que honestamente NO se ha recuperado (todavía)

Aquí es donde la mayoría de los posts de “cómo me recuperé” se vuelven deshonestos. Nosotros no.

• Las posiciones y el tráfico no han vuelto. La parte técnica está limpia y verificada, pero Google sigue negándose a indexar la mayor parte de lo que rastrea, y la posición sigue a la deriva en lugar de rebotar.
• El off-page es nuestro techo real. Nuestro perfil de dominios de referencia es escaso — el mismo contenido que Bing posiciona en el top 3, Google lo rechaza. Un sitio limpio con una validación externa débil es exactamente el aspecto de “rastreada, sin indexar”.
• Nuestros idiomas no ingleses son peso muerto. Generan impresiones pero casi ningún clic; solo el inglés y el polaco convierten de verdad. Escalar páginas traducidas automáticamente fue parte de la huella sobredimensionada, no un activo.
• El arreglo a partir de aquí no es técnico. Es autoridad y tiempo: señales reales de experiencia y conocimiento, enlaces ganados en el ecosistema PrestaShop, y dejar que un sitio limpio se demuestre a sí mismo cuando reabramos la indexación a través de la cola vigilada.

Publicamos esto ahora, a mitad de la recuperación, precisamente porque un post-mortem escrito tras una recuperación completa es un cuento de hadas sesgado por la supervivencia. Así es como se ve realmente desde dentro.

Si esto le está pasando a tu tienda PrestaShop

• Mira Bing. Si Bing posiciona tu contenido y Google no, deja de culpar al contenido y a la velocidad — es confianza, y probablemente lo disparó algo técnico.
• Repasa tu registro de despliegues contra tu gráfica de tráfico. Nuestra prueba definitiva fue un recuento de excepciones que encajaba con el precipicio al día exacto. La tuya podría serlo también.
• Lee las categorías de cobertura del índice, no solo la línea de tráfico. “Rastreada — sin indexar” a gran escala es una señal de calidad, no un bug que corregir.
• Corrige y verifica en producción — directo contra el origen, no “ya debería estar arreglado”.
• No relances el rastreo sobre un desastre. Demuestra que tu sitemap y tu conjunto de envío son impecables antes de pedirle a Google que vuelva a mirar.
• Después, paciencia y construir autoridad. No existe un arreglo de código para la confianza.

Si tu tienda muestra este mismo patrón — limpia en la superficie, ignorada por Google, bien en Bing — nuestra PrestaShop SEO Audit traza exactamente cuáles de estos modos de fallo te están afectando, dentro y fuera del sitio. Es el mismo proceso forense que aplicamos sobre nosotros mismos, más arriba.