How Blocked Resources Affect a HTTPS Migration

Blocked resources can have a negative impact on a HTTPS migration. Ensure your page resources are not blocked by your robots.txt file.

What are blocked resources?

Blocked resources are files such as CSS, Javascript, or images that are being blocked from Googlebot.

When you change from HTTP to HTTPS, it is particularly important that there are no blocked resources so Google can have a clean look at the entirety of your site.

Consequences of blocked resources

It is recommended by the Google webmaster guidelines that you not have page resources blocked.

To help Google fully understand your site’s content, allow all site assets that significantly affect page rendering to be crawled: for example, CSS and JavaScript files that affect the understanding of the pages. The Google indexing system renders a web page as the user would see it, including images, CSS, and JavaScript files.

When a webpage has blocked resources, Google does not get a complete picture of that webpage, which can affect your rankings negatively.

A good example of this would be a responsive web page. If Google can not see the CSS file that makes the page responsive, Google may not rank that page for mobile because it does not see the CSS that makes the webpage mobile friendly.

HTTPS specific consequences

The reason that blocked resources become even more of an issue during an HTTP to HTTPS switch is because Google will need the least restricted and most complete view of your site to facilitate the timely indexing of the secure version of your URLs.

There is also the matter of the reason why your resources are blocked in the first place. It is likely that there are instructions in your robots.txt file that are restricting Googlebot from crawling your resources. This is a good time to ensure that whatever is blocking your resources isn’t blocking other important things.

A big part of switching to HTTPS is knowing and updating your robots.txt file and making your website as accessible to Googlebot as possible.

How to find blocked resources

In Google search console there is a “Blocked Content report”.
Google search console blocked resources

The report has a graph that shows the amount of blocked content. On the first page of the report (shown above) you will see the Host name and the number of pages affected by the blocked content. In a typical setup, you will see the HTTP and the HTTPS version and the number of pages affected by blocked content.

If you click on the Host name (we will use https://example.com) you will now see the actual files that are blocked…

blocked resource detail

This page lists out each file that is being blocked, and if you click any of the listed files, you will go to yet another page which tells you the actual pages (URLs) that are being affected…

blocked resource page

If you click an individual page URL, you will see a pop up that highlights the steps you can take to resolve the issue…

blocked resource options
Follow the steps provided to unblock the resource.

The steps to do so are generally:

  1. Find a blocked resource (we did that above using Google search console)
  2. Confirm that the resource is indeed blocked (using the robots.txt tool in Google search console)
  3. Find the line (instruction) in the robots.txt file that is blocking the resource
  4. Update the instruction to allow Googlebot access to the file

Improve your site in the eyes of Google

There is an enormous opportunity to improve your SEO when you switch to HTTPS.

Google will basically recrawl your entire site in a very short time, leading to a timely and total reindexation of all your webpages.

This means that any improvements made to your pages will be found quickly and those improvements will make it to the Google index in a timely manner.

Since blocked resources are against the Google webmaster guidelines, the optimization benefits of unblocking them are well worth the effort. Unblocking resources prior to an HTTPS switch will ensure that Google will quickly notice and act on your optimized pages.

See more of our HTTPS articles

^Back to Top