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.
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7">
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.

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

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.

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.

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.