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

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 largely controlled by CSS
• Content rendered via JavaScript, such as product listings, reviews, or dynamic text, may be invisible to Google
• 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. Crawling these files helps Google understand the quality and legitimacy of your site and determines whether the page experience is worth ranking highly. If Googlebot cannot see the page the way users see it, it has less reason to rank it well.

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.

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. 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, or confirm the CDN is not blocking Googlebot via its own access rules. This is a common missed step when the robots.txt fix does not resolve the error.

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

Using the URL Inspection Tool

1. Log in to your Google Search Console account
2. Select your property
3. Paste one of your page URLs into the URL Inspection bar at the top and press Enter
4. Click Test Live URL to trigger a fresh crawl of the page
5. Once the test completes, click View Tested Page
6. Switch to the More Info tab
7. 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.

Under Indexing → Pages in Search Console, check 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. The URL Inspection tool gives you the definitive answer per page.

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 offenders:

• W3 Total Cache: Has a “Minify” and “Browser Cache” tab that can add Disallow rules to protect its own cache directories. Check Performance > General Settings and look for any robots.txt management options.
• WP Super Cache: Generates a robotstxt configuration under its settings. Go to Settings > WP Super Cache > Advanced and check whether there is a custom robots.txt section. Remove any blocking rules there.
• Rank Math: Has its own robots.txt editor that takes precedence over the physical file in some configurations. 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:

1. Copy the full URL of a blocked resource from the URL Inspection tool’s Page Resources tab.
2. 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.
3. Check your .htaccess file (Apache) or nginx configuration for rules that restrict access to wp-content paths. Your host may also have security rules applied at the server level that you cannot see in cPanel or Plesk.

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

Password-protected 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.