If you read my last blog post, then you know that I've been having trouble managing the SEO aspect of this blog. Not having a back-end on Github-Pages did demotivate me for a while, but finally I came along with a solution that required least efforts and works perfectly.
So, before I start with the details on how I overcame the SEO problem, I would like to mention that there are some projects that did something similar and ultimately inspired me for the approach I ended up using, one such project is prerender-spa-plugin, however, in my opinion most of these projects took an approach that was much more complex to implement. What these projects did was to integrate pre-rendering engines like Puppeteer and rendred all possible routes of their static website with it and then hosted these pre-rendered pages on the web host instead of the actual single-page application.
This approach works great with SEO and reduces load times as well for your website, however you lose that fluid experience of single-page apps that I personally admire. The pre-rendered pages lose the no-refresh navigation among different pages on your sites and you lose the route-navigation animations that work so well on SPA.
Another inspiration I got from a project on github rafrex/spa-github-pages and took it to a level further. So since SPA URLs (if not hashed) give you a
404: Page not found erorr on Github, rafrex added a
404.html page that converts the URL that user gave and converts that URL into a local SPA friendly URL and then redirects the user there. This approach takes care of having a SPA project that does not hash there URLs and still serve all the routes just fine, however it doesn't do much for the SEO.
But, I did like the redirection logic that rafrex wrote, and combined that logic with the inspiration I got from prerender-spa-plugin.
From the very beginning, I keep all the metadata for my blog posts in a shared Map object, and later I combined them with their respective markdown files to render the Blog component. Having all the meta data at one place in a shared file helped me a lot to implement my solution. I started with a simple node script that runs post-build for this angular based blog. What that node script does is read the metadata file, and create simple HTML files that only have a
head section and these head sections have 2 parts:
I call these HTML files Helmets (yes, the name is inspired by the famous React-Helmet), so when a user jumps to a URL like <domain>/blog/XYZ, the node script creates and puts a helmet file at path <domain>/blog/XYZ/index.html, so the user actually goes to the helmet file path but is redirected to angular router path from the redirect script written in the helmet file. This way if a crawler is scanning the path <domain>/blog/XYZ, it only gets the meta tags, and if a user is navigating to this path they land (via redirection) on the angular SPA. Such a simple trick does the job.
For example this is how a helmet file looks for current URL:
The redirection script detects whether it's a crawler requesting the page, if so, then redirection does not happen, since crawler only need meta tags, no need to redirect.
Here you see the hierarchy with which all the helmet files for
blog/ subroutes are created by the node script.
PS: I finally got around to implement Facebook Comments as I mentioned in my earlier blog post. Please feel free to leave a comment if you like 😜.