The last time I benchmarked it, Google indexed static html content in about a week and dynamic JS-published content often in about 3 weeks. Frameworks like Gatsby, Hugo, and Wordpress have one or more of 3 problems: too complex, too slow, or too vulnerable, partly because of their mass appeal. So for serious SEO gains we actually stay away from them.
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.
by the way, for my own projects - with an editorial setup - I use
* headless wordpress + static site renderer
* wordpress - everything kicked out that makes it slow + caching
* hugo
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)
Conjecture: Hugo and friends generate static file sites can touch on high signal for search engines: fast load times, meaningful cross-linking, responsive templates, minimal (if any) cross-___domain loads, and new in 2020: minimal 'cumulative layout shift' and 'largest contentful paint'.
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.
Hugo’s HTML generation is very lightweight and basically outputs whatever your HTML theme template tells it to— so with a bit of work your site can be very SEO-friendly.
Agreed for the most part. Anything where SEO is critical (most things these days), we use Laravel for (trying to move away from Wordpress), with some custom classes to help standardize important SEO stuff.
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.
> I don't understand why, with React, you need to install a 3rd-party dependency just to update your meta tags.
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.
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. :)
Gatsby uses a lot of JavaScript but, importantly, the pages render without JavaScript enabled. It's just the transitions and prefetching which require JavaScript.
The point is, on my website at least, none of the transition or prefetching was being used by most visitors. About 85% of people hit one page, stayed for a few minutes, and then left. In that case all that JS is just a waste of downloaded data. That's why I moved my site to static HTML and CSS. Slightly annoyingly ever since I did that the number of users who only read one page has dropped to about 75%, but I still see it as a benefit.
I'm a little surprised that the article talks about keywords and not keyphrases. I've found those to be more valuable, especially in the long term, since they're typically harder to unseat if the keywords are too generic. I've set up a quick process for targeting keyphrases in sites and pages that I want to boost.
First, I figure out how much interest is in a phrase that is related to what my site is about. I'll go to Google and Bing and start searching for various keywords and see what autocomplete suggests. If the suggestions are relevant, I'll follow them and note roughly how many results there are and how relevant the top results are to the phrase.
Next, I'll go to trends.google.com and compare the most relevant phrases to see how many searches are being performed for each. Then I compare that against the list of quality results to see where the biggest gaps are. That helps me to identify the phrase that I want to target.
Then, I'll plug the phrase changes into the page that I want new users to land on (typically just the homepage, but this can sometimes be a particular section or article, depending on the site and its goals).
Then, I'll go to seowarp.com and throw the page through a Full Scan which reports on phrasing information. Near the bottom, there's a "Duplicate Content" section that will compare similarities between pages, so if there's anything that is textually similar to my target page, I'll adjust it to drive more attention to the target one for relevancy. I'll also do a Single Page scan for my target page. The results of that scan will have a "First Five Targetted Keywords Detected" section that will show any keyphrases that are found on the page. Again, I'll make sure that my target phrase appears and cull any others that might be taking away any attention from it.
After that looks good, I'll distribute links to the page that contains the phrase. Usually I'll see results start popping up within a week, but can take longer depending on the strength of the campaign.
People (even SEOs and other search marketers) often use keywords and keyphrases and keyword phrases interchangeably, and mean ostensibly the same thing.
I used to provide consulting services to small companies and site owners. I became much more focused on web development, but SEO experience has been helpful in a number of ways since.
The biggest case I can remember is a former employer who ran a niche search engine. They were trying to get ranked anywhere, but almost never showed up in any results. It didn't take too long to see what was going on. It turns out that a developer had plugged in a regular expression to generate a canonical link on any given page. However, this regex was case-sensitive and was only whitelisting lowercased letters. So when you would go to the page "/job/12345/Data-Engineer", it would tell search engines to go to "/job/12345/ata-ngineer" instead. The link would still work since the site would use the "12345" portion as the page's ID, but nobody was searching for "ata ngineer". Literally just putting the letter "i" in the regex's flags was enough to start ranking on the first page for a large number of the company's listings (though reindexing took several weeks since the problem was large and existed for well over a year at that point).
Note that the article is about optimizing a Gatsby site for SEO; it's not a general SEO tips site, of which there are many.
With that said, it's quite amusing how small SEO changes can dramatically improve search visibility. It's one of the reasons why I point people to using Wordpress + SEO plugins like Yoast, which deal with most if not all of these edge cases automatically.
> It's one of the reasons why I point people to using Wordpress + SEO plugins like Yoast, which deal with most if not all of these edge cases automatically.
This is pretty good advice, though what we see more commonly is that Yoast is misconfigured (or not configured at all), which causes more problems than it solves. Another thing that happens is solutions like Yoast will throw lots of errors that actually don't matter because Yoast's goal is to drive interaction with Yoast. It's not always easy to make the distinction.
But yes, for a lot of people "just use Wordpress" is a good solution, and an attentive Yoast install can be super helpful!
Are there any of these that are any good? I know next to nothing about SEO and would love to learn a bit more, but I've never found any useful resource that isn't some kind of crappy spam-blog or so old that I'm left doubting if the information is still relevant.
> I know next to nothing about SEO and would love to learn a bit more, but I've never found any useful resource that isn't some kind of crappy spam-blog or so old that I'm left doubting if the information is still relevant.
I like the look and design of your site, what did you build it with? Also if you were building a performant SEO landing page what tech stack would you use? Great extension.
Thanks, it's a minimal custom CSS theme I wrote on top of Jekyll (static site generator) hosted on Netlify. Any static site generator would work though. I'm using SVG for almost all images as well as minimal JavaScript which helps with performance.
I've been reading SEO-theory for years: https://www.seo-theory.com/
His paid newsletter is a great and is reasonably priced ($30 PM for 5 issues per month). He cuts through a lot of the bullshit which plagues the SEO industry.
You’ll learn more from subscribing to his paid newsletter for 6 months than a lifetime of reading blogs like Moz, AHrefs or SEOroundtable etc.
If you’d would like to know more about what he's about just read a few of his blog articles.
This is sort of table stakes in the SEO world, not end all be all. First you must get these technical details ironed out, and then from there you have to focus on two things that differentiate you from competitors who also have the bases covered:
1. Backlinks - I cannot overstate how much a quality backlink can do.
2. Good content/utility
That's pretty much it but it's obviously easier said than done.
So, instead of worrying about installing plugins, time would be better utilized getting backlinks -- which, I'm not sure exactly sure how you do. You can't force people to share your content, but you can create content that's hopefully worth linking to.
They're not comparable. Plugins is basically a O(1) task: You set them up once and then they're done. If your set isn't set up for technical SEO then crawlers can't read it and you won't rank well. But once you're set up correctly and it's not really possible to put more time into managing plugins and rank better.
By comparison, building backlinks and writing content you can always sink in more time, and derive benefit from that extra time investment. So the plugin stuff is more like foundations. You need it, but it's not what your strategy is.
And "building backlinks" is a lot about outreach. You need the content worth linking to, but there's also things you can do to encourage people to link to content that they already like. Relationships with other sites, encouraging people to tweet/like/reddit/socialwhatever your content, that type of stuff.
I've worked with good content/SEO teams. Generally, they try to make interesting content, then they hire folks offshore to promote it. It's a low hit rate, but it works over time.
Another "technique" is to crawl sites that link out to 404s, or outdated guides. Especially if it's a high value site. Then email them and suggest their users might prefer <insert better widget/site/etc that you own here>.
No, you should install the plugin as it will bring your site up to a good base level of SEO quality - you’ll still need to fill out texts and images but the plugin will tell you where and what you need.
Generating backlinks is a skill you can aquire, but devs tend to sneer at it since a) it looks a lot like sales and b) there A LOT of shady practices
The point of an SEO plugin would be to help crawlers understand your site, like handle link canonicalization, improve <title> tags like "Hacker News" -> "Foo's profile - Hacker News", and things like that.
It ("on site" SEO) has zero bearing on what other websites are doing. SEO is just an umbrella word that also encompasses "off site" SEO like backlink building.
I wouldn't say it's the trick to "good" SEO, more like the trick to "not bad" SEO.
Managing on-page technical factors (which is what a plugin can help you with) is primarily a matter of successfully missing your foot with hundreds of potential bullets.
Getting SEO to "good" still requires good content and link building.
I thought there would be some SEO tips in the blog post, but it was entirely about some weird issues in Gatsby and Netlify, two technologies which I’m not using. There was nothing about SEO.
I coded a chrome pluign called "SEO Live Test" previously "Obtrusive Live Testing Framework".
It collects the live cycle of the page load, including static Dom, Dom ready Dom, JS executed Live Dom and runs various tests on those (plus some on the collected HTTP responses). All of the issues outline would have been fetched. Tests can be extended so any special cases minded.
This looks really cool! I’ll definitely be checking it out. I’m fairly new to SEO so this may be a beginner question- what is the benefit of using this plug-in versus using the built in dev tools Lighthouse tool?
on top of my head: canonical check, ending slash / no ending slash collision check, GSC traffic check, noindex check on HTTP&HTML level, rel-alternate cross-page check, title tag best practice check, highlighter of parameterized URLs, internal link spot checking check, static dom vs rendered dom comparision
The post is interesting but what I find a bit annoying with all the posts around SEO is that at the end, I just feel like I have to become a curator for the search engine in order to reach my audience.
At the end it shouldn't be like this, it's the search engines responsibility to surface the right content for the right audience.
I wish we had as many articles about how to communicate ideas in a more clear way as we have for how to annotate correctly your html code for the search engines.
I have been doing SEO professionally for just over a decade at this point. I've seen that trailing slash issue on more sites than I care to count. It's especially fun when people link to the wrong version of important pages in their nav and footer creating 301'd links across their entire site. An easy fix, but frustratingly common oversight.
I know the author is probably scratching their own itch there, but articles like this make me appreciate my WordPress blog. I don't have to think twice about this stuff. Especially if my main goal with the blog is to grow an audience and not learn Gatsby.
Interesting. Do you include websites built using SSGs like Hugo, Gatsby in your statement? Also, any tips on how you handle security (with minimal maintainence) and page-load performance in Wordpress?
Security is always the trade off, and I don't have any good answers to that problem (aside regular maintenance).
The websites I'm thinking about, though, tended to be marketing websites ('microsites') for large consumer brands, that really didn't do a great deal functionally, and didn't need particularly robust security in the grand scheme of things.
Even though I'm a web developer and have used various static site generators in the past, I never liked them too much because they seem like more work for me. I prefer dynamic CMS for a number of reasons. Having said that, I believe that things like WordPress can do too many things and are overkill for many people who just want to publish content on a blog. So I built DynaBlogger (https://www.dynablogger.com/), a simpler alternative with the most needed features and no bloat.
I also like dynamic CMS more than static websites, there is something really cool about being able to access your editor and directly update your content. Of course things don't have to be black or white, I'm using Grav, it's a lightweight CMS that uses static files for its content and generate a static cache when something change, so you technically only serve static content but still have the benefits of having an admin UI to manage your website and content.
I just signed up and received an email confirmation, but the link was white so I couldn't see it. I had to move my cursor where I thought it was until my cursor changed. I'm using Outlook on Windows 10 if that helps.
This article pretty much sums up why static site generators are such a pain in the ass.
If you're just starting in your static site journey after moving away from something like Wordpress, you'll probably feel like you discovered the holy grail for a while. Yes, Netlify is amazing at first, and yes, it's a pleasure to build sites without fighting a wonky old-school PHP CMS.
However, this will wear thin after you start to care about creating regular content and the nuances of SEO (as the person who wrote this article discovered). I've gotten SSG fatigue over the last couple of years and have completely switched over to building marketing sites and blogs in Webflow.
No worries about build process, no setting up SEO from scratch every time, no wiring up a wonky headless CMS and building rigid content models, no writing blog posts in VScode and then forgetting how I set up my front matter, no PITA trying to set up a new section on your site and then realizing it breaks your headless CMS wiring, Etc. etc.
I do exactly the same with Hugo. I have a barebones template that is ready to go in a minute. I don't use Netlify but rsync public folder to server directly.
I checked my own website for these issues (trailing slash canonicalization, canonical links in <head>) and it seems like Hugo (or the template I started with) handles all of this for me.
The biggest issue I had with SEO was page speed. Google demands fast, secure website, unless you're already large and authoritative.
The second was to neglect link building. Google wants authoritative websites. It also helps to be at the end of everyone's navigation path, no matter what they look for.
For everything else, there's the Google Search console.
Google Search: Surprisingly smart in some ways, surprisingly dumb in others.
And this sort of thing doesn't just make a difference in indexing, but also in other places like analytics – Google Analytics will see a page with a slash and no slash separately, for example, which makes it hard to get an accurate picture of what's performing.
OP/Author here, yes looking into NextJS to migrate my blog over. I loved Gatsby at the beginning, but it's very time consuming to maintain on the long run, especially with all the plugins (I started removing those and rewriting some of them)
Hey OP/Author here, I just fixed this! I recently added some shortcuts, like a week or so ago, and this one went under the radar. Apologies for the inconvenience, and moreover, thank you for your comment without it I wouldn't have noticed
Great article! I've had issues getting my Twitter links to show an image and hopefully this will help. Honestly it shouldn't be this complicated and Gatsby should have a more robust SEO component.
Thanks for writing this - I love to see SEO advice that is actually about the content and structure of your pages, and not about playing the SEO games.
Hey OP/author here, can you tell me a bit more about the issue? I've asked around and it seemed to work as expected on mobile.
Would love to know more about what happened in your case
- Make sure you either never have trailing slash or always have trailing slash (make sure you have canonical pages and redirects as little as possible)
- Have canonical pages
- Don't trust code you haven't read/don't understand
- Make sure you view changes you make and that they are actually made when you think they are
- Make sure what you want to be rendered on the page is actually rendered
- Write tests
Seems like a bunch of tips for people who are just starting out with web development, to not miss the most obvious problems. How this post is currently on the top of the front page will forever be a question for me. I'm glad more people are discovering SEO and it's importance, but this guide is specifically for one technology and are general tips about development rather than SEO really.
Call me old-fashioned, but when I look at the source code of a web page designed using the "modern" frameworks, it looks like a horrible mess of JS/CSS with very little actual content. E.g. take a look at this guy's code snippet's HTML source in the middle of the page - it's just a wall of <div>s and <span>s, for every single visible character.
The search engines these days cannot even function without a JS interpreter, something that surely increases the complexity and cost of building one.
Long gone are the days when one cared about semantic elegance of HTML code, per-site optimized CSS stored in an external file for easy caching, only occassional use of JS for easier navigation...
Nowadays you don't build websites, you have to build "apps". It's one of many signs of the "appification" of Internet.
I generally agree that the web could be simpler. A lot can be accomplished with just plain ol' HTML/CSS nowadays. I think there's a kernel of truth in what you're saying about apps vs. websites.
That said, how would you propose to do syntax highlighting instead of
> just a wall of <div>s and <span>s, for every single visible character
? Rather than being a wall, it looks to me like it's actually a tree of <divs> and <span>s for every line and every _token_.
I think the author has used Prism[1], so I assume the highlighting was done client-side, but even if you were to do the task server-side I think you'd end up with similar HTML/CSS, no?
What would be a better approach to solving the same problem?
Gatsby doesn't offer a syntax highlighter out of the box. It has markdown (and MDX) components that generate pages, and those in turn can have syntax highlighting plugins. AFAICT prismjs indeed is the predominant one used by Gatsby sites (at least, in mine). But thanks to SSR prismjs will typically run at compile time.
Of course you'd use spans to do syntax highlighting, just like you'd use JavaScript to do interactivity. You know what the commenter means–using these in places where they aren't necessary at all.
The commenter specifically used that tree of spans as an example of the horrible mess that is modern HTML. So it is necessary here to deliver the feature, and I think the broader point is that we might see a mess in the DOM inspector, but it is a requirement to deliver certain modern features in a productive way.
Like normal text on a page? No. For one very specific thing that it's useful for? Of course. If it wasn't useful for something it wouldn't exist, the issue is using it for things that it has no reason to be used for.
The code snippet seems like the only part where individual words are wrapped in their own divs or spans. It's not true that the whole article is like that. It seems like the article has reasonably semantic html elements present, just with minified CSS classnames and maybe a couple extra wrapping divs at the top.
I'm not the one who called out this site, and this one "OK" with its semantic HTML for the article content (though outside of that it has a bit more soup than it probably needs). It does render a bunch of stuff with JavaScript though so that's not great :(
So what? Web pages can do more than they used to. Engineers of yore similarly decried the ugly machine code generated by compilers. The HTML and CSS our browsers download are targeted at browsers, not humans.
If someone writes a buggy, inefficient C program, we fix the bugs, we don't abandon C and rewrite everything in assembly because the resulting machine code is prettier.
> If someone writes a buggy, inefficient C program, we fix the bugs, we don't abandon C and rewrite everything in assembly because the resulting machine code is prettier.
Several languages have popped up to address buggy, inefficient C programs and the problems they cause.
It works great with Lynx (text-based browser in the terminal), which indicates it's at least usable by screen readers. Bonus points for not making me scroll past a horribly formatted list of links at the top of the page. I see your point, but at least give the credit for the tooling that generates an accessible text-based experience for those who prefer it. I'd rather have a few good tools that generate something reasonable and consistent than a wild west of everybody hand-baking their own personally flawed interpretation of the standard.
I have to agree. If you try to visit the site in the OP without JavaScript enabled, it doesn't even render correctly. There's little reason for a static blog to be written as a client-side web app.
I visited the page with NoScript turned on and it looked the same. All the HTML is sent fully rendered by the server, so there shouldn't be any reason to expect that JS would be necessary to show the page.
I recently required from the IT team a HTML page intended to be readable on everything. It is a simple instruction with 3 headers.
They came up with an app, full of JS. Don't get me wrong, I write apps for my own use (quasar / vue) so I like frameworks, but I wanted a simple plain page.
Since they wanted to use a framework, I asked them to use https://motherfuckingwebsite.com/ as the template and after some initial gasps of horror we had a working web page.
There are many people using static site generators like Hugo to output clean HTML like you describe. I find Hugo’s approach to static sites produces much cleaner/smaller HTML than Next.js or Gatsby because you’re in the mindset of thinking about the direct output of the templating language as opposed to JSX syntax which abstracts away the raw HTML.
It’s perfect for personal sites, landing pages, documentation, etc.
Nothing about Gatsby or React by itself gets you non-validating HTML. The article has some W3C validation errors, but they seem to be caused by a few CSS errors they made themselves, the choice by their chosen CSS framework to put <style> tags for components directly in the page body next to their component elements, and their chosen code highlighter's choice to use <div> tags inside of <pre> tags. I find it surprising those two tools do that, though I wouldn't describe those issues as having anything to do with the rest of the ecosystem. (I have a Gatsby site using the component CSS library Styled-JSX and the code highlighter PrismJS which don't have those issues, and the site only has a few validation warnings that are purely from my own html. Apparently <section> tags are expected to have headers.)
microsoft.com, apple.com, a number of large "IT" companies have websites that throw W3C validator errors. I wonder whether there's a few that are completely valid..?
This. The elegance valued by so many in discussions seems so redundant when you think of how 99% of the machines that consumes the code will fail to appreciate it. The machine couldn't care less whether your actual header was a header tag or a div tag, and to then optimize for the things the machine does care about can result in horribly ugly code. And the reader of the page sees none of the code.
> The search engines these days cannot even function without a JS interpreter
I wonder if at some point while building a JS interpreter in the early days of Google for search reasons, they realized that the interpreter they spent all the time on could be packaged into a new browser to compete with Internet Exploder.
Maybe instead it was all a conscious decision at the beginning.
Every web developer in the 2000s was a PHP dev. To a man with a PHP hammer, everything looks like a PHP nail. Hence Wordpress (although, I must admit Wordpress's plugin ecosystem was genius).
Every web developer in 2020 is a React dev. To a man with a React hammer, everything looks like a React nail. Hence, Gatsby.
In neither case did it really make sense to build simple marketing sites and blogs with those technologies, they are best suited for dynamic web apps.
But, the technology that all the devs want to put on their resumes will ultimately end up powering everything. Common sense be damned.
After the static site hype dies down I am hopeful that Webflow will become the defacto solution for marketing/blog sites going forward and the design/marketing teams can fully own them and manage all changes. I'd be happy if I never had to touch another marketing site again.
“Site builders” like wix, Squarespace, etc. are basically all the same. They sandbox you into a selection of annoyingly rigid templates and a dumbed down UI and abstract the important stuff away.
Webflow is more of a “visual coding” platform. If you don’t know basic html/css you’ll have a hard time using it. It spits out static sites on the front end with proper readable html/css and SEO.
It’s a bit of a steep learning curve to get the hang of their UI but after a few hours, building things is insanely fast and you have control over everything.
I rebuilt my company’s entire site in it in about 4 hours and was blown away how easy it is to update things.
I’ve heard pretty much all YC companies are now using it to build their marketing sites because of this.
Comparing to other static site generators, you might as well ask how we ended up in a place where we "need" Jekyll, liquid templates, and ruby to build a static blog. Static site generators are great for maintaining static sites with many pages that share templates and commonly-reused components, and React specifically is basically an HTML templating language that just also has the ability to run the same code on the client and update the page while it's open, which is really useful if you have any dynamic bits on your page. It's true there's some stuff downloaded and processed on the client that's dead weight if you're not actually using any dynamic features, but it's asynchronously downloaded and the page successfully does its initial render before that and it's about the size of an image or a font, so I think worrying about it in most cases is a bit overblown.
I guess you got downvoted because the main point of the article is SEO, not react/react-helmet/graphql... Although I have to admit that I asked myself the same question.
I love how react-helmet is a super useful pervasive library with like 14k+ stars on GH developed by the NFL... it’s called helmet. It does the head stuff... I think it's brilliant. I know I'm like 6 years too late for the javascript hype but I'm just happy that's a thing.
The only mistake I made with SEO was to do SEO in the first place. The way Google ranks pages makes today no sense. It is a waste of time doing SEO because above everything else, anyone who has more money will be higher and you can't change that. No matter how good content you have. I have more time to focus on what really matters when I ignored SEO and Google. At this point I don't care if it will index my website or not. It does not have any impact at all.
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.