Tu web carga bien en el navegador. Los usuarios ven el contenido completo, las animaciones funcionan, el menú se despliega sin problemas. Pero cuando revisas Google Search Console, ves páginas indexadas con contenido parcial o descripciones que no tienen sentido. Algunas URLs aparecen como “rastreadas pero no indexadas” sin una razón clara. Si esto te suena familiar, el problema puede estar en un archivo que probablemente tocaste una sola vez y después olvidaste: robots.txt.
Muchos desarrolladores bloquean rutas como /js/, /_next/, /assets/ o /static/ en robots.txt pensando que están ahorrando crawl budget. La lógica parece sensata: si Google no necesita descargar esos archivos, el crawler puede enfocarse en el contenido real. Pero esa lógica ignora completamente cómo funciona el rendering de Googlebot. Cuando bloqueas JavaScript en robots.txt, Google no puede ejecutar tu código, no puede renderizar tu contenido y termina indexando páginas vacías. No es un error sutil. Es un bloqueo total que pasa desapercibido porque tu web sigue funcionando perfectamente para los usuarios.
Cómo Googlebot renderiza tu web
Para entender por qué bloquear JavaScript en robots.txt es tan destructivo, necesitas saber qué hace Googlebot cuando visita tu página. El proceso tiene dos fases y la mayoría de los desarrolladores solo conocen la primera.
La primera fase es el crawling básico. Googlebot descarga el HTML de tu URL. Si tu web usa un framework moderno como React, Next.js, Vue o Angular, ese HTML inicial es casi vacío. Contiene un contenedor raíz (como <div id="root"></div>) y una lista de etiquetas <script> que apuntan a tus archivos JavaScript. En esta fase, Google no ve tu contenido. Ve un esqueleto sin carne.
La segunda fase es el rendering. Google pone tu página en una cola de procesamiento donde un navegador Chromium ejecuta tu JavaScript. Es en esta fase donde React construye el DOM, donde Next.js hidrata el contenido y donde tu web pasa de ser un HTML vacío a ser la interfaz que el usuario ve. Si Googlebot no puede descargar tus archivos JavaScript porque robots.txt se lo prohíbe, esta fase nunca ocurre. Google indexa el HTML vacío de la primera fase y punto.
La documentación de Google lo dice explícitamente: si bloqueas recursos como CSS y JavaScript, Google no puede entender tus páginas. No es una recomendación opcional. Es un requisito técnico para que el rendering funcione.
El error que cometen miles de desarrolladores
El patrón es siempre el mismo. Un desarrollador abre robots.txt, ve que no tiene nada configurado y piensa: “Voy a ser eficiente. Voy a bloquear los recursos estáticos para que Google solo rastree las páginas importantes.” Escribe algo así:
User-agent: *
Disallow: /js/
Disallow: /_next/static/
Disallow: /assets/
Disallow: /static/
Disallow: /node_modules/Cada una de esas líneas tiene sentido individualmente. Los archivos en /js/ no son páginas que necesiten indexarse. Los archivos en /_next/static/ son bundles de JavaScript. Los de /assets/ son imágenes y hojas de estilo. ¿Por qué dejar que Google pierda el tiempo descargando esos archivos?
La razón es que Googlebot necesita esos archivos para renderizar la página. Si bloqueas /_next/static/, Google no puede descargar el JavaScript que Next.js usa para hidratar el contenido. Si bloqueas /js/, Google no puede ejecutar la lógica que construye el DOM. El resultado es que cada página de tu sitio se indexa como el HTML vacío que el servidor envía antes de que JavaScript se ejecute.
El caso específico de Next.js
Next.js organiza sus archivos estáticos dentro de /_next/static/. Esta carpeta contiene los chunks de JavaScript, las hojas de estilos compiladas y los datos de las páginas en formato JSON. Todo el rendering de tu aplicación depende de esos archivos.
Cuando alguien bloquea /_next/ en robots.txt, cada página de un sitio Next.js se indexa con el HTML de server-side rendering (si está habilitado) pero sin la hidratación del cliente. Si tu página depende de contenido que se carga después de la hidratación (fetch de datos, componentes dinámicos, contenido condicional), Google no ve ese contenido.
El problema es peor si usas getStaticProps o getServerSideProps. Los datos se inyectan como un script JSON dentro del HTML, pero los componentes que interpretan esos datos y los renderizan como contenido visible están en los chunks de JavaScript que bloqueaste. Google ve los datos crudos en formato JSON pero no puede renderizarlos como la interfaz que tú diseñaste.
El caso de SPAs con React o Vue
En una SPA clásica con React o Vue sin server-side rendering, la situación es aún más grave. El HTML que el servidor envía no tiene contenido renderizado. Es solo el contenedor raíz y los scripts. Si bloqueas JavaScript, Google literalmente no tiene nada que indexar.
He visto sitios completos de React donde el robots.txt bloqueaba toda la carpeta /static/js/. El propietario no entendía por qué su sitio no aparecía en Google después de tres meses. Cuando revisé robots.txt, el problema fue inmediato: Googlebot recibía un HTML vacío y no tenía forma de ejecutar el JavaScript para construir el contenido.
Cómo auditar tu robots.txt paso a paso
Antes de tocar nada, necesitas verificar exactamente qué está bloqueando tu robots.txt y cómo afecta a Googlebot. No asumas que tu configuración está bien solo porque no la tocaste recientemente. Muchos plugins, servicios de hosting y configuraciones de CDN modifican robots.txt sin avisarte.
Paso 1: Lee tu robots.txt actual
Abre tu navegador y ve a tudominio.com/robots.txt. Lee cada línea. Cada regla Disallow es una ruta que Googlebot no puede acceder. Si ves rutas que contienen /js/, /static/, /_next/, /assets/ o cualquier patrón que coincida con donde tu framework guarda JavaScript, tienes un problema.
Paso 2: Usa la herramienta de prueba de robots.txt en Search Console
Google Search Console tiene una herramienta específica para probar robots.txt. Ve a la sección de configuración y busca “Probador de robots.txt”. Pega tu contenido actual y prueba las URLs de tus archivos JavaScript. La herramienta te dice si Googlebot puede o no acceder a cada URL. Si tus archivos JS devuelven “Bloqueado”, confirma el problema.
Paso 3: Inspecciona URLs con la herramienta de inspección
Toma una de tus páginas principales y úsala en la herramienta de inspección de URLs de Search Console. En los resultados, busca la sección de “Recursos de la página”. Ahí verás una lista de todos los recursos que Googlebot intentó cargar para renderizar tu página. Si los archivos JavaScript aparecen como “bloqueado por robots.txt”, ya tienes la confirmación definitiva.
Paso 4: Prueba el rendering con la herramienta de prueba en vivo
Después de hacer cambios, usa la prueba en vivo para verificar que Googlebot puede renderizar tu página correctamente. La diferencia entre la versión renderizada y la versión del HTML crudo te muestra exactamente qué contenido se pierde cuando JavaScript no se ejecuta.
Cómo configurar robots.txt correctamente según tu framework
Para Next.js
Next.js no genera un robots.txt automáticamente a menos que crees uno en la carpeta /public/. Tu robots.txt debe permitir el acceso a todo excepto las rutas que no quieres indexar:
User-agent: *
Allow: /_next/static/
Allow: /_next/data/
Disallow: /api/
Sitemap: https://tudominio.com/sitemap.xmlLa línea clave es Allow: /_next/static/. Esa regla le dice a Googlebot que puede descargar todos los archivos JavaScript, CSS y datos dentro de esa carpeta. Si no la incluyes y tienes otras reglas Disallow que coincidan con patrones de esa ruta, Googlebot podría bloquear esos recursos.
Para sitios con React (CRA o Vite)
Si tu sitio React despliega archivos estáticos en una carpeta como /static/ o /assets/, asegúrate de que robots.txt no bloquee esas rutas:
User-agent: *
Allow: /static/
Allow: /assets/
Disallow: /admin/
Disallow: /api/
Sitemap: https://tudominio.com/sitemap.xmlPara sitios con Vue o Nuxt
Nuxt genera sus archivos en /_nuxt/. Si bloqueas esa ruta, el rendering del cliente no funciona:
User-agent: *
Allow: /_nuxt/
Disallow: /api/
Sitemap: https://tudominio.com/sitemap.xmlLa regla general
Si no estás seguro de si una ruta contiene archivos que tu framework necesita para funcionar, no la bloquees. Es mejor permitir el acceso de más que bloquear recursos críticos. El crawl budget que “ahorras” bloqueando archivos JS no compensa el daño de indexar páginas vacías.
Errores comunes que encuentro en auditorías
Bloquear todo excepto las páginas HTML
Algunos desarrolladores configuran robots.txt con una regla general que bloquea todo lo que no termine en .html. Eso funciona para sitios estáticos puros, pero destruye cualquier sitio que use JavaScript para renderizar contenido.
Copiar robots.txt de otro sitio sin entenderlo
He visto sitios de WordPress con robots.txt copiados de sitios Next.js y viceversa. Cada framework tiene sus propias rutas de recursos estáticos. Lo que funciona para uno puede bloquear recursos críticos de otro.
Usar plugins que generan robots.txt automáticamente
En WordPress, plugins como Yoast SEO o RankMath generan robots.txt. Si tienes un plugin de rendimiento que bloquea acceso a archivos de JavaScript para “mejorar la seguridad”, ese bloqueo puede terminar en robots.txt sin que lo sepas. Revisa la configuración de cada plugin que toque acceso a archivos.
No verificar después de migrar de framework
Si migraste de un framework estático (como Hugo o Jekyll) a uno basado en JavaScript (como Next.js o Nuxt), tu robots.txt anterior probablemente bloqueaba rutas de recursos que ahora son esenciales. La migración debería incluir una revisión de robots.txt, pero muchos equipos se olvidan de este paso.
Cómo verificar que tu corrección funcionó
Después de actualizar robots.txt, el proceso de verificación tiene tres pasos.
Primero, usa la herramienta de prueba de robots.txt en Search Console para confirmar que tus archivos JavaScript ya no están bloqueados. Cada ruta que corregiste debería mostrar “Permitido” en la prueba.
Segundo, envía una de tus páginas principales a la cola de rastreo desde la herramienta de inspección de URLs. Espera a que Googlebot vuelva a rastrearla y revisa la sección de recursos. Todos los archivos JavaScript deberían mostrar “Cargado correctamente” en lugar de “Bloqueado”.
Tercero, compara la versión renderizada con el HTML crudo. Si la versión renderizada ahora muestra tu contenido completo, la corrección funcionó. Si ves diferencias significativas entre lo que el usuario ve y lo que Google renderiza, hay otros problemas además de robots.txt.
Checklist de auditoría completa
- Descarga tu robots.txt y revisa cada regla
DisallowyAllow - Identifica las rutas donde tu framework almacena JavaScript (
/_next/static/,/_nuxt/,/static/js/) - Usa la herramienta de prueba de robots.txt en Search Console para verificar el acceso
- Inspecciona URLs principales y revisa la sección de recursos bloqueados
- Corrige las reglas que bloquean JavaScript y CSS críticos
- Prueba en vivo después de los cambios
- Monitorea la cobertura de indexación durante las semanas siguientes
Conclusión
Bloquear JavaScript en robots.txt es uno de los errores de SEO técnico más comunes y más dañinos que existen. No genera errores visibles en tu sitio, no afecta a los usuarios y no aparece en ninguna alerta de tu panel de administración. Pero para Google, es como si tu web no tuviera contenido.
La corrección es directa: revisa tu robots.txt, elimina las reglas que bloquean tus archivos JavaScript y CSS, y verifica con Search Console que Googlebot puede renderizar tus páginas correctamente. No necesitas ser un experto en SEO para hacerlo. Solo necesitas saber dónde buscar y qué buscar.
Tu web puede ser técnicamente perfecta y seguir siendo invisible para Google si un simple archivo de texto le prohíbe al crawler acceder a los recursos que necesita para entender tu contenido. Revisar robots.txt debería ser el primer paso de cualquier auditoría de SEO técnico, no el último.
Preguntas frecuentes
¿Cómo sé si robots.txt está bloqueando mi JavaScript?
Abre Google Search Console, ve a la herramienta de inspección de URLs e introduce una de tus páginas principales. En los resultados busca la sección “Recursos de la página”. Si algún archivo JavaScript aparece como “bloqueado por robots.txt”, ya tienes la respuesta. También puedes abrir tu robots.txt directamente en tudominio.com/robots.txt y buscar rutas que coincidan con donde tu framework guarda JavaScript.
¿Puedo bloquear solo ciertos archivos JavaScript y permitir otros?
Técnicamente sí, pero no es recomendable. Los frameworks modernos generan decenas o cientos de chunks de JavaScript que se cargan de forma dependiente. Bloquear algunos puede romper la carga de otros. La regla más segura es permitir el acceso a toda la carpeta de recursos estáticos de tu framework y bloquear solo las rutas que genuinamente no quieres que Google rastree, como endpoints de API.
¿Mi sitio WordPress tiene este problema si uso plugins de caché?
Depende del plugin. Algunos plugins de caché y rendimiento agregan reglas a robots.txt para bloquear acceso a archivos internos. Si tu plugin tiene una opción relacionada con robots.txt o acceso a archivos, revísala. Los plugins de seguridad como Wordfence o Sucuri también pueden modificar robots.txt sin que lo notes.
¿Cuánto tiempo tarda Google en procesar el cambio después de corregir robots.txt?
Google vuelve a leer robots.txt en cada rastreo de tu sitio, generalmente cada pocos días. Una vez que la nueva configuración permite el acceso a tus archivos JavaScript, el rendering comienza a funcionar en el próximo rastreo completo. La reindexación puede tomar entre una y tres semanas dependiendo del tamaño de tu sitio y la frecuencia de rastreo.
¿Es mejor no tener robots.txt que tener uno mal configurado?
En la mayoría de los casos, sí. Si no tienes robots.txt, Googlebot asume que puede acceder a todo tu sitio. Eso puede no ser ideal para crawl budget, pero al menos no bloquea recursos críticos. Un robots.txt mal configurado es peor que no tener ninguno porque activamente impide que Google renderice tu contenido. Si no estás seguro de cómo configurarlo, es mejor eliminarlo temporalmente hasta que puedas crear uno correcto.
