Google routinely says how things are supposed to work, but there are plenty of examples where their crawlers act inconsistent to public statements. To be clear, probably not Googlebot's fault though; we as a species do a lot of weird things when building websites.
Just finished a big project with a client who had a client-side render of their react app for the customer facing website. Googlebot was VERY sporadic with how they were indexing certain parts of the site, and in general, the site lost out to inferior sites in more competitive SERPs. Server side render fixed a lot of this and rankings/traffic jumped.
It's also worth noting that the Bing/Yahoo crawlers (still a notable chunk of web traffic!) can't crawl JS. You can ignore this chunk of market share if you want but someone is going to happily take it.
As a general rule, my advice is always this: Make it as easy as possible for bots to crawl and index your site's content. The more hoops the crawler is jumping through, the worse your site will perform in search engines.
Good, they should just delist client side rendered web pages.
My users don't care how I build it, just that the site works and is enjoyable to use.
If I need server-side rendering I'll still write it with a client-side rendered (e.g. React), but tack on server-side rendering at the end.
You are not building this for yourself if you need to be indexed by google. You need to build in a supported way.
The bigger question is why you think an spa should rank well in general. It's only one page.
This isn't everyone.
The comment I replied to said that Google should "delist client side rendered web pages", which is a terrible idea. Maybe I'm OK with the SEO hit? Maybe I've architectured my SPA so that it can be indexed? (At least to some degree)
> The bigger question is why you think an spa should rank well in general. It's only one page.
SPAs can have multiple pages (despite the name). Check out react-router . Browser history can be manipulated to give the same "back button/forward button" functionality between logical pages. This is done for you by whatever framework you use.
For my use case, having the browser reload every time a page is changed would severely interrupt UX.
This is a beautiful part of the new web: indexable applications.
Spoken like someone who hasn't used the web in 5 years.
My work has powered some of the sites you've visited over the last 5 years. I hope you've enjoyed the experience.
Still doesn't make a spa worthly of ranking well in general.. unless it's really a useful app with actual functionality instead of a shallow one page website.
Reply with some sites you made that you feel should rank well. Let's see how they hold up.
That’s called appeal to authority. It’s a logical fallacy. Your statement was false, regardless of how “authoritative” you are on the subject. If you meant something else by your statement, you should have expressed it better.
You seem to suggest that a SPA can only consist of a single `view`, when in fact there's often no discernible difference apart from the underlying architecture. Maybe we need a new word, so people stop getting confused. SPA has nothing to do with the amount of content or views a website has.
It's just as simple to create a shallow, useless website in PHP as it is in React.
Filter out poor users by making the site inoperable with older hardware. If they cannot afford current gen i9, they will not afford whatever my ad network is pushing. Increases the conversion rate, so all is good.
Even my grandparents use an old iPad or cheap smartphone.
My machine isn't particularly powerful either - I use an old Macbook.
Maybe I'm doing something wrong? Open to feedback. Opensourced code is here .
(I am the creator of https://www.prerender.cloud/)
Some relevant excerpts from the article (emphasis mine):
So, there are still no specifics on what extra delays might be involved, but this seems to suggest what I've heard about JS-rendered content still taking much longer than static content to update in the index (i.e. days to weeks) might indeed be the case.
I.e. seems they are implying that while this works, static content is still preferred by them and takes priority.
Write compatible code
Leads to this page:
Which says absolutely nothing. It details nothing about what is supported.
Utterly useless. No version of HTML running, no info about what gets run, no actual technical details at all.
Not a good fit for everything, but it's great if you want to add some fancy form validation to, say, your landing page. You can render whatever you want with LiveView, get your fancy dynamic stuff, without having to worry about making your page more indexable.
2) but I'm really here to commend your comment on this now-flagged post that I now cannot respond to: https://news.ycombinator.com/item?id=20500181 . I don't know if HN mods understand the irony in deplatforming a post arguing against deplatforming, but I am 100% in agreement with you there.
2) Thank you! Is it really flagged? That's too bad. And funny, in a sad way.
This was back in 2014:
As always take SEO advice from Google with a grain of salt.
So really it matters if you believe in the light or dark sides of the SEO force.
The processing of JS explains a lot of the sheer garbage that is in the Google results.
I think they do it because it ties into their business model. JS is needed to unearth the kind of crap that a certain segment of the user base is looking for. That certain segment is worth catering to because it consists of users who are likely to click on ads.
Otherwise, nobody in their right mind would integrate JS into a crawler. "I'm going to write a program that automatically finds random source code, much of it malicious, and runs it!" Come on; without a business agenda justifying it, it's a complete non-starter.
But that's not my point; how did we go from "search engines shouldn't execute JS" to "you're out of touch if you think you can use the web without JS".
It’s not as if totally legitimate websites don’t have reasonable technical alternatives here.
Wasn't this basically AMP though? The solution to the monster web developers were creating?
A good search engine index based on what humans would consume.
Perhaps you can put the blame on the creator of the site, but that won't bring us anywhere if we just allow people to game the system.
The spider is indexing stuff that is the result of code execution that won't reproduce!
"nobody in their right mind" would expect to use the web in the last 15 years or so with JS disabled and have it actually work
I mean, almost the entire public web consists of blogs, forums, and news articles/essays. Almost all of these, with some modern exceptions, work perfectly fine. Of course, you may need JS to take full advantage of e.g., forum software features, but I can browse just fine. Sure, if you have a legitimate SPA like a mapping application or a game JS is a very reasonable expectation. But it’s hard for me to see what users gain otherwise. Actually, I don’t even see what developers gain, other than an improved resume.