Separar caché de origen
Comparé las cabeceras de una respuesta cacheada (HIT, 200) y de una no cacheada (MISS, 404). El origen estaba roto; la caché lo tapaba.
Caso real 02 · Incidencias · caché edge
404 invisibles: tres archivos caídos en origen y ocultos por la caché edge
Desde fuera todo respondía 200. Pero cualquier petición sin caché —otra región, un usuario nuevo o Googlebot— recibía un 404. Lo diagnostiqué leyendo cabeceras y lo arreglé sin convertir un fallo invisible en uno visible para todos.
Caso real, cliente anonimizado. El nombre del cliente, las personas y los datos internos se omiten por confidencialidad. Las cifras salen de logs, Search Console, GA4 y del propio código. Si un dato de negocio no se midió, no aparece.
3archivos de CPT recuperados
0deploys rehechos
1comando para el arreglo
1paso nuevo en el pipeline
Contexto
El punto de partida.
El sitio usa tipos de contenido personalizados con archivo propio: casos de cliente, integraciones y partners. Son páginas con mucho tráfico orgánico y enlazado interno.
Todo va detrás de una caché de página en el hosting y un CDN. Días después de un deploy, una comprobación rutinaria de esas URLs dio resultados distintos según desde dónde se pidieran.
Síntomas observados
- Desde el navegador habitual, las tres páginas de archivo respondían 200.
- Con una petición limpia o desde otra región, las mismas URLs devolvían 404.
- Las fichas individuales de esos tipos de contenido estaban en riesgo por el mismo motivo.
Diagnóstico
Hipótesis descartadas antes de tocar nada.
Lo que parecía obvio y no era. Descartar bien ahorra días de trabajo en la dirección equivocada.
Un 404 cacheado en el CDN
Las cabeceras de la respuesta 404 marcaban MISS y DYNAMIC: venía del servidor, no de la caché.
Tipos de contenido desregistrados
wp post-type list los mostraba registrados y con has_archive activo.
Slugs cambiados en el deploy
Los rewrite slugs eran los mismos que antes del deploy.
Implementación
Qué hice, paso a paso.
Ir a las reglas de reescritura
wp rewrite list no contenía las reglas de esos archivos. El deploy había regenerado la opción rewrite_rules sin ellas.
Arreglar el origen
wp rewrite flush en modo soft (el servidor es Nginx, no hay .htaccess que regenerar).
Verificar sin caché
Comprobé 200 añadiendo una query string que salta la caché de página, antes de tocar la caché.
Purgar al final
Solo con el origen verificado purgué la caché. Al revés, la copia buena del edge se habría sustituido por el 404 para todos.
Que no vuelva a pasar
Propuse el flush como último paso fijo del pipeline de deploy.
Bajo el capó
El código que importa.
Fragmentos simplificados y sin datos del cliente, para que se vea el enfoque técnico real.
# Respuesta desde caché
curl -sI https://www.example.com/case-studies/ | grep -iE 'HTTP/|cache'
# HTTP/2 200 · x-cache: HIT
# Misma URL saltando la caché de página
curl -sI 'https://www.example.com/case-studies/?nocache=1' | grep -iE 'HTTP/|cache'
# HTTP/2 404 · x-cache: MISS · cf-cache-status: DYNAMICwp post-type list --fields=name,has_archive | grep -E 'case|integration|partner'
wp rewrite list | grep -E 'case-studies|integrations|partners' # vacío
wp rewrite flush
wp rewrite list | grep -c case-studies # reglas de vueltaDecisiones
Por qué así y no de otra forma.
No rehacer el deploy
El código era correcto. El problema era un estado (reglas de reescritura) y se corrige regenerando ese estado.
Orden: origen → verificación → purga
Purgar primero habría servido el 404 a todo el tráfico, Googlebot incluido.
Resultado
Qué cambió, con datos verificables.
| Indicador | Antes | Después | Contexto |
|---|---|---|---|
| Archivos de CPT | 3 en 404 | 3 en 200 | casos, integraciones, partners |
| Respuesta en MISS | 404 | 200 | verificado saltando la caché |
| Deploy rehecho | — | No hizo falta | se corrigió el estado |
| Pipeline | Sin flush | Flush propuesto | tras cada deploy |
Cómo lo validé
- Cabeceras MISS con 200 en las tres URLs.
- Fichas individuales comprobadas por muestreo.
- Purga y nueva comprobación con HIT.
Lo que me llevo
El orden importa: primero origen, luego verificar sin caché y solo al final purgar. Invertirlo convierte un fallo invisible en uno visible para todos.
- WordPress
- Tipos de contenido a medida
- WP-CLI
- Nginx
- CDN
Para tu web
Checklist rápida: ¿te está pasando lo mismo?
- ¿Compruebas las URLs clave sin caché tras cada deploy?
- ¿Sabes leer HIT/MISS en tus cabeceras?
- ¿Tu deploy regenera las reglas de reescritura?
- ¿Purgas solo después de verificar el origen?
¿Te suena?
¿Tienes un problema parecido?
Preguntas frecuentes
Dudas habituales sobre este tipo de problema.
¿Por qué veía mi web bien si daba 404?
Porque la caché seguía sirviendo una copia anterior. Las peticiones que no encuentran caché llegan al servidor y ahí aparece el error real.
¿Purgar la caché lo arregla todo?
No. Si el origen está roto, purgar hace que el error llegue a todo el mundo.
¿Cómo compruebo una URL sin caché?
Con un parámetro de consulta único o revisando las cabeceras de caché de la respuesta.
WordPress · SEO técnico · IA
Cuéntame qué está frenando tu web.
Si ya tienes un WordPress en producción, reviso el contexto y te digo con honestidad si lo que necesitas es desarrollo, SEO técnico, rendimiento o automatización.
