Diagnosing common JavaScript SEO issues and helpful steps to debug them!
Resources: Understand the JavaScript SEO basics → https://goo.gle/31klLBX
How Google Search indexes JavaScript sites - JavaScript SEO → https://goo.gle/383VQji
Related Playlist: Day 1 → https://goo.gle/WDL20Day1
Subscribe to the Chrome Developers → https://goo.gle/ChromeDevs
Speaker: Martin Splitt
#webdevLIVE #javascript
Hi, everyone. Thanks for watching this session on debugging, JavaScript, SVO issues. In the next 15 minutes, I will take you on a short journey in which we will talk a bit about the various that a few CEOs still have about JavaScript and Google search. Then look at the tools available to our CEOs and developers and then get our hands dirty on a few case studies from the real world. Now, let's get started with looking at the basics. Can MCO and Javas could be friends? There is a bunch of history behind this that contributed to various opinions and answers to this question. Today, the answer is generally yes. Sure. As with every technology, there are things that can go wrong. But there's nothing inherently or categorically wrong with JavaScript sites and Google search. Let's look at a few things people tend to get wrong about JavaScript and search. The number one concern brought up is that Google does not support modern JavaScript or has otherwise very limited capabilities in terms of JavaScript features at Google I. O 2019, we announced the evergreen Google bot. This means that Google about uses a current stable chrome to render websites and execute JavaScript, and that Google bot follows the release of new Chrome versions quite closely. Another worry is concerned with the two waves of indexing and the delay between crawling and rendering go about renders all pages and the two waves were a simplification of the process. That isn't accurate anymore. The time pages spent in the queue between crawling and rendering is very, very short. Five seconds at the median. A few minutes for the 90th percentile. Rendering itself takes as long as it takes a Web site to load in the browser. Last but not least, be wary of buying canned statements that pain JavaScript. As the general SVO issue, well, some search engines might still have limited capabilities for processing JavaScript. They ultimately want to understand modern Web sites, and that includes JavaScript. If JavaScript is used responsibly, tested properly and implemented correctly. Then there are no issues for Google search in particular, and solutions exist for SEO in general. For example, you may consider server side rendering or use dynamic rendering as a workaround. Further crawlers when saying test your site properly. The follow up question is usually, well, how do I test my site properly? And luckily we have a whole toolkit for you to test your site for Google Search. Let's take a look at what's available. The first tool in your tool belt is Google search console. It's a super powerful tool for your Google search performance, besides a ton of reports. It contains the oil inspection tool that lets you check if the oil is in Google search. If there are any issues and how Google board sees the page. The second tool that is really helpful is the rich results tests. It takes any URL or lets you copy and paste code to check. Its main purpose is to show a structured data is correctly implemented, but it has much more to offer than just that. Last but not least, the mobile friendly test is similar to the rich results test. On top of the rendered edged him out. The standards of all embedded resources and network requests. It also shows in a the full screenshot of the page as well as possible mobile user experience issues. Now let's take these tools for a spin. I have built three Web sites based on real cases that I debugged in the webmaster forums. The first case is a single page application that does not show up and will add all. As I am not the owner of the domain, I don't have access to Google search console for the side, but I can still take a look. I will start with a mobile friendly test to get a first look at the page and question. As we can see, the page loads, but shows an error message. When I load the page on the browser, it displays the data correctly. We can take a look at the resources Google board tried to load for this page. Here we see that one wasn't loaded. The API unexampled exampled dot org slash products, your URL wasn't loaded because it's blocked by robots to 60 when Google renders it respects the robots cheek's t for each network request it needs to make the HD mail, CSX, JavaScript images or API calls. In this case, someone prevented Google bot from making the API call by disallowing IT and robots to its T. In this case, the web app handles a failed API request as a not found error and shows a corresponding message to the user. We caught this as a software for and as it is, an error page. We didn't index it. Take note that there are safer ways to shore for a four page in a single page app, such as redirecting to a URL with a four four status or setting the page to no index. Right. We solved that one. That's pretty good. All right. Onto the next one. This one is described as a progressive Web app, or PWP, that didn't show up in search except for their home page. Let's go find out why. Looking at the home page, it looks all right. The other views on this progressive Web app also load just fine. Let's test one of these pages. We will use the mobile friendly test again to get a first look at what's going on. Oh. The test says it can't access the page. But it worked in the browser. So let's check with our dev tools. In the network tap, I see that I get a two hundred stable's from the service worker, though. What happens when I open the page in an incognito window? Woops. So the server is not actually properly set up to display the page. Instead, the service worker does all the work to handle the navigation. That is good Google, but has to behave like a first time visitor. So loads a page without the service worker cookies and so on. This needs to be fixed on the server. Great. Two Web sites fixed, but I have one more to go. This one is a news Web site that is worried because not all content can be found via Google search to mix things up a little bit. I'll use the rich results test for this one. The website doesn't seem to have any obvious issues. Let's look at the rendered HMO. Mm hmm. Even that looks fine to me. So let's take a look at the website in the browser. So a loads 10 news stories and links to each news story and then loads more stories as I scroll down. Do we find that in the renovates Jamal to. Interesting, this story isn't in the renot age time out. It looks like the initial 10 stories are there, but none of the content that is being loaded on scroll way. Does it work when I resize the window? Woops. It only works when the user scrolls. Well, Google doesn't scroll. That's why these stories are loaded. That's not exactly a problem. This can be solved by using an intersection observer, for instance. Generally, I recommend checking out the documentation at developers. So Google comes left, search for much more information on this topic and other topics. I hope this was interesting and helped you with testing your Web sites for Google Search. Keep building cool stuff on the Web and take your.