Live data from Hacker News

SEO in JavaScript Web Apps

blog.alexmaccaw.com

41–50 of 53 posts

Re: SEO in JavaScript Web Apps

#41
post #40
post #37

Earlier quoted context omitted.

As a noscript user I'd like to see an explanation to why I should enable javascript on your site. If you put a link to an explanatory page along with the "please enable javascript for a better experience" header I think that would be useful. Of course getting the explanation down is going to take some effort you don't want to be condescending and you do want to give a meaningful explanation - perhaps with pictures, a…

Would just adding a line like "This site uses AJAX for a large part of its functionality" work or would you prefer a more in-depth description?

I would want to know what I was getting in trade for the increased risk of enabling javascript. Your proposed message isn't substantially different from the current message.

Noscript users are going to be more savvy than average users, but they are still users so if you are going to make any effort to inform them, make sure it's from the perspective of a user rather than a developer. Developers care about AJAX, users only care about what they see on the screen.

Re: SEO in JavaScript Web Apps

#43
post #10

Earlier quoted context omitted.

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…

>why do you think it's useful for users to read meta descriptions? It isn't, really. I made a mistake and thought that every page (served to users and search engines) had the same title and description. A user is unlikely to read a meta description, unless he/she is on a search results page. >How does making this a pure JavaScript web app degrade the end-user's experience? NoScript users and special need users are un…

> "special needs users are unable to access your sites content" Sorry I have to call you out on this, ignoring the use of the term "special needs", how could this possibly affect someone's use of JavaScript?

Re: SEO in JavaScript Web Apps

#44

Earlier quoted context omitted.

"Screenreaders in generally do not support JavaScript." Please stop saying that. It hasn't been true for a good 5 years or so. * http://www.brucelawson.co.uk/2011/javascript-and-screenreade... * http://webaim.org/projects/screenreadersurvey4/#javascript * http://www.w3.org/TR/WCAG20-TECHS/client-side-script.html

Thank you! I've been behind the times. I'll start viewing it as a general accessibility issue, not specific to screen readers. But like Steve Klabnik commented, and from http://www.w3.org/WAI/intro/aria.php , there are a few more steps to take to make JavaScript enabled screen readers play nice: "WAI-ARIA addresses these accessibility challenges by defining how information about this functionality can be provided to…

But wai-aria has nothing to do with JavaScript, rather the application of semantic elements to make non-native controls able to be interpreted by screen readers.

Re: SEO in JavaScript Web Apps

#45
post #43

Earlier quoted context omitted.

>why do you think it's useful for users to read meta descriptions? It isn't, really. I made a mistake and thought that every page (served to users and search engines) had the same title and description. A user is unlikely to read a meta description, unless he/she is on a search results page. >How does making this a pure JavaScript web app degrade the end-user's experience? NoScript users and special need users are un…

> "special needs users are unable to access your sites content" Sorry I have to call you out on this, ignoring the use of the term "special needs", how could this possibly affect someone's use of JavaScript?

I don't understand your question. Is "special needs" a term I shouldn't use? I got it from Wikipedia/accessibility.

  [Accessibility] often focuses on people with disabilities or special needs.

Re: SEO in JavaScript Web Apps

#46
People should keep in mind that you do not always have the benefit of green field development; sometimes you have a project already written that does not have much of server-side component, and has no budget or time left for adding real pages/do graceful degradation (much less progressive enhancement.) In these cases, using a spider is pretty much your only choice. Some notes/recommendations:

- I'd recommend PhantomJS (there are some other packages built on top of it, but for my custom needs, using the original was better)

- If you spider a whole site, especially if it's somewhat complicated, log what you're spidering and see if and where it hangs. I started getting some PhantomJS hangs after ~100 URLs. In this case, it can be a good idea to do multiple spidering runs using different entry points (I use command line options to exclude certain URL patterns I know were spidered during previous runs)

- If you're spidering sites using script loaders (like require.js), pay careful attention to console errors; if you notice things aren't loading, you may have to tweak your load timeout to compensate. Using a "gnomon" (indicator) CSS selector is very helpful here.

- Add a link back to your static version for no-JS people in case Google/Bing serves up the static version. This only seemed to be problem shortly after spidering, but it's worth doing regardless (later, search engines seemed to start serving the real version)

- For those wondering how to keep the static version up-to-date, use a cron job, then cp/rsync/whatever your latest version to your "static" directory.

One thing I'd like to add is that I wish PhantomJS would support more things that node.js does (since some of its API is modeled after it), particularly many synchronous versions of functions. That aside, it's an incredibly useful piece of software.

Re: SEO in JavaScript Web Apps

#47
How do YOU differentiate? I SEO like a muthafugga.

First I copy the trend and slap it on the free platform, then I get all blustery and religious in my tribe. Then I game the goog and watch the benjamins rain dOwN.

If you need to build a business around publicly available search engine results... link deep and deliver content, not jumping-off points.

If you rely on search engine referrals and can't "replay" to some nestled in state in your SPA, then DO NOT DO A Single URL Application (SUA).

Hey, everyone! Let's get back to load screens and useless navigation!!! View this site in HTML or wait a minute while we load your Flash.

Re: SEO in JavaScript Web Apps

#48

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.

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

Well, javascript support in w3m and lynx is still pretty poor. It makes it harder to easily get some content from offline reading using wget/curl.

It does depend on what kind of site/app you're making. I'd say that if your main content is text, then requiring js makes no sense (especially if you're publishing some blog posts on configuring server software -- I might want do download that article to a headless server).

I think most apps also benefit from an old school REST architecture, so that it is possible to eg: script your todo-app with curl to create a new todo-item without having to go through 3 pages of api-specs.

Re: SEO in JavaScript Web Apps

#49
post #41
post #40

Earlier quoted context omitted.

Would just adding a line like "This site uses AJAX for a large part of its functionality" work or would you prefer a more in-depth description?

I would want to know what I was getting in trade for the increased risk of enabling javascript. Your proposed message isn't substantially different from the current message. Noscript users are going to be more savvy than average users, but they are still users so if you are going to make any effort to inform them, make sure it's from the perspective of a user rather than a developer. Developers care about AJAX, users…

But I'm a developer, so I don't know what the best wording for this is. The point is, some of the functionality of the site is broken when not using Javascript because it's AJAXed and there is no fallback with POSTs and so forth (that's not in the development budget)

Re: SEO in JavaScript Web Apps

#50

I made a web service that will do javascript SEO for you. Check it out at BromBone.com. We render your entire page for you a save it has html on a CDN. Then you can just do the simple routing described in this article, but send Google the page from our CDN instead. That way Google sees the exact same thing as your users, but you don't have to code it again.

> BromBone uses a real web browser to download your web pages. We run all that fancy javascript, make all your AJAX calls, and save the result. Makes me wonder why Google itself doesnt do it like that. Maybe Google should buy BromBone...

> Makes me wonder why Google itself doesnt do it like that.

I do believe Google does do it like that.

At least, when I had a Twitter search widget on my site, Google indexed the content in that widget.

Post reply on HN