Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Administrador Medios Frontend

Los cambios CSS no aparecen después de actualizar WordPress

Descubre por qué WordPress no muestra un cambio CSS revisando el archivo cargado, cascada, recursos generados, CDN y despliegue.

El navegador puede recibir una hoja antigua, cargar un archivo distinto del editado o encontrar la regla nueva pero perderla en la cascada. Vaciar todas las cachés puede alterar temporalmente el resultado sin identificar qué capa estaba obsoleta.

Empieza demostrando qué archivo y qué regla utiliza realmente el navegador.

Inspecciona el elemento afectado

Abre Estilos y Calculado en las herramientas del navegador. Localiza la propiedad esperada y comprueba si la regla está ausente, tachada, sobrescrita o marcada como inválida.

Clasifica:
regla ausente -> recurso equivocado u obsoleto
regla tachada -> cascada, especificidad u orden
propiedad ignorada -> sintaxis o contexto inválido
clase cambiada -> selector incorrecto
estilo inline gana -> sobrescritura en el origen

Compara una visita anónima y otra con sesión, porque el administrador puede evitar la caché.

Abre directamente la hoja cargada

Desde Red o Estilos, abre la URL del CSS y busca una marca única de la modificación. Anota URL, versión, ETag, Last-Modified, cabeceras y estado de CDN.

Si la regla no existe, confirma que editaste el tema hijo, tema o plugin activo y el document root correcto. La fecha del archivo no basta: quizá se sirve una versión generada o minimizada.

Corrige la cascada con precisión

Compara especificidad, orden, media queries, condiciones @supports y uso de !important. Prefiere un selector acotado al componente y un orden de carga correcto.

.site-header .primary-navigation {
  background: #123456;
}

Evita cadenas de !important. Revisa también la sintaxis anterior: una llave sin cerrar puede invalidar las declaraciones posteriores.

Identifica CSS generado

Constructores visuales, temas de bloques y optimizadores pueden compilar ajustes de la base de datos en uploads o carpetas de caché. Editar ese archivo solo dura hasta la siguiente regeneración.

Modifica la fuente real, usa la herramienta de regeneración y revisa permisos y espacio. Nunca borres toda la carpeta de subidas para limpiar recursos generados.

Versiona correctamente los estilos

Encola los estilos propios con una versión del lanzamiento o del tema:

wp_enqueue_style(
    'site-child',
    get_stylesheet_uri(),
    array(),
    wp_get_theme()->get( 'Version' )
);

Si la cabecera del tema no cambia, usa una versión controlada por el despliegue. Una cadena aleatoria en cada petición destruye la utilidad de la caché.

Sigue todas las capas de caché

Navegador, service worker, WordPress, hosting, proxy y CDN pueden conservar CSS. Lee las cabeceras y purga el recurso exacto después de publicar una nueva versión.

Cloudflare puede ignorar parámetros según la clave configurada. Comprueba esa política y prueba con la caché caliente, otro navegador y otra red. Una recarga forzada aislada no es suficiente.

Comprueba despliegue, nodos y permisos

Verifica que el archivo llegó a todos los nodos y que el enlace de la versión activa apunta al build correcto. Un balanceador puede alternar recursos nuevos y antiguos.

Compara checksums y publica de forma atómica. No edites producción si el siguiente despliegue sobrescribirá el cambio.

Revisa service workers

Una PWA puede servir CSS antiguo al margen de la caché normal. Inspecciona Application > Service Workers y Cache Storage, incluyendo ámbito y versión.

Actualiza el manifiesto y la estrategia de activación mediante el plugin o build. No pidas a todos los visitantes que desregistren manualmente: despliega un worker que retire cachés antiguas con seguridad.

Prueba variantes de idioma y estado

Los plugins multilingües pueden generar CSS separado o clases diferentes. Un archivo RTL o una plantilla traducida puede sobrescribir el principal.

Inspecciona inglés, español y catalán, reconstruye la caché de cada idioma y prueba breakpoints, foco, modo oscuro, barra de administración y etiquetas largas. Mantén contraste y funcionamiento con zoom.

Verifica el resultado duradero

Comprueba el CSS con visitante anónimo, CDN caliente y navegadores representativos. Vigila 404 de recursos después de publicar.

La reparación estable no depende de que cada usuario vacíe su navegador: hace que todos reciban una versión identificable y coherente de la hoja correcta.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia