[dzink]

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.

[helij]

What kind of a setup you had with Hugo to do this? I compile and ship to a server. Why would Hugo handle 404s? That's a job for a web server.

[eloff]

Yes, he shouldn't be running the dev server to serve his static site as a dynamic site in production. That's missing the point of Hugo.

[dzink]

That was after configuring HUGO on localhost and customizing its theme.

[lifeisstillgood]

>>> There are faster and more performant ways to SEO, especially if you can code.

Such as ? ...

I am part way through this, just trying to get a holistic view.

https://www.fullstackoptimization.com/b/understanding-seo

[franze]

thx for the reference. I posted the free download link to the book here https://news.ycombinator.com/item?id=24773941 + plus the first 2 chapters as a PDF dropbox link

also if you have feedback, hit me up anytime via "fe (at) f19n dot com"

[franze]

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)

[vaccinator]

Hugo is not complex from a search engine's point of view, it generates static files...

[erichurkman]

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.

[3131s]

Is the HTML that Hugo generates semantic and does it contain the usual metadata that search engines use?

[chrisdalke]

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.

[aliceryhl]

This is up to the template files.

[duhi88]

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.

[maerm56]

> 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.

[ceesharp]

What's exactly wrong with Gatsby?

I get 98 on all lighthouse scores.

[onion2k]

What's exactly wrong with Gatsby?

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. :)

[robjan]

Gatsby uses a lot of JavaScript but, importantly, the pages render without JavaScript enabled. It's just the transitions and prefetching which require JavaScript.

[onion2k]

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.