¿Por qué mi web sigue mostrando la versión antigua?

Tu sitio está bien. La copia que hay delante es vieja.

Publicar escribe una versión nueva de la página en tu origen, es decir el servidor o el bucket de almacenamiento del que tu hosting lee de verdad. Nada en ese paso promete que tus visitantes estén hablando con tu origen. Entre los dos hay tu navegador, normalmente una red de distribución de contenidos, a veces un service worker que instaló tu framework y de vez en cuando un proxy en la propia red del visitante. Cada uno guarda una copia y una regla sobre cuánto tiempo confiar en ella, y cada uno responderá a una petición sin preguntarle a nadie.

La firma de este problema es la inconsistencia. Tú ves la página nueva y tu cliente no. Dos personas reciben versiones distintas de la misma dirección. Se arregla solo una hora más tarde sin ningún despliegue. Ese patrón merece aprenderse, porque un despliegue realmente roto está roto para todo el mundo a la vez: si a algunos les funciona, deja de leer el log de compilación y averigua quién está respondiendo a la petición. La regla que hay debajo de la primera es la que sorprende: muchas cachés no solo guardan una copia hasta que caduca, sino que siguen sirviendo la copia caducada mientras buscan una nueva por detrás. Caducada no significa fuera de uso, y así es como una página sobrevive a su propia vida útil con mucho margen.

Localiza la capa antes de arreglar nada

Cada paso descarta una caché, en el orden que menos te cuesta. Baja por la lista y párate en el primero que muestre la página nueva: esa es tu respuesta, y la solución es purgar en esa capa, no otro despliegue.

1. Ábrela en una ventana privada. Si ahí aparece la versión nueva, la copia vieja solo estaba en tu propio navegador y ningún visitante se vio afectado. Recarga forzada en tu ventana normal y has terminado. Es el resultado más frecuente y el paso que más se salta, y por eso el susto suele durar más que el fallo.
2. Añade un parámetro sin sentido. Carga la misma dirección con algo como ?x=1 al final. Casi todas las cachés compartidas lo tratan como otra URL y van al origen a buscarla, así que una página fresca aquí significa que tu origen es correcto y que algo entre tú y él sigue sirviendo la copia vieja bajo la dirección limpia.
3. Ábrela desde otra red. Un móvil con datos en lugar del wifi de la oficina. Una red de distribución de contenidos guarda copias separadas en ubicaciones separadas, así que esto distingue un borde desactualizado de algo que están recibiendo todos los visitantes, y es la única versión de la prueba que refleja lo que ve de verdad alguien de fuera.
4. Pregúntale directamente al origen. Consulta la página desde el panel de tu hosting, una vista previa de servidor o una petición dirigida al origen y no a la dirección pública. Si el origen está bien y la URL pública está mal, el problema vive por completo en la entrega, y nada en tu código ni en tu compilación lo va a mover.

Cuando sepas la capa, purga o invalida ahí y repite el tercer paso desde una red que no controles. Confirmar el arreglo desde tu propia máquina es como la gente acaba convencida de que una purga funcionó cuando no lo hizo.

La versión de esto que nos costó una hora

Alojamos páginas de nuestros propios clientes, así que este problema es nuestro y no solo de quien nos lee. El 11 de septiembre de 2026 encontramos una página que habíamos retirado y que seguía sirviéndose a quien la abriera, cincuenta y dos minutos después de la retirada. Todo lo que podíamos ver de nuestro lado era correcto: el archivo ya no estaba en el almacenamiento y nuestros propios registros decían que la página estaba despublicada. La red de distribución de contenidos que había delante estaba configurada para seguir respondiendo con su última copia buena hasta un día entero mientras revalidaba por detrás, así que borrado describía nuestro almacenamiento y no decía nada de lo que recibía un visitante. Lo arreglamos en dos sitios a propósito: en la configuración de la red, para que no sirva copias caducadas en absoluto, y en las propias instrucciones de caché de la página, de modo que el límite ya no dependa de un ajuste que un backend reconstruido restauraría en silencio a su valor por defecto.

La regla que sacamos de ahí es la parte transferible: publicado, actualizado y borrado son afirmaciones sobre tu origen. Lo que recibe un visitante es un hecho aparte, y la única manera honesta de conocerlo es pedir la página como lo haría un desconocido. La misma capa cambió además lo que podíamos medir. Las visitas a las páginas que alojamos se registran como un mínimo y no como un total, porque una petición respondida en el borde nunca llega al origen que cuenta, y mientras estuvo activo el servicio de copias caducadas, las peticiones de refresco de caché de nuestra propia red eran la mayor parte de lo que contenía ese contador, hasta que las excluimos por nombre. Una caché no solo cambia lo que ve la gente. Cambia lo que puedes demostrar sobre lo que vieron.

También cambió cómo escribimos las dos operaciones. Publicar sube el archivo primero y lo registra después, porque el orden inverso registra una página viva mientras no se sirve nada. Despublicar borra el archivo primero y marca el registro después, porque el orden inverso registra una página como retirada mientras sigue en pie. Cuando falla la segunda mitad, el estado que reportamos queda equivocado en la dirección en la que es seguro equivocarse. Preguntarse qué fallo preferirías tener es la mayor parte de lo que significa llevar una web con cuidado, y es la misma disciplina que construimos en AgentCeres, el AI Growth Officer de agentceres.com: un equipo de especialistas redacta las páginas, las publicaciones y la comunicación, y el trabajo que sale hacia fuera espera por defecto la aprobación de una persona. Si acabas de publicar un sitio por primera vez, las comprobaciones de ¿debería usar IA para crear mi web? son la otra mitad de esta página.