How to Fix “Googlebot cannot access CSS and JS files” Error in WordPress

Last modified: August 23, 2026

FAQ

The “Googlebot Cannot Access CSS and JS Files” warning in Google Search Console means Google’s crawler is reaching your pages but being blocked from loading the stylesheets and scripts they depend on. Without those files, Googlebot renders a broken version of your pages — missing layout, fonts, and any content that loads via JavaScript — which affects how Google evaluates your content quality, mobile-friendliness, and page experience signals.

This is different from a soft 404 or a crawl error. The page itself is accessible; the problem is that Googlebot sees a stripped-down version of it that does not match what users actually get. That gap matters because Google’s ranking systems increasingly evaluate the rendered experience, not just the raw HTML text.

The most common cause is a single overly broad Disallow rule in your robots.txt file, typically Disallow: /wp-content/, added at some point during a plugin install or copied from a template configuration. This one line blocks Googlebot from loading every theme stylesheet, every plugin script, and every uploaded media file on your site. The fix takes under five minutes once you know where to look.

Here is what a problematic robots.txt looks like versus a safe one:

# PROBLEMATIC -- blocks CSS and JS files
User-agent: *
Disallow: /wp-content/
Disallow: /wp-includes/

# SAFE -- only blocks wp-admin (except admin-ajax.php)
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://yourdomain.com/sitemap_index.xml

This guide covers how to find that rule, remove it safely, what to check when the robots.txt fix alone does not resolve the error, and how to verify the fix using Google Search Console’s URL Inspection and robots.txt testing tools.

Why This Error Appears and How to Fix It

Start with the robots.txt check. It resolves this error in the large majority of cases. Use Google Search Console’s built-in robots.txt tester (under Settings > robots.txt in your GSC property) to check your live file and see exactly which paths are currently blocked before making any changes.

#	Name	Image
1	Editing the robots.txt File		More Info

* This button will show the rest of the post and open up an offer from a vendor

Why does Google Need Access to CSS and JS Files?

Google does not just scan your page text. Its crawler renders your pages the same way a browser would. That means Googlebot needs to load your CSS files (which control layout, fonts, and visual design) and JavaScript files (which power interactive elements, dynamic content, and client-side rendering) to understand what users actually see when they visit.

When Googlebot cannot load these files, several problems follow:

Your page may appear broken or have a completely different layout than intended
Google may not recognize that your site is mobile-friendly, since responsive design is controlled by CSS media queries — if it cannot load the CSS, it cannot evaluate the mobile layout
Content rendered via JavaScript — product listings, reviews, dynamically loaded text, single-page application content — may be completely invisible to Google even if users see it fine in their browser
Google cannot measure Core Web Vitals accurately for your page if it cannot render it. Blocked CSS causes layout shift calculations to fail; blocked JS prevents Largest Contentful Paint from loading. This can drag down your Page Experience signals even when your actual site performance is fine.
Google cannot verify that the visual experience matches the text content, which is a signal it uses to detect cloaking and spam

Google has been clear since 2014 that blocking CSS and JS resources works against you. If Googlebot cannot see the page the way users see it, it has less reason to rank it well — and for JavaScript-heavy WordPress sites using page builders or product plugins, the gap between what Googlebot sees and what users see can be substantial.

How to Allow Access to your CSS and JS Files to Google

The cause of this error is almost always a Disallow rule in your robots.txt file that is blocking your WordPress content directory. Here is how to find and fix it:

Step 1: Check your robots.txt file

Visit https://yourdomain.com/robots.txt in your browser. Look for any of these lines:

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

Any of these will block Googlebot from loading your CSS and JS files. A broad Disallow: /wp-content/ is the most common culprit — it blocks every theme stylesheet, plugin script, and media file on your site in one line.

Check with Google’s robots.txt tester: In Google Search Console, go to Settings > Crawling > robots.txt (or search for “robots.txt” in the GSC navigation). Google’s tester shows your live robots.txt and lets you test specific URLs against it. Paste a CSS file URL (e.g. https://yourdomain.com/wp-content/themes/yourtheme/style.css) and click Test — it will tell you if that URL is blocked or allowed.

Step 2: Check WordPress Reading Settings

Go to Settings > Reading in your WordPress admin. If the box that says “Discourage search engines from indexing this site” is checked, WordPress is adding a blanket noindex directive and blocking crawlers from wp-content. Uncheck it and save.

Step 3: Update robots.txt to remove blocking rules

A safe, minimal robots.txt for a WordPress site:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://yourdomain.com/sitemap_index.xml

No broad content directory blocks. Remove any Disallow lines that reference /wp-content/, /wp-includes/, or specific theme or plugin folders.

If your site uses a CDN: Check whether your CSS and JS files are served from a different subdomain or third-party CDN URL (e.g. cdn.yourdomain.com or a Cloudflare subdomain). Your main domain’s robots.txt does not control what Googlebot can access on CDN subdomains. If assets are served from a separate CDN domain, check that domain’s robots.txt separately. On Cloudflare specifically, check that your WAF (Web Application Firewall) rules are not blocking Googlebot’s user agent from accessing static asset paths — this is a common missed step when the robots.txt fix alone does not resolve the error.

Finding Blocked Resources in Google Search Console

Google Search Console tells you exactly which files Googlebot cannot access. Here is how to check:

Using the URL Inspection Tool

Log in to your Google Search Console account
Select your property
Paste one of your page URLs into the URL Inspection bar at the top and press Enter
Click Test Live URL to trigger a fresh crawl of the page
Once the test completes, click View Tested Page
Switch to the More Info tab
Scroll to Page Resources. Any file with a red “Not loaded” status or a 403 HTTP error is being blocked.

If you see multiple blocked resources all coming from the same path — for example, every file under /wp-content/themes/ shows as blocked — that confirms the problem is a single broad robots.txt rule rather than a per-file server permission issue.

Checking the Coverage report for context:

Under Indexing > Pages in Search Console, scroll down to the “Why pages aren’t indexed” section. Pages that show “Crawled, currently not indexed” on a site that should be ranking may be suffering from rendering problems caused by blocked resources. Pages that show “Discovered, currently not indexed” have not been crawled at all — for those, the URL Inspection tool lets you request indexing directly and gives a reason for the non-crawl. The “Page resources” tab after a live test gives the definitive per-resource answer.

Editing the robots.txt File

Once you have confirmed which rules to remove, here are four ways to edit your robots.txt file:

Option 1: Yoast SEO File Editor (recommended)

Install or open Yoast SEO in your WordPress dashboard
Go to Yoast SEO > Tools > File Editor
Find the robots.txt section at the top of the page
Remove any Disallow lines covering /wp-content/, /wp-includes/, or specific plugin or theme directories
Click Save Changes to robots.txt

This is the safest editing method because Yoast validates the file format before saving and you do not need FTP access or command-line tools.

Option 2: FTP/SFTP

Connect to your server using an FTP client (FileZilla is free and widely used)
Navigate to your site’s root directory, the same folder that contains wp-config.php
Download a copy of robots.txt as a backup before changing anything
Open the file in a text editor, remove the offending Disallow lines, and save
Upload the edited file back to the same root directory

Option 3: Hosting Control Panel

Most hosts provide a File Manager in cPanel or Plesk. Navigate to the root of your domain and edit robots.txt directly in the browser-based editor without any FTP software.

Option 4: WP-CLI (for command-line access)

# View current robots.txt:
cat /path/to/your/site/robots.txt
# Edit with nano, vim, or your preferred editor:
nano /path/to/your/site/robots.txt

After making changes: Return to Google Search Console and use the URL Inspection tool to run Test Live URL on one of the affected pages. Check the Page Resources tab again — blocked resources should now show as “Loaded.” Then use the Request Indexing button in the URL Inspection tool on your most important pages to fast-track the re-crawl. The warning in your Coverage report may take 2 to 4 weeks to fully clear as Googlebot works through its recrawl queue for your domain.

More Info

Elementor Hosting

When the robots.txt Fix Does Not Work: Less Common Causes

If you have removed the offending Disallow rules from your robots.txt and Googlebot is still reporting blocked CSS and JS files, the blocking is coming from somewhere else. Here are the next places to check.

Caching plugins that manage their own robots.txt

Some caching plugins write directly to your robots.txt file or manage it through their own settings, which can override changes you make in Yoast or via FTP. The main cases:

W3 Total Cache: Has a “Minify” and “Browser Cache” tab that can add Disallow rules. Check Performance > General Settings for any robots.txt management options.
WP Super Cache: Go to Settings > WP Super Cache > Advanced and check for a custom robots.txt section. Remove any blocking rules there.
Rank Math: Has its own robots.txt editor. Check Rank Math > General Settings > robots.txt if Rank Math is installed.

After adjusting any caching plugin’s robots.txt settings, always clear the cache and then verify the live /robots.txt file in your browser to confirm the blocking rules are gone.

Server-level blocks (nginx or Apache configuration)

A robots.txt file only controls what Googlebot is allowed to request, not what your server will actually return. If your server configuration includes a rule that returns a 403 Forbidden response for requests to /wp-content/, Googlebot will report the files as blocked even if your robots.txt allows them.

Signs this is your problem: the URL Inspection tool shows “Not loaded — HTTP error 403” (not “Blocked by robots.txt”). A 403 is a server response, not a robots.txt directive.

To check for server-level blocks:

Copy the full URL of a blocked resource from the URL Inspection tool’s Page Resources tab.
Open it in a private browser window. If it returns a 403 or blank page rather than loading the file, the block is at the server level.
Check your .htaccess file (Apache) or nginx configuration for rules that restrict access to wp-content paths.

Contact your host if you cannot locate the source of a 403 on your CSS or JS files. Server-level blocks are usually security rules they added intentionally and can be adjusted with the right scope defined.

Cloudflare WAF rules

If your site is behind Cloudflare, a WAF (Web Application Firewall) rule might be blocking Googlebot’s IP addresses or user agent from fetching CSS and JS files. Check your Cloudflare dashboard under Security > WAF > Custom Rules and look for any rules that apply to static asset paths or that challenge all traffic without a Googlebot exception. Googlebot’s verified user agent is Googlebot/2.1 — any rule that blocks it from /wp-content/ paths will reproduce this error even with a clean robots.txt.

Password-protected or staging environments

If your site is behind HTTP basic authentication (a username/password prompt before the page loads), Googlebot cannot access any resources at all. This is common for staging environments that were promoted to production without removing the authentication layer. Check your hosting panel for password protection settings on the root domain, and remove them if found on your live site. In cPanel, this is under Security > Password Protect Directories.

Final Word: How to Fix “Googlebot cannot access CSS and JS files” Error in WordPress

In most cases, this error traces back to a single overly broad Disallow: /wp-content/ rule in your robots.txt file. Remove it, use Google’s built-in robots.txt tester in Search Console to verify the fix, and Googlebot will be able to crawl your CSS and JS files on the next pass.

If the error persists after fixing robots.txt, work through the possibilities in order: caching plugins with their own robots.txt management, then server-level 403 blocks (check with a direct URL in an incognito browser), then Cloudflare WAF rules, then authentication layers on the root domain. The URL Inspection tool’s Page Resources tab tells you whether a resource is “Blocked by robots.txt” or returns an HTTP error — that distinction tells you which path to follow.

After making any fix, use the Request Indexing button in the URL Inspection tool on your most important pages to request a fresh crawl rather than waiting for Google’s normal recrawl schedule. Rankings typically improve within a few weeks once Google can fully render your pages — the fix itself takes minutes, and the ranking recovery follows over the next crawl cycle. For most sites, the warning disappears from the Coverage report within 2 to 4 weeks.

Recap: