About Aleyda Solis
Aleyda is an International SEO Consultant with Orainti, a boutique SEO consultancy, a blogger (Search Engine Land, State of Digital and Moz), an experienced speaker and entrepreneur. Aleyda has worked with European, American and Latin-American companies, helping them to grow their organic search visibility, relevant search traffic and conversions in complex environments and industries.
In her Learn Inbound talk, Aleyda will talk about what’s going to change with a mobile first index, how you can make the most out of AMP, and what’s PWA and how you can easily implement it for your already existing site. Learn more about the major updates, functionalities, and opportunities in a mobile first search reality,
How to refocus your SEO actions for a mobile first index
- Understand AMP Do’s and Don’ts
Make PWA work for your website
I just came today to tell you a story this afternoon, a very geeky, sad, but geeky type of story. Like since a few years ago in a galaxy not so far away, smartphones have become our primary digital device. The reality is that we might be a little bit addicted, you know, I just was handling my smartphone like two seconds ago, it is over there. I know where it is. I don't want to lose control of it. Yeah, well, at least some of us, like there are a few exceptions I have to say. I don't know if you have seen Mark's phone. Maybe we can do a little bit like let's take a little bit of a few Euros to buy him a new iPhone X, like, sorry, Mark.
The reality is that mobile phones are a primal need now. It's like, "Yeah." Like this and in some countries like thankfully, this is not in Ireland, not in Europe, but in some countries, it seems that data says that some people will rather give sex for a year than their smartphones. It's like very scary, like yeah, and the typical, like justification of other people looking at this data is like, "No, they are not getting none." It's like, "Yeah, probably." Well, the reality is that for good or for bad, like smartphones have really shaped and changed our behavior, right? Not only in search but in general like in a very scary ways sometimes. And since 2014, it has driven the growth of digital time spent, 20% of e-commerce transactions are performed from mobile devices nowadays. And now search is mostly mobile-driven.
And some of you, my thing is like, wait, wait, wait for it, like Aleida [SP], it's like I have checked my Google Analytics and it doesn't says this, right? Like some of you probably work in B2B. So of course, if you're a B2B type of company, like last year I did an audit for a website. It was the competitor of Tetra Pak, so they sell like huge machinery, right? Like so, no, like the transactions they don't happen online, and it's not e-commerce, even not B2C. So the search of mobile traffic's not as high as a B2C, as an online delivery company, or a platform providing services, or gene [SP] type of located-based services, right?
So it can change from industry to industry. That's completely correct and it's normal. The reality, though, is that many companies, they don't see such a high mobile traffic share because they are not yet that optimized. And that's sad because there's a huge opportunity of more traffic without not even necessarily expanding much more, or doing something that much of a different but really paying more attention and bringing their efforts to optimize all this additional presence that they already have.
And as a consequence, of course, if a lot of people, more people and the majority of people now are searching for mobile devices, Google has said, "Okay, so now we are going to take the ranking factors from your mobile presence." Because until now even if they had a mobile crawler to recognize and identify our mobile presence, they didn't take that information into consideration yet to rank our site, to rank or presence. They only took into consideration the information that they did found in our desktop presence, in our desktop versions, right?
And that is about to change. They have said that at the beginning they are going to switch to a mobile-first, and later on, they are going to completely switch to a mobile-only index. So this is the time, this should probably be the time when we all need to wake up a little bit, it is already being tested and they have said that probably potentially next year is going to be release, right? And again, at some point a mobile-only index and still right now we are going to see that there are a few sites, like this ones that are not necessary that well-optimized, and I took my time when I was going through the slides to see a little bit of how...what was the saddest as I researched, right?
And I went and saw that Aer Lingus shockingly liked the airline that I flew at yesterday here, like what a lovely interstitial there, right? They want to push me to download their app. It seems that their mobile site is not worthy enough to enter, to be accessible from mobile devices and then property.ie, not mobile-friendly yet, huh. This sites we are going to see a little bit of data. They have already issues on mobile and if ranking factors are going to come, seems likely next year from their mobile presence they are going to have huge issues.
But still right now, right? Like, let's think beyond SEO. The reality is that this type of situation is already hurting these sites, why? Because people leave. I mean, if you push me with an interstitial, if you want to push me to download your app, if you like show me tons of ads and don't allow me to actually see the much more important information, if it takes so much to load, I will go away, and many analysis, many studies and surveys have also shown this, and this is a reality, right?
Remember how I said before that most of the traffic, organic search traffic is coming now from mobile devices. Well, there is a huge negative gap happening with conversion on mobile. It's sad. Most of the traffic come from mobile now and we don't convert it. We convert it much more poorly than the desktop one, so the gap is like this, right? It's not trivial, it's sad, it's a sad situation. It hurts our business, it hurts our potential and it's already there and it's just going to be even more important with a mobile-first index coming up.
So I am here to share a few SEO Jedi skills, and you will see I am going to go through a lot of resources, a lot of data, a lot of tools, too. So it's not necessary that you start taking photos or write it down. I just tweeted the slides that I have uploaded in SlideShare, so you can follow me @aleyda. You can see here my handle, @aleyda. This is not a trick for you to follow me on Twitter, although if you want you can also follow me on Twitter, but that's just if you want. But yes, you can see all the slides there with all of the URLs and resources that I am going to share.
And as it was mentioned before, I'm an international SEO consultant, I do this on a day-to-day basis, and I'm going to show you how I help usually my clients to connect with them. When my grandma asks me like, "What do you do, Aleyda?" It's like I connect companies to them, because mostly this is what search is going on right now. And a few of these clients are brands that you likely know. So hopefully maybe I'm not the best, as Barry said, but I don't suck at it. So I'll help you today, too. What is the first thing to do? What do you think? A correctly configured and accessible mobile website you must have, and this is not me. I'm trying to, you know, the Star Wars type of team and stuff. This supposed to be Yoda here, but never mind.
Anyway, so to make our website like to have the base there, to be accessible and compliant so Google can identify that it's mobile-optimized. The third thing that we did need to do is, of course, enable a mobile version. And the reality is that a lot of people think a bit of having a responsive web design. A lot of people think if they have a responsive web design, it's like, "I don't need to do anything else," and that's not correct. First, responsive, it's not the only way to go. It's one of the three main, there are many more alternatives that can be combined, of course, but the three... One of the three main web configurations.
Responsive web design is like the one that Genus [SP] has, for example, so it uses the same HTML that it is only reformat using CSS media queries, but it's the same content, the same HTML. Then we have dynamic serving like the one of the journal has, right? The content is shown through the same URL as you can see here, but the HTML is different because they dynamically serve based on the user agent. If they identify that is a mobile user agent, they will serve one HTML that is well-designed format for that device. If it is desktop, they will do the same based on that device.
And then we have independent mobile websites and they are very easy to identify, because there are privileged in their own parallel web structure, under an M subdomain [inaudible 00;09:29] independent does here in [inaudible 00:09:33]. So each one of them have pros and cons, as you can imagine responsive web design because they load the same information, the same HTML in every case, like it's the same. So at the end of the day when we are accessing on mobile, we might not necessarily want to see the exact same stuff done on desktop, right? Maybe we have identified that the behavior of our users, it's a little bit different. We want to push certain things. We want to certainly reformat the images or certain elements and resources that take a lot to load, and since it is HTML, what we are going to do is just to hide them in certain ways, but the content will still be there, the information will still be there, and it's going to take a little bit of time.
Usually, it hurts more from a performance perspective. Then with dynamic serving, the problem is that we need to really correctly identify the user agent, and sometimes this doesn't... Well, it's a little bit tricky. This doesn't happen as we wish and sometimes we end up... We might end up serving the desktop content to the mobile users or vice versa. So we really need to do it well on one hand, and then add the [inaudible 00:10:38] user agent in the HTTP header, like this specific annotation there so Google can understand that we're using this type of configuration.
And then with all the independent mobile websites. Again, the problem is that we need to redirect when the best of user comes to our site to the right URLs if they haven't found the right URL in the first place, and this can hurt a little bit. However, this option is better as well as the one of the dynamic serving, in order to really personalize the content, the HTML, the experience that we provide to our mobile users. And as you can see here you have the reference. Google has published long time ago best practices of the configurations for all of them, right?
And all of them has like very fundamental requirements, like, for example, in the case of responsive web design, it is fundamental like really critical that you don't block the CSS, the JS, and the images because this is the way that Google has to really identify that you have a responsive configuration in the first place, the same with dynamic serving, the same with independent mobile sites. They all have specific best practices and configurations that we need to implement, so Google can really understand that we have implemented one or the other type of configuration.
And the one thing is, like, typical question, when Google announced a few months ago that they were going to move to a mobile-first index, like are this configuration is going to change in any case? Because, for example, as you can see here, the configuration of independent mobile sites, it requires that we tag the desktop URLs and the mobile URLs, and we refer them to each other. So the mobile URLs until now, they needed to add a rel alternate...a rel canonical tag. Sorry. A rel canonical tag point into the desktop ones. Why rel canonical? Because remember, until now the mobile URLs were not really taken into consideration for indexing purpose and accessing purpose, ranking purpose until now.
So they were canonicalized into the ones that were original, the desktop ones. But some people say like, "Well, this needs to change with mobile first, right?" Because now these mobile pages will be the ones that will be indexed on rank. So the tags will need to be switched, right? Before, it was a canonical from mobile to desktop and then a rel alternate from desktop to mobile. Now it needs to be the other way around, but then someone has been... A lot of questions has been arise like this on Google Q&As; and then like Gary from Google very eloquently said like, "No, there's no need to change the configuration."
So Google has said in many times that they will make the most to avoid that we need to change all the configuration and best practices that we have had until now because they know that it's tricky. It has taken so much for us to get this thing going, right? And the one thing, though, is that they recommend that if you at some point are considering to move from an independent mobile configuration to a responsive web design, you do it right now before the mobile-first index happens. Why? Because once that they start taking into consideration the mobile pages to rank you, well, that will be a real migration happening when you do the migration to a responsive web configuration. But if you do it right now it doesn't matter because those mobile URLs are not really going to influence negatively in case something is amiss, right?
So you better do it right now, if you have thought on doing it at some point. But what else, what we can do to really make completely sure that any of these configurations are correctly set, are correctly executed on our sites?
The first thing, very fundamental, very basic. To go to the Google validator and see if our much more important pages pass the validation. And take a look at this. It really shocked me to see that thejournal.ie didn't pass the validation and I said, "Like why is like..." The reality is that they have a mobile version but they are blocking the mobile Googlebot. So as you can see, it's not having just a mobile website, it's allowing Google to properly recognize the content on one hand, and then, well, configure correctly that content so it's accessible and can be understood and accessed by Google.
And then other websites like ran.ie [SP], it seems that they don't want us to rent from mobile devices somehow, and they are not mobile-optimized now. So use Google Analytics to identify which are the devices that are used by your users, the mobile devices that are much more popular in every case, and then you can go to Google Chrome and use Chrome DevTools to simulate those devices. It's very easy, really like you have a powerful SEO tool for free in Chrome, right?
You right-click plus Inspect here and then you click on this icon, and then you will be able to choose from whatever device up there to navigate, to browse through your site, if you were in that device. Select one of the top devices that the users actually use, of course, and take a look how these pages actually look. See in the Google search console if your biggest trigger, mobile usability errors, because like right by default you might likely find some issues there, like if the viewport tag is not found in some of your pages, these pages. It doesn't matter whatever type of configuration and design that you have there. Google won't allow them to pass the validation, because the viewport tag is not there, so that is fundamental.
You can use also SEO crawlers, like for example Side Boat [SP] to verify all of this assessment, validations, attributes that Google usually take into consideration from mobile usability perspective. You can see there that here that these are the same. That Google validates and then you can also use other crawlers, bigger crawlers, more enterprise-oriented crawlers, like DeepCrawl. They really have this very in-depth and powerful mobile report, where they identify what type of configuration each one of your pages have and if they are correctly configured or not. What is the configuration, you can see here if it is a separate desktop, if they have AMP, if the buyer [SP] user agent is included or not, if the viewport is correctly set or not, page by page like this.
So you can easily go through each one of your site pages and fix them accordingly. And then once that you make sure that your pages are accessible, they have a mobile version, they can be found by Google. Your content also needs to be there for Google. And this is very common, right? And again, another Irish site, daft.ie. I go to the last version I see all these options they provide already like direct accesses, and previews on their home pages like this, right? However, if I go to the same page on mobile, we can see that it's not the same, right? You can see this is an independent mobile sites under a touch subdomain here specifically, and yeah, much more simpler option.
So that this are the type of sites that right now you may sound like, "They have a mobile version. It's correct, it's okay." Nope. One of the main things that Google have said is that we really need to take all this content that we were optimizing for, and that we wanted them to take into consideration to assess and rank our sites, also to our mobile pages now, because right now a lot of designers and developers, they have taken like the simplistic approach to optimize for mobiles, like, "Oh, it doesn't load fast. Okay, let's eliminate all the structured data from the mobile version." Gone, gone, gone, delete, delete, delete, "Oh, all this content. How does it look? How do we make to make it look well on mobile?"
There is so much more restrictive elements here, like this little space. How do we do, like all these paragraph gones, deletes? Like we cannot do that anymore. We need to take all the structured data, all the content that we were really optimizing to... And that we really wanted Google to know us from and take into consideration to rank us with to our mobile pages. So now we really need to...a mobile-first approach. Now we really need to take a serious process to optimize well, not only from an SEO but also usability perspective. Because it is understood that there are much more restrictions of spaces, and that is why Google has said, "You know what?" Until now if we didn't show a content by default on a desktop pages, Google didn't took that content into consideration in the same way that they did with visible content. For example, if we hide a content with CSS visibility, zero our visibility hidden, or whatever technique we use, even with CSS.
Not necessarily with even with scripts. They won't take that content into consideration, right? And however they say, "Look, you know what? We know that on mobile it's much more difficult. With mobile it's difficult, we are going to take into consideration the content that you include on your page, even if it is hidden." Like by default like this, right? So it's okay to use this type of design practices to include much more content on your mobile pages. And then again, it is important that the content is accessible, easily accessible. And that is why Google at the beginning of this year, they launched this update that paralyzed the usage of interstitials and pop-ups.
A lot of people they had, of course, they had all this type of theories, "Oh, Google is doing this just to, you know, to compete with websites like Yelp," because they didn't like that Yelp optimized, like really optimized for localized queries, and then when the user got there they just like show up huge interstitial saying like, "Download our app." So they didn't even continue to do browser content on the web, right? Like there were a lot of conspiracy type of theories like this. But the reality is that this was an update that I was...from my user perspective I was very happy with because I don't like this.
Foursquare, they continue to do this somehow. Maybe that is why they haven't necessarily like regained all the users that they used to have at some point in the past. But yeah, I highly dislike this. This is the screen that I get when I go under to the homepage from my mobile phone by default, right? Guess what happened on last January to Foursquare? Here they lost tons of visibility from mobile results because of this, right? So let's avoid this. There are many more alternatives to implementing this. One of this alternative is to use the mobile app banners, right? Like they are supported by default natively by iOS and also Android. We just need to include certain tags on our mobile pages like this, and they will be shown...they will be included at the top.
There are other workarounds, for example, I was at a conversion conference like a few months ago, and like they say like, "Look, don't worry. Just don't show the pop-up or the interstitial right away when the user lands. But, you know, add a timer or required an action from the user, an event that is triggered, things like that. Wait for the user to load the page or show the banner to cover half of the screen instead of the whole screen." Of course, there are always grayish areas that you can play with, but the reality is that we need to think that Google at the end of the day what they want us to replicate the type of experience that our users have, and if the mobile user experience that we provide, "Oh, it's intrusive and not necessarily that accessible." Well, they will try to replicate and not take that content into consideration.
So what we can do to really make sure that we comply well? We need to emulate the Googlebot for smartphones. So for example, any crawler nowadays they allow us to select any type of user agent, and this case the Googlebot for a smartphone, and we also need to select... We should select the rendering option in this case with Screaming Frog. So we can actually see what Google sees, what the bot sees. So we will find things like this, right? When we start crawling in the case of Argos in Ireland. Again, they have their mobile subdomain blocked somehow. Yeah.
Or things like that, it's like, "Why are these resources returning errors? Or how is the mobile content renderer here?" Is it correct? Is it how it should be shown? It doesn't load. Are the images really there? This is how we want the user to be seen by the user [inaudible 00:23:46] the crawler? From technical configuration to titles, descriptions, everything. The redirects. If we need to have redirects, if you have an independent mobile site, everything should be compliant and needs to really reflect the type of configuration and behavior that we want to give the Googlebot on our site, right?
So I love this post that was done by Everett [SP] on the Moss Blog [SP]. Like going step by step on how you can do this type of validation, but with a parity comparison in mind. Because remember, we want to make sure that we take the content that we had on desktop to a mobile site. So instead of doing a typical audit, in thi case a mobile audit, making sure that our mobile pages are correctly configured, the [inaudible 00:24:37]. If the actual content that is there on configuration replicates the one, reflects the one that we have been having until now with the desktop one. So we can make sure that when the mobile-first index come, we are going to be at least okayish.
We will start in the same place that we are right now. And then last but not least, your mobile website should be really fast. Like forget about SEOs because of conversions is because of the experience that we give to users. I don't know how...like this for me was shocking but you know what? We don't want to stress user out but the reality is that it seems that experience in mobile delays is like even harsher than watching a horror movie. I don't know if this has taken strangers things into consideration, but the reality that people have some minimum expectations, right? And the expectation here is of two seconds. And some studies have shown that the average speed that the website have is like far higher than that as you can see here, yeah.
And this means money. Money that is lost because of painful mobile delays and now this is going to be just more and more important because in the mobile-first index, Google is going to take mobile speed as a ranking factor into consideration, right? So just like quick tests, like how much do you think that the independent homepage takes to load? Less than five second? Do you think so? Yeah. Less than five seconds on mobile? Yeah. No, no, seven seconds. I love this tool by the way from Google, not because necessarily the accuracy but because they show up in just a comparison and the estimated loss of traffic that it gives. Of course, it can be a little bit more, a little bit less. You can use many tools like web-based tests, there are so many, The Lighthouse extension from Google, so many resources nowadays.
However, I really like that they show the context, right? The impact that this type of delays may have. The Argos Ireland homepage. How much do you think that it takes? Less than eight seconds do you think? Yeah. Ten seconds. Now, lottery.ie, you know, they should be fast, you know, it's about giving away money. Test your luck here, like how much? Less than 15 seconds? Fifteen seconds less? Yes? Money is hard. You don't want it to give away. So what about your own site?
The easy way to identify this is to use Google Analytics. You have this speed suggestion report, so it's really easy to go there to the pages that have a higher page view, and that will give you of course like an average payload time. It can be a little bit not necessarily that accurate but you can take these pages as the top ones, a much more critical ones that you can assess yourself, and get the mobile speed assess many other ways to compare data, right?
So you can use, again, the crawlers. Nowadays they give a very in-depth... Sitebulb in this case page Pete [SP] report, so you can complement with that data. I love this one because of Sitebulb, because they don't only identify the issues like...but also provide recommendations, like very actionable recommendations, like Minify CSS, Minify GS, avoid doing redirects, avoid too many web fonts, and they specifically include and show us which are the pages suffering decisions, which are the resources causing these troubles, right?
And you can, again, verify and validate this data with other resources. This is the Chrome Lighthouse integration that I love it, again, and you can see it directly on your browser. And it will show you not only how much time does it take to paint the content of your mobile content on the browser, but actually like which are the critical issues. In this case, they will map with Google best practices, PageSpeed best practices like this, and at the end of the day, as you can see, it's about following WPO's best practices. The solution is to implement this development perspectives that have been there all the time, but the reality is that we work with clients that are whether big, there are huge, so had they have a lot of restrictions in their legacy system, or we work with smaller clients that don't have necessarily that many resources to really implement all this stuff. That's the reality, being practical, right?
So Google launched a couple of years ago AMP to help us with this, right? What it does is to simplify the already existing HTML and JS and CSS, and they provide us with a simplified version of it. So at the end what we have is our original mobile page and we will have this extension, this parallel presence that we will build with this already optimized by default resources. And as you can see there are websites that they doing a pretty good job. As you can see RTE here. They provide mostly the same type of experience, it's very well-replicated and they also include the correct tags here to refer, and it is very important to refer the ANP URL to the original one on mobile, because it's just, again, it's not really your original mobile page. It's just an extension that Google will use to provide a much faster experience. This fast.
It's crazy but it's like this, it's much more faster. Even if you already have a relatively fast site, it's going to have...going to go half of your speed, right? The thing is, AMP is not a ranking factor, at least yet, right? And also, Google won't index AMP in a mobile-first index, because, again, it's an extension, a parallel presence that you built. It's not your own site, right? However, it has been made a requirement to be included in the news carousel. Google has said, "You know, I just want to really show fast pages on the carousel to give the user the best possible experience."
"So I am going to make AMP a requirement," so like this. So this is a type of presence that you will get with AMP, right? You will be included in the carousel with AMP. You can see here the logo and then also the organic results. All of this has done that. AMP pages, AMP URLs really skyrocket in visibility. I have clients with this data. Take a look, it's crazy. They are getting from mobile, they are getting more page views, more clicks, more visits on AMP URLs than the actual mobile presence that they have built, and they are not alone, right? This is data [inaudible 00:31:36] published like a couple of months ago regarding the type of visibility that top media sites in the UK have gotten. But we need to be realistic, this is a resource. AMP is not a replacement for your site, it shouldn't be. In a Google Q&A that we did a couple of months ago in Spanish by the way, you have the link there if you speak Spanish. They even said, like one of the representative that it would have been reasonable for them to expect that this group of limited functionalities with AMP will replace the one of the full mobile web, right?
So AMP is a fast add-on to your existing but slow mobile web. Don't use it as a silver bullet solution but as a resource that is there, so you can avoid this type of experience. There are many successful and not successful type of experiences that have been published about AMP, and this is one of the nonsuccessful one. And this website says, "Okay, yeah, we tested AMP. It wasn't good, we ended up eliminating it and wanna..." And they say, "Our site was already pretty fast and we don't publish new." So why did you use AMP in the first place? It's like, what the heck. Of course, it was not going to really move your traffic needle in this case. So for those of you who cannot improve your own mobile page speed, or who need to be included in the news carousel, AMP can be a solution, AMP is a resource and here are a few tips to implement AMP.
The first thing that you need to do is to check if you can really implement your current mobile user interface and functionality with AMP components, they call these components. They give this a reality, yeah. Google just really trying to push AMP, so they have built all of this AMP by example for example group of resources. You can even test your coder, it's crazy. So you can see if your current user experience and functionality on mobile can be replicated with AMP, and this is the type of goals that you want, right? Like the Mirror, they're doing it very well in Ireland as you can see, like one of the original mobile page is AMP URL version. You cannot really that much tell the difference between them.
However, these what you need to avoid. These are independent. This is the original mobile page, they have a menu there. However, if I switch to the AMP URL version, there's no menu. I have had a few clients telling to me when I start this out, it's like, "We implement the AMP and our bounce rate skyrocket." "Yeah, right, because your super-good-looking hamburger menu is not on AMP." No wonder, your users they don't have anywhere to go to. Yeah, anyway, so you have also free WordPress plugins that can facilitate the implementation.
The reality, though, even if they are paid or not because there are premium options, I've tested a few of them. They provide these additional like functionalities to personalize the user experience and the design of your AMP pages, you know, it's disappointing, you know, I tried to follow this route. I redesign it, took a lot to redesign my own site, and this original mobile page. I really like it, I spent a lot of time and this is the AMP URL version, one of these plugins that supposed to give me like really highly personalized options, like no. You really need to put your resources there to personalize AMP URLs and to replicate your user experience, right? So it's important that you verify this.
Also, there's an ecosystem about user experience when accessing to AMP pages from SERPs, when we click on AMP we get this URL. This is the AMP URL viewer URL from Google that falls and it's rendered under the google.com domain or whatever country domain they are being shown, these URLs are being shown. And this is because they use themselves as a CDN, right? And this end up generating that a lot of users, and probably you have seen these URLs like in social networks, whatever they are being shared like this. It was painful to see that some of my posts were showed like this, and I was like, "Oh, this could be a link to my site and now it's just a link to a URL like under the Google domain."
So we can start avoiding this type of not sending out the popularity, the right popularity to our own original canonical mobile web experience, by optimizing our own internal menus. So we use AMP to get the traffic, yes, that's cool but if we want to refer users, let's refer the user to our own original mobile pages like this, like the Irish Exo [SP] miner do, like on their AMP design they don't link to other AMP pages, they're linked to their actual mobile pages because they probably have a good mobile work experience, a good mobile version. They just wanted to use AMP to be included in the news carousels.
Also, don't allow users that are browsing from desktop devices to your AMP pages because otherwise, they will get stuck like this, daily verge [SP] like this. This doesn't look good. Why you don't redirect me to the right desktop version, right? Do it like this. Redirect to the right version that is properly configured to the right device. Also, AMP implementations, this is crazy, have tons of errors, more than 70% of the publishers using AMP have errors. So SEMrush did this great study, and most common mistakes are coming, of course, by elements that are compliant with HTML but they are not supported by AMP, right? And again, with crawlers like Sitebulb in this case or also DeepCrawl, we can go through the pages and they have already this very straightforward report showing the errors, showing the mistakes, the configurations problems that we will find in every page like this.
So it's very straightforward to find them like this, and the relationship between the AMP pages and our original mobile pages like this, too. So it's very straightforward to go through them and download this type of sheet and say, "Look, these are my original mobile URLs. These are the AMP URLs, and these are the type of issues. These are the issues happening in each one of them." And fix them because sadly, and this is a real screenshot of a client, it can be painful to implement. It's like every time there was a release, something more happened. This has been fixed last week and then something more happen, yes, thank you very much. It didn't validated that this new type of content really went through the AMP validation first, and was AMP-compliant.
So what we can do, though, to avoid this is to really prioritize to fix the critical issues, to avoid most of them. And that the critical ones are the ones that will really avoid your pages to be shown in mobile SERPs with AMP, so fix them first. You can use also The AMP Validator by Google, but take a look really which are the specific issues happening much more commonly, and then avoid a pattern. Like identify the pattern, avoid it in most of the pages that are shown with them. Also, you can use the Google search console to follow up with them, that is good. However, there are other tools that provide even more data. For example, I love SEOMonitor data because they not only show that the pages...the AMP results where I am included with my own AMP pages, but any of them.
The ones that are shown in my SERP, so I can really identify opportunities there. The same with SEMrush. They show the AMP information not only for my site but the one of my competition. So I can see for which pages my competitors are ranking with AMP pages and I am not. The same with Citrix, and I love all this data because it provides like when you are doing a research for any type of query and any type of competitor domain here, they will show not only where they are included with AMP results, but also any type of snippet. So for example, if you want to included in a zero results type of observed feature, right? Or if you want to be included with the news carousel, if you want to be included with, I don't know, mini site links. It will show them right there.
So the reality is that these are only the highlights. I did a full AMP presentation last week, SMX East in New York. So there is tons much more about AMP that you can take a look at there. And sadly and I am even beyond time. Oh my God. Time is sadly almost up. You have here like step by step type of [inaudible 00:39:56] that you can take to validate that your website really complies with the mobile-first criteria, to make sure that all of your SEO process is taken to a mobile-first type of mindset, and you make sure that you can make things happen with these tools. I did this type of stack, right? Including all of the tools that supported mobile features, and you can take a look at them at the Moss Blog here, so it's much more easily for...much more easy for you to reply all of this questions that I have included there.
The reality, though, is that you don't need to wait for mobile-first. These are the type of results. These are the type of increase that I expect you to have, that I already have and I expect you to have from mobile rankings, from mobile source conversions, a real like a scalable growth trend over time, right? So now is your time. Thank you very much.