[APPLAUSE] ALEYDA SOLIS: So,
thank you very much. I speak at a lot of
conferences, usually, but these are search
marketing conferences. So, it is pretty much
refreshing for me to be surrounded by developers. Usually, I end up
debating with them a lot. Hopefully, not this time. Not at all, I think. I’m delighted, actually,
to speak today– to share a few of the
insights and experiences that I have had in the last
couple of years with AMP to maximize AMP results–
to make the most out of it, through the
optimization process and achieve results during that. So I have already been
introduced a little bit. In case you don’t
know, I have been doing SEO for a little
bit of more than 11 years. I have spoken a little bit
about it around the world. I have written a book. It’s in Spanish, though. But if you’re a
Spanish speaker or want to learn Spanish while reading
a little bit about SEO, which is fun, really, just let me know. I’ll be happy to
give you a free copy. In any case, what I do
at a day to day basis, or at least this is what I
tell to my grandma, is this– I’ll help brands and companies
to connect with them, usually nowadays, through mobile
devices in search– through search, really. Usually, I help, at this
point, pretty big brands. But realistically,
ultimately, speed is an issue that affects
and negatively influences many different
types of websites, from smaller websites
to huge websites, too. And this, from a
purely SEO perspective, is also pretty big. It’s huge, and it will
become even much more important with the upcoming
mobile page speed update. In case you haven’t heard
about it, it’s coming in July. And until now, Google hadn’t
taken speed into consideration. And now it’s going to be an
actual working factor coming from your mobile web presence. So we really want to make the
most out of the AMP opportunity to easily fix this. If, at some point, we
haven’t yet– right, hopefully you have,
but in case you haven’t, besides
giving your website a much more delightful
experience, and an amazing user experience, and
accessible design, and provide all of this
magnificent functionality– so all key 10 UX best
practices, you want, also, to make the most out of it. Realistically,
these are the type of results that we can
obtain with AMP, right? I have helped websites from
huge websites in the news sector to smaller communities
to blogs to B2C and B2B. And in general, I have to
say that the results are pretty much impressive, right? And for some of my
clients, really, AMP became a requirement
if they wanted to be included in the
Top Stories Carousel. These were
informational websites that really wanted
to be there, right? So we were one of the first– I have to say, with a few
of them, to implement AMP and to go through the
troubleshooting process. And despite the huge
opportunity that AMP gave us, this is the reality, right? This is study and
analysis that SEMrush did across many countries. I think it was eight countries,
from the US to Europe. You can see a few of them here
that the ones to identify which were the most important issues–
the critical issues that they had, and how correct
and optimized their AMP implementation
was, right? You can see the results there. 70% of the publishers
had errors. And this is not an
exception, I have to say. Many of my clients– for example, I have clients that
have communities on AMP, right? And they have the typical issue
of user generated content. Do all they need to
validate and make sure that user done at whatever
type of character that can or embed any image or video
or element or resource that will make that page to not
be able to validate well. And then you have all
the types of websites. And every type and
different type of website will have different
types of issues and the scenarios in there. So this is not unique
to publishers, for sure. And realistically, this
can be very well outlined with your optimization
process, right? What I have found and what
I repeat again and again is that the most difficult
SEO task is not necessarily only to identify the issue, but
make sure, first, to avoid it, and then to align
the optimization process with your already
existing development process, content creation process,
marketing process, et cetera, et cetera, to
make it viable, to make it, also, relevant and profitable
at the end of the day. So first issue here
that we can easily solve with a correct
optimization process. And well, maybe I
shouldn’t a voice, but let’s do a little
bit of a voice. Typical client– oh, my
site engagement decreased after launching AMP, right? It’s like, I expected to see
this huge spike in traffic, and all of the sudden,
oh, what is this? What are these shitty results? You promised me that I will
have an increase, right? So this is a typical comment
and complaint of someone who didn’t really assess
the AMP implementation at the beginning. Because the decision shouldn’t
be, necessarily at this point, can I implement all
these functionalities and content in AMP because we
have all these many components already? But what is the
best configuration? What is the best
setting, in case you have an independent
mobile website? In case you’re doing
responsive web design. In case you’re doing
dynamic serving, right? There are so many different
decisions to be made. And so how do we start? First, we should go through
all of the different types of components and
realize and identify if all of our current
functionalities can be easily
implemented through them, if they can be replicated. Well, we have all
these resources, we can even troubleshoot them. We can even copy
our current code and use the documentation
there, too, and go through it with a development team. And hopefully, also,
with your own SEOs to see if it is
feasible, also, to do it in a way that is
accessible, that is correctly indexable,
et cetera, et cetera. And we should keep
this, also, in mind. The different type of settings
that we can have– we’re on our own mobile
website, right? We can use responsive
or dynamic settings. We can have independent
mobile website, right? We can use AMP as our own– as
your website or canonical AMP. You can use independent mobile
website with non-canonical AMP. And you will end up having to
support three different types of web properties at the end
of the day, which might not be necessarily the most cost
effective way to implement it, right? So just an example, right? Two different implementations
of independent mobile website along AMP. Like, we have wikiHow. We can have their
best of websites– their canonical URLs– the ones
that are indexed at this point, because we haven’t moved yet to
the mobile first index, which is expected to happen in
a few months by Google. And then we have the AMP
version loading there under the [INAUDIBLE] domain. And then we have the independent
mobile website version, with all the AMP
parameters there. So every single change,
every single update, they need to
replicate it in three different types of properties,
which can be a little bit too much, right? This doesn’t mean
that it’s not good or it’s correct or incorrect. It works for them. They have their own
characteristics, their own needs, their own
restrictions, their own goals, resources, et cetera, and they
implemented it right there like this. And then we have this other
type of setting, like, with the Irish Times. They have their desktop
website like this, and then they have an
independent mobile website implemented directly
through AMP– through AMP, that
loads directly there. So every time, if
you go to Chrome, and you [INAUDIBLE] any type
of mobile device or you go to the mobile and
you enter here, you will be directly shown this
result here– this page here, whether you have gone through
the mobile service or not, because this– their independent mobile
website, directly in AMP. So which is better for you? Which makes much more sense
based on your own restrictions and capabilities? A lot of people
right now is trying to move from independent
mobile settings to responsive or dynamic serving because
of Google’s upcoming mobile first index. Because at the end of the
day, your independent mobile settings will
canonicalize directly. If you have them
like this, you will need to canonicalize
to your desktop one. And this won’t makes
sense, necessarily, when the mobile first
index comes, right? So this is something that
you need to really validate, check well. If this is maybe a good point
for you to migrate first to a responsive setting– if you can directly
implement AMP there, or if you want to minimize the
AMP implementation like this, directly. Also, something very important
that, in the past at least, with the independent mobile
settings, it was not needed. But nowadays, we have
been asked to include every single structured
data and tax, in general, that we had in our desktop
versions to our mobile ones. And also in AMPs, like, for
example, hreflang annotations. If we had hreflang annotations
in our own desktop versions to specify the language, and
alternatively, the country that we are targeting
with each single page under alternate sister
versions of each page– the ones that are
targeting all the languages or other countries to specify
the relationship between them, we need to also implement
those in the AMP URLs. And this is a type
of setting that we will have with the independent
mobile organization or scenario. It’s a little bit more
complicated, right? So again, it’s
important to assess what is much more feasible to
implement by you internally, right? Because for example, here
we have our desktop version, and of course, we need to
specify which is our AMP URLs, and the AMP needs to
canonicalize back, and the same with the
independent mobile setting– exactly the same. And then again, we need
to include the language or alternative to the country
values in each one of them. A little bit of
more work, isn’t it? What is best for you? What is much more
efficient for you, right? But you need to go through
this and understand the specifications, what you
can do with each one of them, and what is the best
way to apply them. Then again, we have the
relatively new, also, requirement that came
in play this month, I think, already,
about content parity. The same content that is
available in your canonical URL and your canonical pages, in
case you are not implementing AMP directly in them, needs to
be also shown in your AMP once. What happens, right? A lot of websites, they
were just using AMP. They were using AMP
as a sneak preview. And you need to click on the
button to be referred directly to the canonical page. That was not using AMP– not
necessarily giving the best experience, in general, with
speed, so we ended up having the same non-ideal situation. Right, so this shouldn’t
be the case anymore. You should avoid to do this. And realistically, there were
many questions around the SEO community around this,
because a lot of publishers, they love to have the button in
their original mobile website, saying, like, load more or
show me the whole content. That is not shown by
default sometimes. And sometimes you’re taken to an
additional URL, not necessarily the initial one. So realistically, to keep
things clear, if you actually want to do this
with your AMP URLs, you should also be doing this
with your original canonical URLs, which might
not necessarily be the best in order for
Google to really assess and run well these pages,
because you won’t be showing your whole
content there, right? So, if you’re
showing 10 paragraphs in your original
canonical URLs, you need to show those same 10
paragraphs in AMP, right? So again, it’s about
parity in this case. The content that you’re
delivering one way, you should deliver in the other. And this is so funny for
me because, of course, this is specifically–
this is just an example. This is not a website
that I have worked on, but I had this very
typical scenario that I have found many times. This first time that I helped
through an AMP optimization process, and the client
was like, oh my God, when I implemented AMP, I
saw all this lost engagement. The bounce rate is horrible. Can you please take a look? And I went and checked, and
I saw that they had no menu. How do you want the users
to continue browsing through your site, right? You eliminate the hamburger menu
or the menu in general from AMP implementation, and you
are not allowing the users to continue browsing
through your site, to continue engaging
with your content. So don’t do this. Do this, right? I’ve done a little bit of
tests with a few clients, and I have asked, which
one is the AMP version? Like, when we have finished
a process across a few users, right? Sometimes they don’t even
know because the experience is really replicated. The experience is right there. And this is what we should
be looking to achieve– to implement that UI– the functionality,
the content that we give with your original mobile
pages with the AMP ones. And if at some point,
we decide, again, that we have an independent
mobile site, we implement, additionally, an AMP
URL probably to it. Like in this case,
for example, we have the “Time” website, right? And this is not the first time
that I see this happening, right? I am shared these URL
through social networks. I click on it, and I go to
the AMP version like this. I am not redirected to
the relevant desktop page because I am accessing through
my desktop device, right? So we shouldn’t forget about
mobile configurations and best practices here. If I am accessing
through a desktop device, through an independent URL
that is targeted to a mobile, then I should be redirected
to the relevant desktop URL. Because otherwise,
the experience is not that good, right? I will end up leaving anyway. Or the easiest way to
fix this, actually, will be to implement
this page directly as a responsive web design. Then it will be multi-device,
and I wouldn’t be needed to be redirected anyway. And of course, if at
some point, somehow, we don’t like the results
that we’re getting and we decide to disable
AMP, we need, again, to follow certain
SEO best practices. We just don’t remove
the tags and that’s it. And it starts returning 404
HTTP status in the all AMP URLs. No, no, no, no. We need you to
handle one redirect. We need to save that profit,
refer that old traffic to keep what we have
gained until now, and refer all this traffic
to our own canonical URLs that we are keeping and we
are still working with, right? Actually, there is really
good, here, resource– step by step type of
results, independent of the type of
configurations that you have on your site, right? But it should be
pretty straightforward. So as you can see, it’s all
about accessing the viability and the best way and setting. That is the correct one,
based around resources and capabilities and
goals to achieve. And then there’s another
very common scenario. The AMP version is
launched, and then we get all of this huge share
of errors all of a sudden, and we don’t know where to
start, right, fixing them. So it’s about validating. Validating well before,
during, and after the launch is happening, right? First thing, and this is
very important, it’s not only about sharing the specification
on how to implement the components,
but actually, what are the actual errors that are
the most common ones to find, and the ones that
should be validated to avoid, also, when with
the AMP URLs are generated? And there is
actually a reference there of validation errors. These are the ones that are also
used through the Google Search Console. So this is a great reference to
have through the implementation process. And then, again, there are
some Google specific errors that we should keep
in mind that have to do, also, around
content parity, that these are
specific to Google. But again, if we want to be
shown in a mobile service, that I’m pretty
sure that you want to be shown in a mobile
service through your AMP URLs, these are the ones that you
should also keep in mind. And there’s a list of the most
common errors to look for. Again, this is based
on the study of SEMrush that they did across many
important publishers that had AMP implemented. And a lot of
disallowed attributes that’s directly from
HTMLs to invalid URLs, except disallowed resources. So these are the ones that we
should be looking for in order to actually provide
the expected results. How we should do it. I have found the best time
to start validating, really, is not when the code is
already generated to TN, right? It’s to work alongside
the development team, to go on troubleshoot and look
with them for these errors. Even before the code is
already ready to be tested on a test on [INAUDIBLE]
for production on [INAUDIBLE] that is
accessible for almost everybody that is a stakeholder
in the project, right? So what I have
done in these cases is to use the project
validator, when you can actually even copy, paste, and
you can paste here the code to look for
mistakes and problems, specifically with
the top templates– the home page, the listings,
the products, the community, the blogs– to look for the errors there. There’s also a way
here to be able to test specific internal pages that
are not publicly available where you can also do an
ngrok tunneling– easily configurable. And this, of course, is to go to
through your top most important templates– ones that you
have the implementation done through them. You need to crawl them. There are many SEO
crawlers, simulators, that right now
support AMP and are able to specify all
of the type issues that the Google Search
Console will warn about, like DeepCrawl for example. They will identify what type
of mobile setting you have, and they will specify
here, page by page, if, for example, you have
a non-reciprocal mobile AMP type of relationship. The annotations are not found. Which are these pages? At which level of the
URL structure they are– the web architecture
of our site. The same with [INAUDIBLE] I
love because its very visual and very telling. They will tell you which
ones are past here, where there are no issues,
how many have been crawled, how many have been
crawled with AMP, which are the actual issues? The one in red is
the critical issues. The ones that will not
make your page to actually be shown in mobile search. The ones that are actually
[INAUDIBLE] desirable, not necessarily required,
but desirable to include them directly and refer
them directly. And then you will
be able to generate a list of canonical URLs and
URLs with each specific issue listed like this, segmented
by the type of problem. So it’s much more easy
to go through them and apply the fixes
to them directly. And of course, once
we launch, we’ll be watching the
Google Search Console. This is the new one. I love it. It’s amazing. It’s much more visual. You will see how we can do
the whole troubleshooting process through it. It’s not just to check. There are the
issues, but actually to go through the issue
and fix them with that. But of course, like, I have 2.8
millions URLs that are valid. I have 36K– actually,
I’m very proud of this. Just 36K from almost 3 million. Amazing. But then again, there are so
many different types of issues that we don’t know
where to start, right? How do we do? We go through– and I love this,
because we can go and select only the actual
critical errors there, and we will only be shown those. So we will prioritize those
that are affecting more pages. So we can filter those
affecting more pages, and then go through
the ones where we want to really see
results, the type of pages that are much more critical for
us from a business perspective. Maybe the posts are not the
most important ones on our site. Maybe the listings. Maybe certain categories,
et cetera, et cetera. We can filter them
now much more easily through the Google
Search console interface, and then we can select
and go through them. We can see which have been
the last identified here, and we can go through them
and see the exact snippet in the code that has
the specific issue. And we can go through
the top 10 of them to identify the pattern there. What is the pattern that
we can identify here? The one scenario,
the one instance that is generating again,
again, and again the same type of error across all these
different types of pages. We can actually check here. We can click here because you
say, oh, but this is so weird. It looks like an
outdated version, or this is a version that was
actually not the one available when we finally launched. I don’t know how we ended
up having this indexed by Google at some point. Whatever. So you can actually go and check
the live version of the page here, as you can see,
and verify it again with the AMP test to identify
the problems are still in place or not. And then you can
share the report– that is specific report– with your development
team, across the team, the team in charge to
troubleshoot with you these types of mistakes. This is amazing
because, again, mostly what is much more
difficult here is to share the errors
in a meaningful way, to make them understandable,
to go across and give access to all the people who
need to have access. Like this, we give
access much more easily. And they will see
this page here. You see only the specific
report with the specific errors that we have shared. So they can be much
more easy to fix. Once they are fixed,
they tell, oh! They are fixed now. You can go and check. We go, check again,
and if they are valid, we have this option now
that is called Validate Fix. We click on it and
we send these pages to Google to be reprocessed,
because again, in the past, we had this problem that
we see all these legacy errors there keep appearing
in the Google Search Console. They were generating
a lot of noise, right? We minimized these
type of scenarios now by being able to have,
also, a push type of process to send them across the Google
Search Console interface. And of course, we will find
situations like this where it says, we cannot continue
with the validation process because we have found that you
still have these errors in all these URLs. So you should
continue fixing them. So it’s not just about
sending and waiting again for three days, not
knowing what is going on, if it is going to be OK or not. But they are validated, again,
and the goal, like this. And if they are being processed,
you will get an email. We’re validating the pages
that you have sent, et cetera. After two or three days,
you will get, again, another email saying, we have
specifically fixed the issues that you have specified about. And all of this is the command
pad in the Google Search Console interface, like this. When it started, if the
validation is looking good or not, when it is done,
it’s also updated there. And you will be able to see
here the evolution over time, until you get zero errors. It’s about a rinse and
repeat type of process, so hopefully you
will get here and you will see how the errors
decrease over time. And you will have annotations
on when the new issues are found and when they are fixed, too. So it’s actually pretty good
to identify the correlation of when you’ve fixed the
issues and when you actually start seeing the best possible
results, which again, will help you show how valuable it is,
your troubleshooting work, and why you should keep AMP
in place in a correct way. So it’s about validating
through the whole implementation process right from the start. And then last but not least,
this typical issue about we’re not sure which are
the queries that are generating much more
benefit with AMP, right? Do you have to
enable, maybe, all of your listings, or
all of your products, or what should be next? Maybe the block, maybe
the community, maybe the– which are the type, if
[INAUDIBLE] are giving you the type of
engagement that you’re looking for in order for
you to refine and expand to reward your efforts? So it’s about monitoring at
all the different levels. First, from an
indexing perspective, are all of these meaningful
pages that you really want to push with
AMP the ones that are being taken into
consideration in the Google index? Take a look. You can actually
now take a look, recharge those that are
effectively indexed, when they were last detected. See if they are being
refreshed as you wish, et cetera, et cetera. Then, you go to the
Google Search Console. In this case, we will need to
switch to the old interface. Yet, I have been told
that in the future, this will also be brought
to the new interface. But right now, we still have
it in the old interface. We will go to the Google Search
Console search analytics report and we’ll be able to
filter here and then reach results per device mobile. Right now, the results
will be shown for mobile and for each query
and for which page these are being
shown at the moment. The average position, the
click to rate, the impressions versus click, to
understand better the behavior when
they are included in the carousels versus
when they are included in the organic results, right? We can identify in
here the pattern. Which are the queries that
are including one of the– what are the type
of [INAUDIBLE] rates that we get through the swipe? Type of behavior when
they are included in the carousels versus the
other, et cetera, et cetera. And then this, again,
is not so natural. Hopefully, this will be also
fixed in the new Google Search Console. We can actually go through
each type of query and page to see, granularly, which
are the ones blocked by each type of page. If there’s even
more opportunities– if additional queries that
we may want to target– which are the other
topics that we want to be pushing AMP for, right? So we can go forward, go more
granularly by doing these types of questions and analysis. And not only with the
Google Search Console, because at the end of the
day, the Google Search Console will give us the data for the
top queries and pages for which we are already ranking for. We want to know the
opportunities out there. What are our competitors
doing with tools like [INAUDIBLE] or SEMrush? We can go through
their ranking indexes and we can see for any website,
for any domain that we want, which are the queries that
they are ranking and targeting with AMP results, and
how they are doing it, with which type of pages. We can do the same with rank
trackers like SEO monitors. There are more and
more rank trackers that support AMP nowadays. So for example, for
queries that you’re targeting because
you wish to rank for, but you’re still not
somehow ranking for, right? You’re maybe positioned 30, 40. You can see if they are
including AMP results like this, and if there are any
other players ranking for them, your competitors like this, too. So for example,
here, I am tracking with SEMrush my own results
and the one of my competition out there, so I’m seeing
all the SERP features are shown for these queries. And these are the
players that are actually making the most out of them. So that is a nice
way to a little bit incentivize your editorial
team to cover certain topics, certain terms with AMP pages,
if you haven’t done it yet until now. And last, but not least,
again, a lot of people ask me, Aleyda, I really
want to better understand what is the type of
specific behavior and the change of
behavior, the impact that the swipe option
and functionality has through the top stories
carousel, right? If I am included in third
and fourth position there, and people need to
swipe, what is the click to rate versus the first one? You can actually track this,
also, with Rank Ranger. That is the one
rank tracking tool that I have found that does
this really easily and is straightforward like this. For you to see the
impact of being included number one in the
carousel or number two or number three or number
four, and to better understand these
type of settings. Why not? And last, but not least,
to understand better the correlation of your
index, your rankings, and then at the end of the
day, of course, your traffic and conversions– whatever is
a conversion for you in Google Analytics. Now, there is a much
more effective way to track this with the
API through the URLs and pages shown through
the CDN, and the ones that are shown directly by
yourself to make it much more meaningful and relevant to
what is actually expected from a behavioral perspective. And better understand,
is all of this aligned with what you
expected in the first place? Is there a correlation
off of there of trends? The results are consistent
with the type of issues that you have had,
and all your efforts that you’re doing to
improve your experience and optimization
along the process. So as you can see,
it’s about following up with your AMP index
rankings and traffic to better understand
the correlation of them and track at every
single stage to identify not only the challenges
and the problems, but also the opportunities
that will allow you to continue expanding with your results. And well, there’s,
again, all the steps that we have followed. Hopefully, they will be relevant
for you, useful for you, as they have been for
me and other clients that I have worked with. And as you can see,
it’s about having a good alignment, good
project management, good communication too, and
include and validate and assess across the process,
not just at the end when all the releases are
done and then we will have all the issues to fix, right? Thank you very much. Hopefully, it’s time to
maximize your own results. [MUSIC PLAYING]