Such as ? ...
I am part way through this, just trying to get a holistic view.
also if you have feedback, hit me up anytime via "fe (at) f19n dot com"
for bigger projects by now next.js became very popular - and works if you start with a webperformacne/speed focused approach
but you can search engine optimize everything (that does server side rendering / that is not client side only), well everything but TYPO3 (a CMS cancer in Europes German Speaking Markets)
Not to say that you couldn't construct some monstrosity of a site with Hugo, but you're more likely to do that with a mess of half-maintained Wordpress plugins.
I haven't had that experience with Hugo, but I pushed the files up to S3/Github Pages/Netlify and had them served from there. I'm a big fan of the concept.
I've had a great time with Gridsome, the VueJS version of Gatsby. I don't understand why, with React, you need to install a 3rd-party dependency just to update your meta tags. Like, it should either be part of your main layout when you set up your site (my Laravel approach), or there should be a built-in configuration for it, like Gridsome has (https://gridsome.org/docs/head/). Every site needs this stuff, so it should be a first-class feature.
You don't. This seems to be a common misunderstanding. You're free to and should write your meta tags (and everything else inside the head tag) in plain React components. It's enough to do this on the server side, but the document title should be updated client side, too. React-helmet is an antipattern.
I get 98 on all lighthouse scores.
This may not be true for your website, but on many Gatsby-driven websites there's heavy reliance on JavaScript that doesn't actually add very much. The really good thing about Gatsby is that it makes moving between pages more efficient because it only downloads the content that changes and then it leverages React to seamlessly transition the parts that change when you move from one page to another. It does that really well. The problem is that a lot of websites that use Gatsby are blogs, and that's not how people read at blogs; most of the time people go straight to a page from Google, and then go back to Google after they've read that page. They don't move around the website. All that JS to make that happen nicely does nothing.
That's certainly the experience I had when my website was Gatsby based. I was sending people a chunk of JS that that just didn't benefit from. If Gatsby suits your visitor model then it's a great tech choice, but I found that something even more static (11ty in my case) worked better for people who came to my website.
Also, for what it's worth, I get 4 100s in Lighthouse. :)
This blog issue illustrates the too-complex problemof Gatsby - you don't find out about some minor configuration error until it gets indexed weeks later, and you lose substantial business due to the long feedback loop of SEO. Add to that the long compilation time, and you're looking for alternatives soon after investing massive resources in a setup.
Hugo had a different problem the last time we tried it. In a test setup we did, a small configuration issue spewed your entire server and configuration data to anyone who visits a 404 link. Any issue with the setup created the volcano of sensitive data vulnerability. Didn't take the time to dig in any further.
Wordpress is a behemoth, but because of that and slow hosting service providers it is incredibly slow to use on a hosted shared server, without caching. On top of that thousands of bots on the web are looking for and sending post requests to Wordpress admin files or php plugins (even if you're behind Cloudflare).
There are faster and more performant ways to SEO, especially if you can code.