6.3 Polishing your Firebase webapp - indexing and SEO (Search Engine Optimisation)
Last reviewed: September 2023
1. Introduction
SEO - Search Engine Optimisation was introduced briefly in post 6.2 in the context of Google's "Mobile First" policy. That post gave guidance on screen layout designs intended to ensure prominence in Google search returns. It's now time to look a bit more deeply into this and examine how search returns get into the search engines in the first place.
In the early days of the web, Search Engine indexing of your site would have happened automatically. Once your html files were saved on a public server they would be regularly reviewed by "search bots" deployed by Google and the like to crawl the web looking for information to put into the indexes that drive their search engines.
Google's SEO Starter Guide shows how, once you've carefully filled out the header information in your html file, potential users of your site will be able to use Google searches to get its url. The bots are also able to look deeper into your site and add more general site content from <p> elements and the like.
But in a modern webapp, while there will still be an html file with a <head> section, general site content is likely to be tucked away in remote databases or local internal storage. While the javascript or React code that links everything together will eventually generate <p> elements etc, these are not directly available to the indexing bots as they were in the past. How is this ever going to work?
2. Getting search-engine index entries for a Javascript webapp
Fortunately for modern Javascript webapps , the search bots now actually simulate the actions that a user might take in running a webapp. They launch a "headless browser" - ie a cut-down version of something like Chrome or Firefox - to "hydrate" the webapp and then analyse the resulting DOM.
"All" that you then need to do is to guide the bots by providing a list of the pages that you'd like it to examine. You do this by constructing a "sitemap" file. Here's the sitemap.xml file for the index site for these posts.
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://ngatesystems.com/about</loc>
<changefreq>weekly</changefreq>
<priority>0.5</priority>
</url>
<url>
<loc>https://ngatesystems.com/waypointsindex</loc>
<changefreq>weekly</changefreq>
<priority>1.0</priority>
</url>
<url>
<loc>https://ngatesystems.com/examples</loc>
<changefreq>weekly</changefreq>
<priority>0.6</priority>
</url>
</urlset>
This should be placed in your webapp project'spublic directory alongside your index.html file so that it is deployed into the root of your Firebase project.
Google's Google Search Console tool gives you a mechanism for directly initiating and and monitoring Google's use of your sitemap.xml file. This tool also enables you to track the performance of Google searches on your site - see Google's Basic Search Console usage document for advice on how to use the Search Console.
You might be interested to note that it is also possible to initiate scanning of individual pages directly using the Search Console's URL inspection tab. This seems to produce a near instant response (whereas you can wait weeks for a sitemap submission). The inspection tab can also show you the rendered html code that it has used - a huge confidence booster when you're building this via props and JSX.
Of course the ultimate test is to do a search yourself to see what Google knows about you. When testing my own index webapps I found that the best way of doing this was to do a Google search on site content. So, for example, once Google had indexed my site, a search for "Github is a free Microsoft service that gives you somewhere you can store and advertise source code on the web." - a quote from the site's "Examples" page - instantly returned the site's url. I'm still struggling to comprehend how Google can do that, especially when I recall that that particular chunk of text isn't even coded in html - it's buried in a Json.
I think I should mention however, that I had no success on getting index entries for the site-index webapp while it was still using its initial, free, Firebase url at ngatesystems.web.app. Indexing on my site only started to work after I paid Google £10 to register my ngatesystems.com domain. I don't feel aggrieved about this - this was after all a ridiculously small payment for the amazing service that they provide.
3. SEO - Search Engine Optimisation
A lot depends on getting your site really well indexed. If people can't find you easily they won't use you. But it's not just a question of obtaining a mention in search-engine indexes. Once you're well-indexed you'll want search "hits" for your site to be listed prominently. Welcome to the world of Search Engine Optimisation - the art of ensuring that search engines respect your site.
I've already provided a few hints about how you might convince Google that your site is worth its attention. Google's "mobile first" policy indicates one example of a way in which you can influence their opinion. But this is a deep and complex subject.
If you've used React and React Router to develop your webapp, you might find it useful at this point to have a look at my recent post at Highs and Lows of a Firebase/React Development. It seems that the "hydration" of dynamic pages by "headless browsers" may not always be complete. Also if you want discrete pages in your webapp to be indexed in their own right, you will need, in any case, to pay close attention to the way you serve <head> information to these pages.
Further, if a lot depends on the success of your search indexing, you may need to look at a design model that serves "pre-rendered" pages to the browser rather than the dynamic javascript that has been the standard described thus far. This would imply the replacement of the familiar "Client Side Rendering" (CSR) arrangements by "Server Side Rendering" (SSR) technologies. See Next.js and CDN for more background on these ideas.
Top comments (0)