Cuidado con webpkgcache.com: por qué esta opción puede “romper” tu WordPress y cómo solucionarlo (o dejarlo bien configurado)

Si alguna vez hiciste clic desde Google a una página tuya y se abrió una URL rarísima del tipo:

https://tusitio-com.webpkgcache.com/doc/-/s/tusitio.com/tu-pagina/

…y encima se veía todo sin estilos, sin fuentes, sin JavaScript o “desarmado”, es muy probable que te haya afectado Signed Exchanges (SXG), una optimización que ciertos CDNs (como Cloudflare) pueden activar para acelerar el “click desde Google”.
SXG no es la caché clásica de Google: es un paquete firmado de tu HTML que Google prefetch e intenta servir antes de que el usuario haga clic, pero desde un dominio de Google, por eso aparece webpkgcache.com. Si tu sitio no está listo para ese contexto “cross-origin”, se rompe.

Este post te explica qué es SXG, por qué afecta especialmente a WordPress, cómo apagarlo si no lo querés y, si decidís mantenerlo, cómo blindar tu sitio para que no vuelva a pasar.

Cuidado con webpkgcache.com PUEDE ROMPER TU SITIO EN GOOGLE

Qué es SXG y qué no es

• Qué es: un mecanismo por el cual Google (y otros clientes) puede precargar y mostrar tu página de forma casi instantánea, entregando un archivo firmado que representa tu HTML. La URL que ves en el navegador puede ser la tuya, pero los recursos se resuelven en el contexto del dominio webpkgcache.com que hospeda ese paquete.
• Qué NO es:
  • No es el viejo botón “En caché”.
  • No es la caché de tu CDN o tu plugin.
  • No es una copia estática que podés borrar con un “purge” propio; depende del índice de Google y de SXG.
  • ES UN DOLOR DE CABEZA PARA LIMPIAR TUS RESULTADOS EN GOOGLE

Por qué SXG puede “romper” un WordPress

WordPress vive de temas y plugins que cargan CSS, JS y fuentes desde /wp-content/… y /wp-includes/…. Cuando tu HTML se abre “empaquetado” por SXG:

• Fuentes sin CORS: si tus .woff2 no permiten uso cross-origin, el navegador las bloquea. Resultado: tipografías por defecto o “saltos” de layout.
• Preloads sin crossorigin: si hacés preload de fuentes o scripts sin el atributo crossorigin, fallan bajo SXG.
• Rutas relativas/absolutas mal resueltas: algunos temas usan rutas implícitas o combinan assets en base al host de origen; bajo webpkgcache.com no coinciden y se pierden.
• Bloqueos en robots.txt: si por error bloqueás /wp-content/*.css o /wp-includes/*.js, Google no ve los estilos al “probar” tu página y SXG solo agrava la percepción de “rota”.
• CSP estricta: una Content Security Policy muy cerrada puede impedir cargar recursos cuando el HTML viene desde dominio ajeno.
• HTML que varía por cookies: si el HTML cambia según cookie/user-agent, el paquete SXG puede no coincidir con lo que espera el usuario.
• Optimizadores agresivos: Rocket Loader, concatenaciones o inyecciones tardías de JS/CSS pueden fallar si el documento no se entrega directo desde tu host.

Cómo identificar que te golpeó SXG

• La URL que se abre al hacer clic en Google incluye webpkgcache.com y un patrón /doc/-/s/.
• La página se ve sin CSS/JS o con la fuente caída.
• En DevTools (Network) ves que los primeros requests vienen desde el dominio webpkgcache.com.
• Al recargar con la URL canónica (tu dominio) “todo vuelve a la normalidad”.

Solución inmediata: desactivar SXG en tu CDN

Si no querés lidiar con esto o no necesitás la micro-mejora de LCP/CTR que a veces aporta SXG, lo más simple es apagarlo:

1. Entrá a tu panel de CDN.
2. Buscá la sección de Speed/Optimization.
3. En Other (u “Otros”), desactivá Automatic Signed Exchanges (SXG).
4. Purga toda la caché del CDN.
5. En Search Console, usá Inspección de URL → Solicitar indexación para las páginas afectadas (home y las más visitadas).
6. Reenvía tu sitemap.xml para acelerar el re-rastreo.

Qué esperar: los resultados que hoy muestran webpkgcache.com se irán limpiando a medida que Google vuelva a rastrear. No hay un tiempo fijo; suele mejorar en horas/días si pedís reindexación.

Alternativa pro: mantener SXG… pero bien configurado

Si preferís quedarte con SXG porque te da buen rendimiento, blindá tu WordPress y tu servidor con estos pasos.

Habilitar CORS para fuentes

En .htaccess (Apache) agrega:

# CORS + policies para fuentes
<IfModule mod_headers.c>
  <FilesMatch "\.(woff2?|ttf|otf|eot)$">
    Header set Access-Control-Allow-Origin "*"
    Header set Access-Control-Allow-Methods "GET, OPTIONS"
    Header set Cross-Origin-Resource-Policy "cross-origin"
  </FilesMatch>
</IfModule>

Esto permite que las fuentes se carguen aunque el HTML llegue “desde otro origen” (webpkgcache).

Usar crossorigin en preloads críticos

En tu tema (cabecera), asegurate de que los preloads tengan crossorigin:

<link rel="preload" as="font" href="/wp-content/themes/tu-tema/assets/fonts/poppins-latin.woff2" type="font/woff2" crossorigin>
<link rel="preconnect" href="https://tudominio.com" crossorigin>

Si haces preload de módulos JS, aplica lo mismo.

No bloquear CSS/JS en robots.txt

Un robots.txt amistoso:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Allow: /wp-content/*.css
Allow: /wp-content/*.js
Allow: /wp-includes/*.css
Allow: /wp-includes/*.js

Sitemap: https://tudominio.com/sitemap_index.xml

Revisar políticas CSP

Si usás Content-Security-Policy, incluí las fuentes/host necesarios:

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' 'unsafe-inline' 'unsafe-eval' https:;
  style-src 'self' 'unsafe-inline' https:;
  font-src 'self' data: https:;
  connect-src 'self' https:;
  img-src 'self' data: https:;

Ajustá según tus proveedores (CDN, analytics, mapas, etc.).

Evitar HTML que varía por cookies

• Desactiva “variantes por cookie” para usuarios anónimos en tu caché.
• Si necesitás personalización, usá ESI/fragments o hazlo client-side después de pintar el HTML.

Cuidado con optimizadores agresivos

• Rocket Loader y combinaciones extremas de JS pueden romper SXG. Probá en staging con SXG activo.
• No “aplanes” todo el CSS en un inline gigante si luego depende de rutas relativas.

Checklist específico para WordPress

Añadir crossorigin y preloads desde functions.php

// Añadir hint de preconnect
add_filter('wp_resource_hints', function($hints, $relation_type){
  if ('preconnect' === $relation_type) {
    $hints[] = array('href' => home_url(), 'crossorigin' => true);
  }
  return $hints;
}, 10, 2);

// Forzar atributo crossorigin en estilos críticos
add_filter('style_loader_tag', function($html, $handle, $href, $media){
  if (strpos($href, '.woff') !== false || strpos($href, '.woff2') !== false) {
    $html = str_replace('<link ', '<link crossorigin ', $html);
  }
  return $html;
}, 10, 4);

// Helper para imprimir preload de fuentes
function tema_preload_fuente($path){
  echo '<link rel="preload" as="font" type="font/woff2" href="'.esc_url($path).'" crossorigin>' . "\n";
}

En tu header.php

<?php 
// Ejemplo de preload (ajusta rutas reales)
tema_preload_fuente( get_stylesheet_directory_uri() . '/assets/fonts/poppins-latin.woff2' );
?>

Asegurar rutas limpias

Evita concatenar rutas con $_SERVER['HTTP_HOST']. Usa funciones nativas:

get_stylesheet_directory_uri(); // para assets del tema hijo
get_template_directory_uri();   // para assets del tema padre
plugins_url('path/archivo.js', __FILE__); // dentro de plugins

Lazy-load y galerías pesadas

SXG no “arregla” páginas con 100 imágenes en la home. Usa loading="lazy" y paginación/carruseles. Si usas plugins de optimización de imágenes, verifica que el primer viewport tenga fetchpriority="high" en la imagen hero.

Revisa el robots.txt del plugin SEO

Algunos plugins meten reglas de más. Asegúrate de no bloquear /wp-content/ ni /wp-includes/.

Evitar el “texto con espacios” a mano

Ese “E J E M P L O D E T Í T U L O” con espacios rompe accesibilidad y puede generar snippets raros. Logra el efecto con CSS:

.titulo-espaciado { letter-spacing: .12em; }

¿Y si no quiero que Google muestre “caché” nunca?

Si te molesta cualquier tipo de copia mostrada por el buscador, agrega el encabezado:

<IfModule mod_headers.c>
  Header set X-Robots-Tag "noarchive"
</IfModule>

Esto no desactiva SXG, pero evita que se muestre el clásico “En caché” cuando Google lo ofrece.
Recuerda: SXG es otro mecanismo; si lo dejás activado, igual necesitas las medidas anteriores.

Pasos de verificación después de un cambio

1. Purgá caché del CDN.
2. Inspección de URL en Search Console → Solicitar indexación de las páginas clave.
3. Revisá “Último rastreo” para confirmar que Google ya vio la versión correcta.
4. Probá el flujo “desde Google”: buscá tu marca/página, hacé clic y verificá que no aparezca webpkgcache.com (si apagaste SXG) o que todo cargue perfecto (si lo mantuviste).
5. Monitorea Core Web Vitals con y sin SXG; a veces el beneficio de SXG no compensa el riesgo si tus assets son complejos.

Preguntas frecuentes

¿Puedo “borrar” un enlace webpkgcache.com específico?
No directamente. No es tu servidor. Lo que podés hacer es desactivar SXG, forzar reindexación y, como medida adicional, usar la herramienta de remoción de contenido desactualizado de Google sobre esa URL si el contenido del paquete ya no coincide.

¿Cuánto tarda en desaparecer?
Depende del re-rastreo. Con Solicitud de indexación + sitemap reenviado suele mejorar en horas/días. No hay SLA.

¿SXG mejora siempre el SEO?
No “sube posiciones” por sí mismo. Puede bajar el tiempo hasta el primer render al venir precargado, lo que mejora UX y a veces CTR. Pero si rompe el sitio, el perjuicio es mayor.

¿Qué pasa con Cloudflare APO, Rocket Loader y compañía?
Son independientes. APO puede convivir con SXG; Rocket Loader a veces interfiere con JS críticos en SXG. Probar en staging es clave.

¿Y si mi sitio no es WordPress?
Las causas son análogas: fuentes sin CORS, preloads sin crossorigin, robots que bloquean CSS/JS, CSP estricta, variación por cookies. Los remedios son los mismos.

¿Puedo tener SXG activo solo en algunas páginas?
Depende del proveedor. Como regla, es “todo o nada”. Si necesitas granularidad, evalúa reglas de respuesta que desactiven SXG en rutas problemáticas (cuando el proveedor lo permite).

Conclusión y plan de acción

• Si priorizás estabilidad: desactiva SXG en tu CDN, purga caché, reindexa en Search Console y listo.
• Si querés rendimiento con SXG: añade CORS para fuentes, usa crossorigin en preloads, revisa robots.txt y CSP, y testea que tu tema/plugins no dependan de rutas u orígenes implícitos.
• Siempre: usa Search Console para comprobar cómo “ve” Google tu página; una sola línea mal en robots.txt o una fuente sin CORS puede desarmar la experiencia.

Con estos ajustes, tu WordPress (o cualquier CMS) no volverá a quebrarse cuando Google intente ser “demasiado rápido”. Y si preferís la tranquilidad, apagar SXG es totalmente válido: el verdadero rendimiento viene de optimizar bien tus assets, no de un atajo que, si no se configura, termina saliendo caro.