How to Find and Fix a Weird Bug with Google Previews

A while back a client had an issue with their PPC ad previewing the mobile landing page rather than the desktop version of the landing page. It was a bizarre one-off issue that involved SEO teams, PPC teams (separate agency) and Google engineers. The organic search result rendered a preview of the correct landing page: national geographic shop organic preview Notice the different landing page when previewing the PPC Ad: national geographic shop PPC ad preview Thankfully it was discovered that the Google preview user-agent was being redirected to the mobile domain, resulting in the preview showing the mobile content. Duh?! Right? Hindsight is 20/20. In defense of all involved, Google previews weren’t clearly stated on how they actually worked. Are they cached or on-the-fly? Google states that they generally generate previews using cached content but if it is not available then they will generate one on the fly using the user-agent “Google Web Preview.” We knew there was something signaling a redirect but without full access to a client’s site, it is difficult to dig deep enough to find the culprit. However, we were able to test the PPC ad URL against the Google Web Preview user-agent and voilà! There was the answer in a 2 second test. curl status against user-agentThe site was redirecting the desktop URL to the mobile URL for the Google Web Preview agent only. Conclusion: Running the target URL against the user-agent string showed us exactly how the web preview bot was reacting to the URL. Interesting to see confirmation of Google's vague explanation of how previews work. It seems that in this case, the organic results showed a cached version of the preview, but the PPC ad showed an on-the-fly version, rendering the mobile the URL. user-agent detection preview The client was able to remove the user-agent redirect and the mystery of the incorrect preview was solved. How to Test for This So how can you test your site against something odd like this? We will show you! There are tools that can help you do this, but we prefer the manual way in order to remove any points of weakness (and to get our nerd on). To test a URL against a user-agent string, follow the steps bellow: *For this example, we will use the Google Web Preview, but you can replace this user-agent string with any other user-agent string you’d like to test. User-agent strings are easily found online.
  1. For Mac OSX or Unix users, open a Terminal window. For Windows users, you can use Putty or your favorite SSH method...
  2. Type: curl --head --user-agent “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/[WEBKIT_VERSION] (KHTML, like Gecko; Google Web Preview) Chrome/[CHROME_VERSION] Safari/[WEBKIT_VERSION]”
  3. To be clear, there are single spaces separating the text entered in the curl command and two dashes (it is hard to see in this WordPress font). There are no tabs or enters (new lines) and the user-agent string needs to be placed within quotes
  4. After typing the curl command, hit enter
  5. Review results
terminal window curl command example The above example ran against the google web preview user-agent. It returns a 200 header response code (perfect). Let’s see what a googlebot mobile should see when properly being redirected to a mobile site. curl command example for user-agent stringNotice the “302 Moved Temporarily” and the location” (by the way, CNN should change that to a 301 redirect). This curl command tutorial is handy for many situations, and it confirmed an annoying issue for our client. We often find clients serving different header responses and redirects to different user-agents. Performing this exercise can be a big find and easy win, saving your site potential problematic issues. A big thanks to Jody O'Donnell and the RKG crew for helping with the discovery and testing of this situation.  
Join the Discussion