 Hello and welcome to another webmaster conference lightning talk. This time, as you can see, recorded from home. In this video, we will discuss how to make sure that your single-page application is discoverable via Google search. Before we dive in, let's recap what a single-page application actually is. Unlike a regular website, a single-page app uses JavaScript to control the page's cycle. JavaScript is typically used to create the HTML that creates the page and also uses JavaScript to load other content when users are navigating to other parts of the single-page application. These are often called views rather than pages. This technique allows us to load views without the browser doing a full reload and allows us to use custom transitions between the different parts of the application. Single-page apps might use an architectural pattern called the app shell model, where the shared parts of the UI and code, like menus, headers, footers, and so on, are loaded when initially loading the single-page application. And the different views are dynamically loaded into this shell, reducing the amount of data needed to send over the network. OK, so what do we need to look out for when building single-page apps? I think it is time to look at our sample app, test it and then improve it where we see potential. Our example application is an e-commerce web app, a cheese shop. You can browse different product categories, learn more about a specific product, and you can put it into your cart. It also uses the user's location to display prices in the local currency. When we run the mobile-friendly test, there is a bit of an issue. The main content doesn't show up. Time to investigate this. In the JavaScript console messages, we can see that there is a problem with our code. We are incorrectly using an unsupported feature. That's an important point here. Because we do forget that code doesn't always take the happy path. In our example, we assume that we always get the user location. But we forgot to deal with situations where that isn't available. It's important to make sure that you cover all code paths to avoid these scenarios. Googlebot, for example, declines the request for the geolocation. I also noticed something else when using the shop. It does not change the URL when navigating between different views. But as Googlebot uses URLs to locate these different pages or views in our case, this would mean that Googlebot would only see our home page and nothing else. To fix this, we can use the history API and proper link markup with href attributes to expose the other views as URLs within the links. It's also a good idea to take a look at the titles and meta descriptions for our different views. Right now, all views have the same generic title and meta description. This isn't really helpful when people are searching for the one specific product or a specific category in our shop. With a little bit of extra JavaScript, we can fix this quite quickly. Ah, nice. This will look much better in the search results. A very common problem is the way that single page applications are dealing with error scenarios, such as invalid URLs. In our example, the application displays an error message, but the server reports an HTTP 200. That is a bit of an issue, specifically in single page applications, because the server doesn't really do the error handling anymore. Only the server serves the web app in all cases, and then the JavaScript in the browser decides if it wants to display an error. But HTTP status codes do help Googlebot and browsers decide how to deal with a response. So we should fix this. Here's the JavaScript that deals with the error situation. It reads the URL and fetches the data, and if that fails, it displays an error message. But we can't just tell JavaScript to report a different status code, because the status code can't be changed once the server sent it. What we can do, though, is to configure our server to respond with an error code for a specific URL, like slash not found gives a 404, slash maintenance gives a 500, and so on. When we do that, we can use JavaScript to redirect to the designated error URL. This signals to the browsers and Googlebot that the page is just a redirect to another URL, and this URL is an actual error. Alright, now our webshop can be crawled and indexed, gives useful product information and search result pages, and behaves properly when there is an error. If you are interested in learning more, do check out the links for a tutorial, our documentation, JavaScript SEO video series, and like and subscribe if you want to see more videos like this. Thanks for watching, have a great day, bye!