SEO troubleshooting with Browser Devtools
Oh, okay. That's… That's not good. Why does that happen? Oh! Hi there! Do you know that? You just tested your new version
of your website on staging, and it has technical problems
in Google Search. Well, did you know you can use your browser and Google Search Console tools for a quick first analysis before bringing out the big toolbox? Let me show you how.
♪ [music] ♪ Let's start with this website. When I checked the staging URL
with the mobile-friendly test, I noticed that some
of the content is missing in the rendered HTML. Let's find out what's happening here. We can take a look at what's happening right in the browser. When we open the website in our browser
with Developer Tools open, we get a variety of tools that we can use to troubleshoot what's going on. In the Elements tab, for example, we see an HTML representation
of the DOM of the page. We can use this to search
for content on the page and see whether it is or isn't in the DOM and where it is placed. The DOM is closest to the rendered HTML in the Google Search Console tools. In our example, we can see that the content we are missing
in the rendered HTML is also missing in the DOM! If you're not sure what the difference between source HTML, rendered HTML, and the DOM is, check out our Lightning Talk
on that topic.
The next interesting tool
is the Network tab that allows us to do
a few different things. In this tab, we can see what happens between the server and our browser. If we reload the page, we see each request
to the server and the response. We can use the waterfall diagram to get an idea of what happens and how long everything took. We can use this to learn
where time is spent. When we click on a request, we see how long the browser queued it
before making the request, how long the connection took, how long it took the server to respond, and how long it took us to download the response. If we see longer times
for connections or downloads, it might make sense to look at different options
for your service. But there's more in here.
We can also see all requests
and response headers, which allows us to look for things
like an X-Robots header, for instance. But how does it help us in our case with the missing content? Well, we can use the Network tab to search for the missing content to check if it has even made its way from the server to the browser. It doesn't look like that, though.
But what happens if I scroll the page a bit? Ah! The content seems to show up now, and it is also visible on the Network panel in Devtools. When we click on the image request, we can then go to the Initiator tab and see what requested it. In this case, main.js made the request. From there, we can even jump
into the piece of code that made the request specifically. We are being transported
to the Sources panel in Devtools and the relevant line
in the JavaScript file. We can see that this code is only running when scrolling happens. Well, the Google Search
documentation mentions that Googlebot
does not interact with pages, and that includes clicking,
but also scrolling, so our code never runs in Googlebot. We can now let the developers know that they need to find a way to load this content in Googlebot too without relying on scroll events. But the Network panel also has
a few more features as well. For example, we can disable the cache, set the network transfer speed, or other network conditions, including the user agent that we use to make our requests with.
Please note, however, that setting
the user agent to Googlebot here might not work as expected. Googlebot also respects robots.txt, which your browser ignores, and some sites might do IP lookups to see if any request really comes
from a Google data center, so you might still see different results than the actual Googlebot would see. Want more technical SEO antics? Catch me on the Search
Off the Record podcasts where we talk all things Google Search, go behind the scenes, and, who knows, maybe discuss my love for JavaScript? Yay! Join me, Martin, and the Google Search Relations elves and check us out wherever you download podcasts. All right, in this Lightning Talk, we've learned a ton
about the browser Developer Tools, so let's recap this. First things first, your browser
has built-in debugging powers, such as a view of the DOM, inspection of network requests
and responses, settings for user agent
network conditions and caching, and you can use these together with the testing tools
in Google Search Console to debug a range of issues.
I hope this was useful for some of you, and if you're interested in what
other powers Devtools could give you let us know in the comments below, and we might make another video
about the other panels too. Until then, stay safe,
have fun, and bye-bye! ♪ [music] ♪.
