The Internet Marketing Driver

  • GSQi Home
  • About Glenn Gabe
  • SEO Services
    • Algorithm Update Recovery
    • Technical SEO Audits
    • Website Redesigns and Site Migrations
    • SEO Training
  • Blog
    • Web Stories
  • Contact GSQi

Archives for October 2016

How To 301 Redirect Images During a Website Redesign or CMS Migration – The Most Forgotten Step When Changing URLs

October 19, 2016 By Glenn Gabe 2 Comments

Redirecting Images During a Website Redesign or CMS Migration

Website redesigns and CMS migrations can be challenging from an SEO standpoint. And that’s especially the case on large and complex websites, where there are a lot of moving parts. In those cases, business owners and webmasters need to be methodical and meticulous to avoid negative impact.

I’ve written a number of posts about migrations and redesigns over the years, based on helping many companies execute a website redesign, move to https, change domain names, or switch CMS platforms. That includes a recent case study about a site that moved images to a CDN, but forgot to implement redirects. You should definitely check out those posts if you are thinking about making big changes. I’ve provided a number of important points to consider before making the move.

Based on working on many redesigns and migrations, as well as speaking with many webmasters that have faced challenges when changing urls, there seems to be one item that keeps getting left behind. It’s an item that simply gets no love during a redesign or migration (since it’s easy to miss). And it can definitely end up impacting a site negatively when changing urls.

I’m referring to properly redirecting all images on the site when those urls will change.

A URL is a URL
Although many people don’t think of it this way, images reside at urls too (just like articles, posts, pdfs, etc.) And those images could have built up links, and could be driving traffic via image search. But when companies work on gathering the necessary intelligence before a migration goes live, images often get left in the dust. In this post, I’ll cover more about this phenomenon, how to gather the necessary intel, how to redirect the urls, and then how to check that everything is ok once the redirects are in place. Redirecting images is a step you should definitely add to your migration checklist, and it very well could help you avoid negative impact during your redesign or migration.

Image URL is still a URL

First, Google’s John Mueller has something to say:
Before we hop into the core part of this post, some of you might be wondering, “do we really need to redirect images too?” The simple answer is yes, you should! Again, those images could have built up links, could be driving traffic, and could be helping with social sites like Pinterest.

But hey, I get it. You want to hear a Googler explain it. No problem. John Mueller explained this during a webmaster hangout in August of this year. Here it is, at 57:29 in the video.

Cool? Now let’s talk about redirecting images. :)

URL Changes and Nailing The Redirection Plan (Including Images!)
Whenever urls change, you need to absolutely nail the redirection plan. That means 301 redirecting all old urls to their new counterparts on a one-to-one basis (when possible). That doesn’t mean redirecting all old urls to the homepage of the site, or to less or non-relevant urls. If you do that, Google can see those pages as soft 404s (as I documented in a previous post of mine). And if that happens, then the pages will ultimately be treated as 404s, and Google will remove them from the index. Not good, to say the least.

301 redirects seen as soft 404s

It’s also not optimal to skip the redirects altogether, which can result in 404s, dropped signals, and then forcing Google to find and re-index all of those images. And again, if the original image urls lose signals, then the new images have no guarantee of ranking where they did before (even if they get indexed at their new urls). And from an inbound link perspective, you’re going to lose those valuable links. Again, not good. You might also have some referral traffic leading to those images, which you will lose as well (as users hit a 404 page).

As you can see, you definitely want to make sure all images redirect to the new urls that contain those images. And again, that should be a one-to-one mapping. i.e. Redirect each old url to its new url. The way you handle this completely depends on the situation at hand. For example, if there’s a pattern to the url changes, then you can use mod_rewrite or ISAPI_Rewrite using regular expressions (depending on if you’re running Linux or Windows). Then a few lines of code can handle all of the redirects in one fell swoop.

If for some reason there’s not a pattern that you can leverage, then you might need to handle the redirects on a one-by-one basis. And if you have many image urls to redirect, speak with your developers about creating a custom solution for handling mass redirects. That might include creating a lookup table that can be referenced.

Regardless, do not simply let your images 404. There’s no reason to let links and traffic drop when you change urls.

How To Redirect Images During a Redesign or CMS Migration
Before a migration, I typically spend a lot of time gathering the necessary intelligence to make sure clients fully understand all of the urls that need to be redirected. That includes top landing pages from organic search, from referral traffic, urls that have built links, etc.

From an images standpoint, there are a few ways to find that data. I’ll cover several of those items next.

1. Crawl Your Site
If you want to get a feel for where all of your images are residing, then crawl your site! I use both DeepCrawl and Screaming Frog extensively and both will surface image data. Once you crawl your site completely, click the Images tab in Screaming Frog to view all images that were picked up during the crawl.

Image report in Screaming Frog

From a DeepCrawl standpoint, find the Resources report and then click “All Images”. Just like Screaming Frog, you will see a list of all images picked up during the crawl. You can export the report and then make sure the images are handled properly during the redesign or migration.

Image report in DeepCrawl

2. Analyze Inbound Links
Using tools like Majestic or ahrefs, you can find images that have built links. So fire up your favorite link analysis tool (mine is Majestic) and export all of your links. Then you can filter in Excel for image files, like .jpg, .gif, or .png. Then make sure those image urls are properly redirected.

Majestic stats for image url

3. Google Search Console (GSC) – Search Analytics Report
Head to GSC and fire up the search analytics report. Click the Pages group to list all pages yielding impressions and clicks in Google. Then click the “Search Type” dropdown, select “Filter by search type”, and then select “Image” from the dropdown. This will show you all pages showing up in image search.

Image Search Trending in GSC

Then export these urls to ensure they are redirected during the migration or redesign. But, those are just the urls of the webpages the images are included in. You still need to make sure all images are accounted for (the actual image urls).

Tip: You could also click the “Queries” group at this point to see all of the keywords that lead to those pages in image search, which can help identify the images that are ranking well. Once you identify all the images contained on those pages, make sure those images are properly redirected. This can help you avoid losing traffic from image search.

Gather and Dedupe:
At this point, you will have a boatload of image intel from your site. I recommend adding the list of urls to one worksheet in Excel and then deduping that list. Then you’ll have a final list of images and image urls to check.

Dedupe in Excel

How To Audit Image Redirects
Before a redesign or migration goes live, it’s important to perform all the necessary checks on the site in staging before you pull the trigger. Don’t wait until the site is pushed to production to start auditing the url changes. Google will already be crawling and indexing those new urls, and if redirects are not in place, you’re setting yourself up for disaster.

So, start by crawling those image urls in staging to ensure the proper redirects are set up! Take the deduped list and use a tool like DeepCrawl or Screaming Frog in list mode to crawl the old image files and the urls those images reside on, and make sure that the 301 redirection plan is perfect.

List Mode in Screaming Frog

Don’t Forget Redirect Chains
And as I’ve said many times before, just because a url 301 redirects doesn’t mean the destination url resolves properly! For example, what if your 301 leads to a 404, 500, etc?

That’s why it’s important to check redirect chains too. That will enable you to see if the redirects lead to 200s (which they should) or if they lead to non-200 header response codes. Again, there are times the redirect chain ends in a non-200 header response code, like a 404, 500, etc. That means your redirection plan is flawed and you can start leaking signals, rankings, and traffic. Not good.

Both Screaming Frog and DeepCrawl have a redirect chains report. Use it! Make sure those redirects actually lead to 200s. If not, you can pay dearly. Beware.

Redirect Chains Report in Screaming Frog

Monitor GSC for image traffic:
Once the redesign or migration goes live, then you should also monitor image search traffic via the Search Analytics report in GSC. Just like we checked before, you should use “Search Type” grouping, select “Filter by search type”, and then select “Image”. That will show you trending for clicks and impressions for images being surfaced in image search. If you see a drop when the redesign or migration went live, then go back through the process listed above to ensure all images are taken into account via the redirection plan.

Image search trending in GSC

Summary – Images need redirects too.
Again, redesigns and migrations have many moving parts. As I explained above, it’s critically important when changing urls to nail the redirection plan. And that includes images! So follow the steps I listed in this post and make sure you don’t leave your images in the dust. If you do, signals will be lost, you could lose valuable inbound links, and subsequent traffic. And that’s never a good thing.

GG

Filed Under: google, seo

UTF-8 BOM and SEO: How to find, clean, and fix an invisible character in your robots.txt file

October 2, 2016 By Glenn Gabe 11 Comments

UTF-8 BOM and SEO

I’ve written in the past about how a robots.txt file could look fine, but actually not be fine. For example, maybe you add your directives, a sitemap file or sitemap index file, and then upload it to your site. You think all is good, but you find that directives are not being adhered to, maybe a boatload of urls that are being crawled that shouldn’t be, etc. When that happens, it can have a big impact on SEO (especially on large-scale sites with many urls that should never be crawled).

So why does this sinister robots.txt problem happen? It often comes to down a single character. Literally. Sure, it’s an invisible character, but a character nonetheless. It’s called the UTF-8 BOM and I’m going to explain more about that in this post. Unfortunately, I’ve come across this issue many times during audits and while helping companies with technical SEO. It’s sinister, since it’s invisible. But the results are extremely visible (and can be alarming).

Below, I’ll cover what UTF-8 BOM is, how it can impact your robots.txt file, how to check for it, and then how to fix the problem. So, if your robots.txt file is bombing, and you are still scratching your head wondering what’s going on, then this post is for you.

What is UTF-8 BOM?
BOM stands for byte order mark and it’s used to indicate the byte order for a text stream. It’s an invisible character that’s located at the start of a file (and it’s essentially meaningless from an SEO perspective). Some programs will add the BOM to a text file, which again, can remain invisible to the person creating the text file. And the BOM can cause serious problems when Google tries to read the file. Actually, the UTF-8 BOM can make your robots.txt file, well, bomb… Sorry for the play on words here, but I couldn’t resist. :)

What can happen to a robots.txt file when UTF-8 BOM is present?
As mentioned above, when your robots.txt file contains the UTF-8 BOM, Google can choke on the file. And that means the first line (often user-agent), will be ignored. And when there’s no user-agent, all the other lines will return as errors (all of your directives). And when they are seen as errors, Google will ignore them. And if you’re trying to disallow key areas of your site, then that could end up as a huge SEO problem.

For example, here’s what a robots.txt file looks like in GSC when it contains UTF-8 BOM:
UTF8-BOM in robots.txt Tester in GSC

Needless to say, all of the directories that should be disallowed are not being disallowed. And that means many urls that shouldn’t be crawled are being crawled (and many are being indexed). This can lead to all sorts of nasty SEO problems. And that could include quality problems, as well, depending on what is being crawled and indexed.

How to identify UTF-8 BOM:
Right now, you might be sweating a little. Maybe you’ve seen problems with your robots.txt file and subsequent indexation, and you’re now wondering if UTF-8 BOM is the problem. Don’t worry, I’ll quickly walk you through how to check your robots.txt file now.

1. First, fire up GSC and use the robots.txt Tester. When you view the report, does it look like the screenshot above? Is the first line showing a red X next to it? If so, hover over the x and you might see a hint that says, “Syntax not understood”. If so, there’s a good chance you’ve got the UTF-8 BOM situation I’ve been explaining.

Syntax error when testing robots.txt file in GSC

2. Next, visit the W3C Internalization Checker. This tool will enable you to upload your robots.txt file and check for the presence of UTF-8 BOM.

3. Next, click the tab labeled “By File Upload”:
How to check robots.txt using W3C checker

4. Next, click “Choose File” and select your robots.txt file. Then click the “Check” button:
Choosing a robots.txt file to check for UTF-8 BOM

The tool will return the results, which will include a line about UTF-8 BOM. If you see that in the results, you know what the problem is (which is great). That’s the smoking gun.
W3C Checker Results for UTF-8 BOM

How to fix UTF-8 BOM in your robots.txt file:
Fixing the issue is pretty easy. I recommend using a text editor like Textpad to create your new robots.txt file. When saving the file, ensure that BOM is not selected (some text editor programs have an option for adding the BOM).

Checking for UTF-8 BOM in text editor

Also, make sure you’re not using a word processing application like Microsoft Word for creating your robots.txt file. I’ve seen that cause problems too. You should be using a pure text editor for creating your robots.txt file, .htaccess file, xml sitemaps, etc. I’m a big Textpad fan, but there are many others you can use as well.

Once you make the changes, then use the W3C internationalization tool to check the revised file. If the BOM doesn’t show up, you’re good to go. If it is, you are doing something wrong while creating the robots.txt file. Go back and start over using a pure text editor.

After you’ve fixed the problem, head back to GSC and to the robots.txt Tester. The tool enables you to submit a request to Google to retrieve your latest robots.txt file (after you upload the new one).

Submitting a new robots.txt file to GSC

If you’ve done everything correctly, the errors should be removed from the robots.txt Tester and your directives will now work (blocking directories and files that should not be crawled).

Side note: Blocking does not mean “remove from index” (usually):
If you’ve been experiencing robots.txt issues due to the UTF-8 BOM problem I’ve covered here, your work might not be done. If many pages have been indexed, then just blocking via robots.txt will not remove those pages from the index. Over time, Google can remove them, but I would try and get those undesirable urls out of Google’s index quickly.

For example, you could add the meta robots tag using “noindex” and submit an xml sitemap to Google that contains all of the urls that you want deindexed. Then once you’re sure those urls are deindexed, you could block those directories again via robots.txt. But remember, if you add noindex to files that are being blocked via robots.txt, then Google will never be able to see the meta robots tag… You will need to let Google recrawl those pages first, see the meta robots tag using noindex, and then you can start blocking the files again. That’s a confusing subject for many in SEO, but it’s a really important one.

Summary – Don’t Let UTF-8 BOM Turn Into An SEO Bomb
There are several hidden and sinister problems that can rear their ugly heads in SEO. The UTF-8 BOM is one of them. If your robots.txt file is not working as expected, throwing errors, and causing serious headaches, then follow the instructions in this post to test for UTF-8 BOM. You might find that a hidden character is the gremlin causing major SEO problems. Then it’s up to you to remove that problem by “disarming the BOM”. :)

GG

 

Filed Under: google, seo

Connect with Glenn Gabe today!

Latest Blog Posts

  • Continuous Scroll And The GSC Void: Did The Launch Of Continuous Scroll In Google’s Desktop Search Results Impact Impressions And Clicks? [Study]
  • How to analyze the impact of continuous scroll in Google’s desktop search results using Analytics Edge and the GSC API
  • Percent Human: A list of tools for detecting lower-quality AI content
  • True Destination – Demystifying the confusing, but often accurate, true destination url for redirects in Google Search Console’s coverage reporting
  • Google’s September 2022 Broad Core Product Reviews Update (BCPRU) – The complexity and confusion when major algorithm updates overlap
  • Google Multisearch – Exploring how “Searching outside the box” is being tracked in Google Search Console (GSC) and Google Analytics (GA)
  • Sitebulb Server – Technical Tips And Tricks For Setting Up A Powerful DIY Enterprise Crawler (On A Budget)
  • Google’s Helpful Content Update Introduces A New Site-wide Ranking Signal Targeting “Search engine-first Content”, and It’s Always Running
  • The Google May 2022 Broad Core Update – 5 micro-case studies that once again underscore the complexity of broad core algorithm updates
  • Amazing Search Experiments and New SERP Features In Google Land (2022 Edition)

Web Stories

  • Google’s December 2021 Product Reviews Update – Key Findings
  • Google’s April 2021 Product Reviews Update – Key Points For Site Owners and Affiliate Marketers
  • Google’s New Page Experience Signal
  • Google’s Disqus Indexing Bug
  • Learn more about Web Stories developed by Glenn Gabe

Archives

  • January 2023
  • December 2022
  • November 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • August 2021
  • July 2021
  • June 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019
  • June 2019
  • May 2019
  • April 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • August 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • January 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • January 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012
  • July 2012
  • June 2012
  • May 2012
  • April 2012
  • March 2012
  • GSQi Home
  • About Glenn Gabe
  • SEO Services
  • Blog
  • Contact GSQi
Copyright © 2023 G-Squared Interactive LLC. All Rights Reserved. | Privacy Policy
This website uses cookies to improve your experience. Are you ok with the site using cookies? You can opt-out at a later time if you wish. Cookie settings ACCEPT
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience. You can read our privacy policy for more information.
Cookie Consent