Fixing the Base64 to Image 404 Error

Recently I got quite a shock when I moved over to the newly released Ahrefs Webmaster Tool. I had a spike in 404 errors that I had never seen before. I did some digging came to the conclusion that this was somehow connected to the Base64 to image code.

When I checked out the page source I found that the Base64 to image code was embedded with every image on my website as below in every image I had.


I suspected that this code was resulting in the Ahrefs Webmaster Tool picking up 404 errors in the weekly scans I had begun running.

I previously used a few other tools for scans, but none of them had identified the 404 error I’m sharing with you here.

So, how bad did it look? Yeah… Pretty bad.

Ahrefs scan looking really bad

The number of 404 errors that were connected to a missing GIF file was alarming to say the least. There was one for every URL with an image on the site.

The report from Ahrefs was showing that all URLs on the site had a string ending in “/images/gif” that were being picked up by the bots.

Ahrefs screenshot showing Image 404 Error

What did the Base64 to image 404 code look like?

After some research, it seemed to turn out that the code below was generating URLs that had nothing behind them.

This was where I thought the 404 errors were coming in, through the code on the page source that looked like this:

Page Source Code showing the Base64 Code

As I went to check what the /images/gif URL on each page pointed to all I found was a big pile of nothing. Not even a single pixel, which is what the Base64 code is supposed to point to.

Checking the page source for the 404 error page there was nothing that remotely suggested the existence of a GIF image. Even though there was an image in the footer, which on other pages triggered the “GIF” using CRTL+F.

After a few days of scraping page after page on various sites including Stack Overflow, I eventually came upon a solution. It was a long bow, but it seemed to have done the trick.

It appeared to be that the Jetpack had introduced some conflicts.

The Solution

The solution was really simple, but it was nowhere near obvious at the time. It had nothing to to with the Base64 code per se as I assumed.

What did I do? Turned off Jetpack’s Lazy Load for this particular build.

The culprit – turn off Jetpack Lazy Load

After all, with CloudFlare running through the SiteGround plan I have, how much more would Lazy Load really do for me when I’ve got Polish, Mirage and Rocket Loader running?

How do things look now? Much better. There are some areas that I need to continue to fix. That’s all a matter of time now.

Better looking scan results

It’s amazing to think that just one setting on a single plugin can cause so many issues. The Base64 to image assumption has been put to rest for now.