CSS and JS blocked in robots.txt
Whether robots.txt lets Googlebot fetch the CSS and JavaScript the pages need. Google renders a page before it judges it, and blocked assets mean it sees the page unstyled.
Google does not judge a page from its HTML alone: it renders the page the way a browser does, with its stylesheets and scripts, and only then decides what the page contains and whether it works on a phone. If robots.txt forbids Googlebot from fetching those files, it sees an unstyled page or one whose JavaScript content never appears. A layout that looks fine to visitors can then fail mobile-friendliness and lose content in the index.
How SiteScan checks it
During the crawl the scanner collects the CSS and JavaScript files the pages load and tests each path against the rules in robots.txt that apply to Googlebot (its own group if there is one, otherwise User-agent: *). Green "Allowed" means none is blocked; red "Disallowed" gives the number of blocked files. The row appears only when robots.txt exists and assets were found.
How to fix
- Remove broad rules that cover asset folders, such as
Disallow: /wp-includes/,Disallow: /assets/,Disallow: /static/orDisallow: /_next/. - If a folder must stay closed, open the files explicitly in the same group:
Allow: /*.css$andAllow: /*.js$. - Then check a page with the URL Inspection tool in Google Search Console and look at the rendered screenshot.
Related: the robots.txt row and robots.txt and sitemaps.
See this check on your own site
Run a free scan: the report shows this row for your domain along with the other checks of the site audit.
More in “Indexing”
What SiteScan checks
TLS certificate
- TLS certificate expiry
- Outdated TLS versions (TLS 1.0/1.1)
- TLS certificate chain
- TLS certificate issuer
- Certificate signature algorithm
Domain registration
- Domain registration expiry
- Registered domain name
- Domain registrar
- Domain registration date
- Domain last updated date
- Domain status codes (EPP)
- Domain transfer lock
- Registrar abuse contact
- RDAP and WHOIS data source
Indexing
- robots.txt file
- CSS and JS blocked in robots.txt
- XML sitemap
- Sitemap index file
- Off-domain URLs in the sitemap
- Sitemap lastmod dates
- Broken URLs in the sitemap
- RSS and Atom feed
Addresses & redirects
Security headers
- HTTP security headers and grade
- Strict-Transport-Security (HSTS) header
- Content-Security-Policy (CSP) header
- X-Content-Type-Options: nosniff
- X-Frame-Options and clickjacking
- Referrer-Policy header
- Permissions-Policy header
- HSTS preload list
- CORS and cross-origin reads
- HTTP TRACE method
Delivery & reputation
- Cache-Control header for HTML
- ETag and Last-Modified revalidation
- HTTP/3 and QUIC support
- Server version disclosure in headers
- DNS blocklist (DNSBL) check
Internal links
Exposure
- Exposed sensitive files (.env, .git, backups)
- Directory listing enabled
- Public JavaScript source maps
- Exposed WordPress endpoints
Well-known files
- security.txt file
- llms.txt for AI assistants
- llms-full.txt file
- ads.txt authorized sellers file
- humans.txt file
- Well-known change-password URL
DNS & email
- MX records (mail servers)
- SPF record
- DMARC record and policy
- DNSSEC signing
- CAA record
- Nameserver redundancy
- IPv6 support (AAAA record)
- MTA-STS policy
- TLS-RPT reporting record
- BIMI record (brand logo in email)
- Wildcard DNS record
- Dangling CNAME and subdomain takeover
Privacy & consent
- Analytics and tracking scripts
- Cookie consent banner
- Privacy policy link
- Terms of service link
- Imprint (Impressum)
- Accessibility statement
Core Web Vitals
- Lighthouse performance score
- Largest Contentful Paint (LCP)
- Cumulative Layout Shift (CLS)
- Interaction to Next Paint (INP)
- CrUX field data vs lab data