11–20 of 53 posts
Does it matter that the JS-constructed HTML does not look anything like the spider-friendly version? We're about to deploy an AngularJS application that is using PhantomJS to generate the spider-friendly content on the server. I'd much prefer to do this simpler method if it works just as well.
Another option is to make a website that works without JavaScript. Only dynamically fetch pages when JavaScript is enabled. Progressive enhancement rocks. Visiting http://monocle.io/posts/how-yield-will-transform-node without JavaScript support yields a blank page. All page titles are Monocle which isn't very descriptive and the meta description is the same for every page. Only with escaped_fragment can a user see de…
My companies do website/CMS services for small businesses–so SEO is WAY more important to us than an app or a content aggregator like Monocle. If our clients suspect SEO sucks for our product they will leave. Conversely, if our product has a reputation for good SEO, it can drive a lot of business to us.
Also, Monocle.io isn't setting the title tag for any of their URLs, so that's a pretty poor example to use wrt SEO.
I'd like to see a real, in-depth article that discusses the following:
- At this point, should I use hash-fragments or pushState?
- Which front-end JS framework (backbone, ember, angular, etc) has the best support for SEO features out of the box?
- Is Rails 4 + Turbolinks SEO-friendly?
- I'd love to see some kind of experiment/example showing that a JS/hash_fragment based site can actually rank well when competing against basic HTML sites. I know that SEO comes down to content and links (more or less) so experiments like that are hard/impossible. I just used to do a lot of SEO for Flash sites back in they day. In the end, you could only do so much and I worry that doing SEO for JS sites is similar.
Just because Google provides the hash-fragment feature doesn't mean they don't give such sites less weight when ranking.
Another option is to make a website that works without JavaScript. Only dynamically fetch pages when JavaScript is enabled. Progressive enhancement rocks. Visiting http://monocle.io/posts/how-yield-will-transform-node without JavaScript support yields a blank page. All page titles are Monocle which isn't very descriptive and the meta description is the same for every page. Only with escaped_fragment can a user see de…
Hey, thanks for taking the time to comment. I certainly could make the titles more useful, in fact due to you suggestion I've just committed a fix to that. I'm interested though, why do you think it's useful for users to read meta descriptions? Or the raw text used by spiders? How does making this a pure JavaScript web app degrade the end-user's experience? I think I can effectively argue the opposite - that JS and c…
Though such an obvious error is hopefully always ignored.
Does it matter that the JS-constructed HTML does not look anything like the spider-friendly version? We're about to deploy an AngularJS application that is using PhantomJS to generate the spider-friendly content on the server. I'd much prefer to do this simpler method if it works just as well.
Progressive enhancement is "The Right Way", for sure, but there are some projects where we just aren't concerned with targeting users without Javascript. That said, hopefully this will let us cater to many of those users, reap the SEO benefits, and provide a better first-landing experience for those not hitting the home page.
Edit: This is the grunt plugin we are using for this: https://github.com/cburgdorf/grunt-html-snapshot
Another option is to make a website that works without JavaScript. Only dynamically fetch pages when JavaScript is enabled. Progressive enhancement rocks. Visiting http://monocle.io/posts/how-yield-will-transform-node without JavaScript support yields a blank page. All page titles are Monocle which isn't very descriptive and the meta description is the same for every page. Only with escaped_fragment can a user see de…
Honestly, with every worthwhile browser (both desktop and mobile) supporting JavaScript and having it enabled by default, it doesn't make much sense to support browsers with it disabled. The couple million people with NoScript installed who enable it only on specific sites know to enable it if a site doesn't work.
Another option is to make a website that works without JavaScript. Only dynamically fetch pages when JavaScript is enabled. Progressive enhancement rocks. Visiting http://monocle.io/posts/how-yield-will-transform-node without JavaScript support yields a blank page. All page titles are Monocle which isn't very descriptive and the meta description is the same for every page. Only with escaped_fragment can a user see de…
Honestly, with every worthwhile browser (both desktop and mobile) supporting JavaScript and having it enabled by default, it doesn't make much sense to support browsers with it disabled. The couple million people with NoScript installed who enable it only on specific sites know to enable it if a site doesn't work.
Look at it this way, this __escaped_fragment__ is only supported by Google. No other search engine supports it. And considering that building it with progressive enhancement first, and then enhancing it with JavaScript, you get content that's indexable by any search engine, not just Google.
The workload is the same, the complexity is the same, the only difference is the focus on progressive enhancement first rather than try to bolt a clearly less optimal solution later.
Another option is to make a website that works without JavaScript. Only dynamically fetch pages when JavaScript is enabled. Progressive enhancement rocks. Visiting http://monocle.io/posts/how-yield-will-transform-node without JavaScript support yields a blank page. All page titles are Monocle which isn't very descriptive and the meta description is the same for every page. Only with escaped_fragment can a user see de…
Hey, thanks for taking the time to comment. I certainly could make the titles more useful, in fact due to you suggestion I've just committed a fix to that. I'm interested though, why do you think it's useful for users to read meta descriptions? Or the raw text used by spiders? How does making this a pure JavaScript web app degrade the end-user's experience? I think I can effectively argue the opposite - that JS and c…
If we were to take two web apps, one using a rendr-style-render-on-server approach ( https://github.com/airbnb/rendr ), and one using a blank-html-bootstrap-through-js approach, the rendr-style app will win out for time-to-first interaction.
To take a specific example, loading the monocle home page gives a base html time of 355ms for me. setup.js takes another 570ms.
All told, it's an initial load of 355ms vs 970ms. Or "close to instant" vs "is something wrong? oh no, it's good".
see:
https://www.google.com/search?q=%22Node+has+had+great+succes...
Notice how the monocle.io link is totally useless. Overtime, this will get you killed by Google as they realize your domain is returning useless results.