Vue.js and SEO

JS frameworks are more suited for apps, behind authorization screen, not websites in classical meaning. Or for non-critical elements that does not need to show in SEO results.

If your site traffic depends on SEO don't use JS components.

I think it's time that search engines start supporting this, because it is upcoming, fast.

@thijsdemaa I am not sure how would this happen. Usually crawlers are headless browsers which do not even have the possibility to enable Javascript. And even if there was a way, it would be sooo much slower (the wait time for Javascript code to execute). Anxious to see what happens with Javascript and SEO in the future, but don't really currently see a way around it.

@toniperic I'm afraid of it too, but its kind of a bummer. At our company we would love to use Vue.js and Vue Router in a major application, but we just can't get past the SEO part.

Here's another way to think about it:

If your content requires javascript, is that really a good idea? Is it accessible?

When a search engine struggles to access your content, it's a sign that some users will too.

Well, I think I disagree. We are at a point where every browser supports JavaScript, and anyone who has it disabled experiences major limitations on the internet. Vue.js and Vue Router are both quite light weight.

So no, I don't think the content can be considered inaccesible, or less accessible for that matter

So no, I don't think the content can be considered inaccesible, or less accessible for that matter

There's a number of reasons that javascript might not be available, for example when the user has poor connectivity and some resources on the page are not downloaded. This article by the UK government is from late 2013, but still worth reading.

By the way, notice how blazing fast that gov.uk page loads. That's because they are very content-focused and don't load a bunch of extraneous bloat before the user can start reading.

I'm not saying that javascript-only websites/applications are a bad idea. It just seems like a questionable trade-off to make content (e.g. an article / blog post) depend completely on javascript. If you get some significant benefit in return, then maybe it's a worthwhile trade-off. For me, I'd rather have my content render faster and not depend on loading a javascript framework.

That's an interesting article you quoted there, thank you. But this is not concerning something simple as a blog, but an information system. Arabian horse shows, with timetable information, photos, documents, livestreams, etc. It is basically an application, but not behind authentication and it should be available to the public, and indexable by search engines.

Is there not a way to put the data in the HTML when it comes from the server, so that the search engine can see the HTML tags when it's crawling the page, but is not visible to the user?

@thijsdemaa have you checked out Prerender?

Arabian horse shows, with timetable information, photos, documents, livestreams, etc. It is basically an application, but not behind authentication and it should be available to the public, and indexable by search engines.

Okay, then maybe one useful question is: for a given URL, is there a "definitive" version of that content that you would like search engines to see? Or is the content on that URL changing constantly?

If the content is changing constantly, it can be tricky to know "what is the content of this URL?" And if you can't answer that question, then it's hard to know where to start with SEO. :(

Of course, maybe some pages are highly dynamic and others less so. Or maybe you can adjust your URL structure to reflect the state of the page. In all cases, the page is the atomic unit of the web, and search engines behave accordingly.

From an SEO perspective, in general this isn't something you have to worry about too much anymore. Search engines, for the most part, are able to render and crawl your site just like a browser. So if you're worried about it solely in regards to that aspect, don't be. Now if you suspect a large percentage of your users would be blocking or disabling javascript then that's something entirely different.

With that said, there's really no reason to build your average informational website solely on the client. In 99% of the time it's overkill.

@tjames so are you saying that search engines do support JavaScript?

@tjames Interesting, looks like I was behind the times!

I am building a Laravel - Vue public website.

Most Main Content in body is output from laravel backend {{ $content }}, NOT Vue @{{ content }}. But here is the key thing: if I create new Vue and bind to entire body, will the Search engine read all the text fine?

Also, If I put the entire navigation bar into Vue Inline template, is it SEO friendly? (Again most items are from laravel {{ $item->name }}, never rendered again by Vue)

This matters a lot because It helps me decide whether Vue.js should be used at all : /

This is directly from Google: "Times have changed. Today, as long as you're not blocking Googlebot from crawling your JavaScript or CSS files, we are generally able to render and understand your web pages like modern browsers" see the whole post here: https://webmasters.googleblog.com/2015/10/deprecating-our-ajax-crawling-scheme.html

For those that are still worried or for some reason don't believe Google, use progressive enhancement. Vue makes this easy with the 'replace' component property, render your static content/text in your component container on the server, set the replace property to true and Vue will take over and replace that content with your component when it's loaded.

Just adding my 2cts:

The issue here is not about JS or not JS, but about client side or server side rendering of the content.

The base principle is to admit that if you render the content server side (or if you deliver static content), troubles are theorically limited : all SEO bots will have the same content to index, and they will index the same content. Period.

If you go full client side rendering, content indexation will depend on how the SEO bot handles client side rendering.

If he fails at it : no SEO.

As tjames said, SEO bots are evolving and are able to index client side rendered content, but we MUST be aware of the fact it is something new, and we never know how things are handled inside the black box ...

Hi guys, just sharing I have a full Vue.js SPA with Laravel backend (no SSR), and it is crawled just fine by Google and rendered in Fetch as Google feature.

The solution lies in just properly polyfill the JS code. I needed just a few adjustments to Laravel Mix.

I explained here https://medium.com/@andre_tgposters/hi-gajus-kuizinas-you-totally-nailed-it-ef39cd5fba4e

The original post is here and deserves my compliments: https://medium.com/@gajus/react-application-seen-as-a-blank-page-via-fetch-as-google-afb11dff8562

This is my website: https://www.typographicposters.com

andre , how did you solve the # issue without make an error in refresh , in your website https://www.typographicposters.com/ , did you used history mode or hash mode ?

Hi james.. can you please explain more about this replace attribute? ive been searching about it in google and vue docs without any luck.. has it been deprecated?

I didn't implemented but I think you should check this "https://medium.com/@nour.araar/make-vue-js-spa-with-laravel-seo-friendly-c9f2a9d6f61f"