This fall was packed with announcements about Google’s mobile-first index. First, Gary Illyes gave a keynote at Pubcon and dropped a bomb that Google intended to roll out a mobile-first index in the near future.
Sure, Google had been hinting about the mobile-first index for a while, but now we had real information from a Googler that it was indeed coming.
Then on November 4, 2016, Google published a blog post officially stating its intention to roll out a mobile-first index and explaining why it wanted to do that. It was huge news, since the new approach is a 180 from how things have worked for a long time. I’ll cover more about that soon.
My point today isn’t to detail the mobile-first index. That’s been done many times already. Instead, my purpose is to present a case study of a site that finally went mobile-friendly but will end up heading face-first into the mobile-first index. Sure, the mobile-first index hasn’t rolled out fully yet, but it’s going to soon. And we also know that it’s being tested in the wild.
(Actually, the November 10, 2016, algorithm update could have been — or partially could have been — Google testing the mobile-first index. You can read my post about the update to learn more about what I saw while analyzing sites impacted by that update. Note, there was also a substantial rollback of that update on November 18, which could indicate there was testing going on.)
The case I’ll present today is a good example of how changes from Google, and then on the client side, could end up colliding on the web. Both parties have the right intentions, but the collision could yield serious problems.
Comments