robots.txt bloquea CSS y JavaScript: por qué Google ve tu web rota

Respuesta corta: si tu robots.txt bloquea CSS y JavaScript (carpetas como /wp-content/themes/, /wp-content/plugins/ o directamente los ficheros .css y .js), Google puede leer el HTML pero no cargar los estilos ni los scripts, así que ve tu web desmaquetada o a medias. Quita esas reglas, deja bloqueado solo /wp-admin/ (con excepción de admin-ajax.php) y compruébalo con la Inspección de URLs de Search Console.

Esta guía es parte de Mi web no aparece en Google: las causas técnicas.

Por qué Google necesita tus CSS y JavaScript

Hace años, Google leía solo el HTML. Ahora renderiza las páginas casi como un navegador: descarga las hojas de estilo, ejecuta el JavaScript y mira el resultado. Con eso decide, entre otras cosas, si la página se ve bien en el móvil, qué contenido es visible y qué texto aparece solo después de cargar los scripts.

Si el robots.txt le prohíbe descargar esos ficheros, Google renderiza una página sin estilos y, en webs que montan contenido con JavaScript (constructores visuales, sliders, pestañas, tiendas), sin parte del contenido. Google lo dice claramente en su documentación sobre robots.txt: no bloquees los recursos que necesita para entender la página.

No es que te «penalice». Es que valora lo que ve, y lo que ve está roto.

Por qué pasa: los robots.txt heredados

Este problema casi siempre viene de un robots.txt antiguo. Durante años circuló por blogs y foros una plantilla «optimizada» para WordPress que bloqueaba todo lo que no fuera contenido:

User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/
Disallow: /wp-content/cache/
Disallow: /*.js$
Disallow: /*.css$

Tenía sentido cuando Google no renderizaba. Hoy cada una de esas líneas, salvo la primera, puede impedir que Google cargue algo que necesita. Otros orígenes habituales:

• Un plugin de seguridad o de «optimización SEO» que reescribe el robots.txt.
• Un robots.txt copiado de otra web o de un tema premium.
• Reglas para frenar bots que, sin querer, también afectan a Googlebot (por ejemplo, un grupo User-agent: Googlebot con más bloqueos que el de *).
• Bloqueos de /assets/ o /static/ en webs que no son WordPress.

Cómo saber si tu robots.txt bloquea CSS y JavaScript

Lee tu robots.txt

Abre https://tudominio.com/robots.txt y busca cualquier Disallow que afecte a:

• /wp-content/themes/ o /wp-content/plugins/
• /wp-content/ entero
• /wp-includes/ (aquí está jQuery y otros scripts que cargan muchos temas)
• Patrones como /*.css, /*.js, /*?ver=
• Carpetas tipo /assets/, /static/, /dist/

Recuerda cómo lo lee Google: si existe un grupo User-agent: Googlebot, solo aplica ese; si no, el de *. Dentro del grupo, gana la regla más larga que coincide con la URL y, a igualdad, gana Allow.

Compruébalo con una URL concreta

Abre el código fuente de tu portada, copia la URL de la hoja de estilos del tema (algo como /wp-content/themes/tu-tema/style.css?ver=1.2) y pregúntate: ¿alguna regla del robots.txt la bloquea? Si tienes dudas, el informe de robots.txt de Search Console (Ajustes → robots.txt) te enseña la versión que ha leído Google, y Screaming Frog tiene una opción para probar URLs contra un robots.txt (Configuración → robots.txt, con las reglas personalizadas).

Mira cómo te ve Google

En Search Console, inspecciona la portada y pulsa «Probar URL publicada». Después, «Ver página probada»:

1. Pestaña «Captura de pantalla»: si ves la web sin estilos, en una columna con letras en Times New Roman, ahí lo tienes.
2. Pestaña «Más información» → «Recursos de la página»: lista los recursos que no se han podido cargar y el motivo. Los que ponen «Bloqueado por robots.txt» son los que tienes que liberar.

No todos los recursos bloqueados importan. Si lo que falla es un script de un tercero (un chat, un píxel de publicidad), no lo controlas y no suele afectar al contenido. Lo que importa es si tu robots.txt bloquea CSS o JS de tu propio dominio.

Cómo arreglarlo paso a paso

1. Haz una copia del robots.txt actual antes de tocarlo.
2. Localiza dónde se genera. En WordPress puede ser un fichero físico en la raíz (/robots.txt en el servidor), el robots.txt virtual de WordPress, o el editor de Rank Math (Ajustes generales → Editar robots.txt) o de Yoast (Herramientas → Editor de archivos). Si existe el fichero físico, manda sobre el virtual.
3. Quita los bloqueos de /wp-content/, /wp-includes/, temas, plugins y extensiones .css/.js.
4. Deja un robots.txt mínimo:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

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

1. Si tienes un grupo específico para Googlebot, revísalo igual, o elimínalo si no tiene una razón clara.
2. Si de verdad necesitas bloquear una carpeta de /wp-content/ (por ejemplo, ficheros privados de un plugin), bloquea esa ruta concreta y no la carpeta padre. Y recuerda que el robots.txt no protege nada: lo privado se protege en el servidor.
3. Purga la caché del CDN si el robots.txt pasa por él.
4. En Search Console, vuelve a «Probar URL publicada» y comprueba que la captura sale bien y que ya no hay recursos propios bloqueados. Google relee el robots.txt con frecuencia (normalmente en menos de un día); en el informe de robots.txt puedes pedir que lo vuelva a leer.

Errores habituales

• Bloquear /wp-includes/ «porque es del sistema». Ahí están scripts que usa el frontal de muchos temas.
• Usar el robots.txt para ocultar cosas. Es un fichero público: cualquiera puede leerlo y ver justo lo que intentas esconder. Para lo privado, contraseña o permisos en el servidor.
• Bloquear /*? para quitar parámetros. Bloquea también las hojas de estilo con ?ver=. Para los parámetros de filtros, mejor canonical o noindex.
• Pasarse de frenada y bloquear /. Un Disallow: / deja a Google sin acceso a toda la web. Lo vemos en noindex, X-Robots-Tag y robots.txt.
• Que el robots.txt devuelva un error. Si /robots.txt responde 5xx, Google puede dejar de rastrear la web hasta que se arregle. Un 404 es aceptable (Google entiende que puede rastrear todo); un 500 o un 403 no.

Cómo evitar que vuelva

• Revisa el robots.txt al entregar cada web y después de instalar plugins de seguridad o de SEO.
• No copies robots.txt de otras webs. El mínimo de arriba vale para la gran mayoría de WordPress.
• Si trabajas con staging, que el robots.txt de staging no viaje a producción: es otro clásico.
• Incluye la comprobación de «Ver página probada» en tu checklist de publicación, junto con las de el sitemap.

Para agencias: robots.txt de muchas webs a la vez

En la auditoría SEO de cada web, Jeffrey comprueba si las reglas del robots.txt impiden a Google cargar las hojas de estilo y scripts típicos de temas y plugins, y lo marca como hallazgo para corregir. Si el robots.txt bloquea la web entera a Google, ya no es un hallazgo: es una alerta crítica, la misma que la del noindex, que llega a la agencia y a NexaTech a la vez.

Jeffrey también lee el robots.txt antes de rastrear cada web. Si durante tres rastreos seguidos el robots.txt no se puede leer (403, errores 5xx o fallos de red), abre un aviso, porque eso puede estar frenando a Google igual que a nosotros. Y en la ficha de cada web verás qué permite el robots.txt a Googlebot y a los bots de IA más conocidos (GPTBot, ClaudeBot, PerplexityBot, Google-Extended), para decidir con el cliente qué dejar pasar.

Preguntas frecuentes