getiblog

Recently, I’ve had several conversations over twitter and IM with various people, including James Bowden just today, about the topic of making pages still function even if JavaScript is not present/enabled. It was Alex Sexton’s post on preventing FOUC the accessible way which kind of sparked the rabbit trail I want to discuss in this post: how JavaScript, non-JavaScript, and SEO interplay.

SEO != Accessibility

The first thing to get straight is that many people conflate the ideas of Accessibility (that is, strictly that people with disabilities can still access your content) and SEO (that is, strictly that a search engine crawler bot can access and index your content). We’ll talk in just a moment about how they are somewhat related, but let’s first dispel the myth that they are one-in-the-same.

SEO means that I am actively trying to surface certain important pieces of information in my page to catch the radar of the search engine bot, so that later when someone is doing keyword searching, they will more likely see my page as relevant to that search query. In an odd sense, SEO is actually Accessibility for future search users. But it’s not really Accessibility in the sense of making my page easily and functionally interactable for someone with disabilities like low-vision or keyboard-only input.

Here’s why it’s important to distinguish between these two concepts: Accessibility is a must-have for anyone who actually wants to be a good net-citizen to their fellow community members. SEO is an optional improvement to your content, and only really necessary if you actually have content that should be indexed.

For instance, Gmail needs to be intensely “Accessible” (whether it is or not is the subject of other blog posts by people more knowledgeable than I am). But Gmail doesn’t particularly need to be SEO indexable (except for the landing and marketing pages) because it’s much more a web application than a web site, and the content that Gmail displays is largely private content — that is, my private email inbox. I definitely don’t want that content crawled and appearing in the Google search index!

SEO ~= Accessibility

Here’s why it’s so common to relate the two concepts: often times, the process of making a page Accessible (at least, the basics) is very similar to making a page SEO indexable. But notice I said often — the two ideas are definitely related, but there’s a whole bunch of SEO that has nothing to do with Accessibility, and vice versa.

For instance: alt tags on <img> elements. The alt-tag is supposed to define a textual replacement for the image. If I have a picture of two boys playing baseball, I can describe that image by saying “Boys at a baseball game” in the alt tag. This will serve a couple of purposes.

First and foremost, the text will appear in the browser if the image cannot be rendered (for whatever reason). Secondly but almost equally important, if a user is browsing your site with say a Screen Reader because they are blind, the Screen Reader can describe the picture only based on what text you put in that alt tag. So, the primary goal then of the alt tag is for Accessibility reasons.

But alt also has (rightly or wrongly) some SEO implications. SEO bots also have a very hard time understanding a picture without some help explaining it, so if you describe the picture in the alt tag, the SEO engine has a better chance of understanding and properly indexing your page. This is a bonus though — not the primary goal.

Another topic which has both SEO and Accessibility facets is “semantic markup”. Semantic markup means structuring your document in a way that makes it easier for anything parsing it to understand your intent (whether that is an SEO bot or a Screen Reader). For instance: wrapping paragraph text in a <p> (“paragraph”) tag or describing a list of items using an <ol> (“ordered list”) tag. HTML5 has a whole slew of new tags designed to make the process of “marking up” your document with tag structure more semantic and meaningful. This will not only help search engines but it will also help your disability visitors.

SEO <> Accessibilty

On the other hand, there are many techniques which are quite unique to each discipline and really have little-to-no overlap with the other. For instance, an SEO expert may very well put an <h1> tag in the middle of some paragraph text and use CSS to make sure it’s still styled like the surrounding text content. Why? Because they know that a search engine may pick up on that keyword more easily if it the structure of the document indicates it’s importance, regardless of visual presentation.

But that has absolutely nothing to do with Accessibility, and is quite possibly even counter to the goals of such. A Screen Reader might “render” that text confusingly when verbally transcribing it: “The lazy brown Section Title! dog slept the afternoon away.”

By the same token, using WAI-ARIA (the modern RIA/Ajax extensions to basic Accessibility techniques), you might markup a tag with all kinds of extra attributes to help the Screen Reader out, but which would have no meaning or usefulness to an SEO bot at all (and may very well even confuse it if you’re not careful).

SEO – JavaScript

Here’s where the conversation usually gets a lot more muddled. Years ago, web developers had a non-trivial amount of users to consider who were surfing the web with browsers that were partially or completely incapable of dealing with JavaScript (the text-based Lynx browser, for instance). Today, most studies show that <2% of people surf without the benefit of JavaScript. For a lot of developers, we’re now getting into the territory where supporting a “fallback” (non-JavaScript) version of the page or site may become non-pragmatic compared to the relative percentage of viewership.

Not everyone feels that way, though, and so a lot of sites still, to greater or lesser extents, try to maintain some sort of non-JavaScript functionality. For instance, you may have a contact form with the web 1.0 submit button, and then with JavaScript you modify that form at page run-time so that it instead submits via Ajax. This is a reasonable first pass at “progressive enhancement” (or, depending on your mindset, “graceful degradation”).

The unfortunate and confusing part is that developers (and especially business types like bosses) often times combine their efforts for SEO, Accessibility, and non-JavaScript fallback all into one effort. The primary reason for the conflation is this: a non-JavaScript capable browser in many basic ways seems the same as an SEO bot (which can’t, for the most part, do anything JavaScript) as well as a disability-challenged visitor who must rely on a Screen Reader or other Accessibility tools for input and output. It seems on the surface that it’s easier to just lump all 3 into the same category, like the Dr. Seuss “Haves” and “Have Nots”.

While this may seem like a good pragmatic shortcut, as I’ve shown so far, this leads to a lot of confusion, wrong practice, and missed opportunity. The result is that you end up getting all 3 practices wrong in some way or another. You should have a separate and robust strategy for each: Accessibility, SEO, and non-JavaScript (if that demographic is important to you).

Ajax = SEO confusion

There are many people out there who feel that Ajax’ifying your page (that is, making it so the page content can change/update without full page refreshes) automatically puts you at odds with SEO and with Accessibility. But this is usually where the confusion takes over and we lose sight of some important points:

1. Not all content needs to be SEO indexed. Understand that you can SEO the portions of your site that are important for search results, but not SEO the stuff that’s not important. For instance, if you have a weather widget on your page, the weather content inside that widget is not SEO relevant, so don’t worry about making it SEO friendly (whether it’s Ajax or not).

   Digg has a bunch of different links to various content around the web. In some respects, it’s kind of like a search engine itself. I’d submit to you that the list of links on the Digg homepage is not really SEO relevant, because this page itself is not providing any relevant additional info. It’s just a link farm to other content on the web. Of course, Google certainly crawls the links found on Digg and indexes that content, but I rarely see that Digg itself shows up as the source for content when I do a Google search — I just see the content itself. For Digg, SEO’ing their Ajax is probably not as relevant.

   Twitter and Facebook on the other hand have a lot of original content, and so it absolutely makes sense for them to make their pages and content as SEO friendly as possible. To the extent that they have Ajax mixed in, they will need to take notice of how Ajax may affect their SEO.

2. Just because your page has Ajax on it doesn’t mean that it’s not SEO indexable. For instance, for Accessibility (and non-JavaScript) reasons, it’s probably a good idea for the “first page-view” (that is, when a user first pulls up your URL or when they do a full page refresh) to send out all the relevant content in the initial HTML. This content is then perfectly indexable by an SEO crawler without any JavaScript.

   Just because you then add Ajax updating of that content to your page to help users save page refreshes does NOT mean that you’ve lost SEO friendliness of your content.

   If however you send out an empty page with no content and build everything on the fly with JavaScript and Ajax, then you definitely are limiting the ability of a search engine crawler to see that content.

SEO + Ajax

The confusion around these points is so strong and prevalent, Google recently published a set of suggested practices for making an Ajax-enabled page crawlable, to give you a way to achieve SEO with your Ajax goodness.

Basically, Google recognizes that it’s common for the complex Ajax-driven states of a site/application to be tracked (and thus bookmarkable and history-capable) by saving those “states” into the hash portion of the URL, like this: http://somedomain.tld/something/#state1&state2. However, everything from the # to the end of the URL is only known and accessible by the browser and is not something a server request sees, so the Google crawler can’t make such a request and expect that your server itself will return any relevant content for that state (because your server won’t ever see the # portion of the URL).

So, Google is suggesting that for their crawler (without the benefit of JavaScript or Ajax) to index all these Ajax driven states, you need to help them out (does that sound like SEO to you!?) and add additional functionality to your site/app that let’s these states be indexable.

The specifics of the technique are not important to this post (read the link provided if you are interested). In addition, I’ve got my own issues with their suggested practices, so that’s probably stuff for its own post at some point. But bottom line, you can take some extra steps on your server back-end to make all those Ajax driven states individually indexable.

SEO.split(“.”)

Here’s the big confusion that we need to unravel. Google has wrapped up this topic into a discussion of Ajax, which makes everyone who has any Ajax on their page scared that they will lose all their SEO if they don’t conform to Google’s suggested practices. This is just plainly not true. And it’s creating a lot of wrong practice by trying to have everyone conform to something that is only relevant to a certain subsection of sites/applications on the web.

This may seem like it’s related to Ajax, but I suggest to you it’s not really directly about Ajax. Google is actually saying that individual pieces of information can be individually indexed, if that makes sense for your site. In other words, the individual pieces of “partial” information (that you may or may not Ajax into the page instead of doing a whole new page view for) can be indexed as just that partial content instead of as a complete page.

Google is not concerned about whether you are using Ajax or not. They’re concerned about whether you are displaying relevant and indexable content in a way that their search bot can easily access or not. So, they responded by giving you a set of guidelines by which you can make such usage more SEO friendly. Google wants access to that individually indexable content just as much as you may want the SEO juice of having more of your site’s content being indexed.

Take Twitter for example. Individual tweets and user profiles are all unique pieces of content that should be separately indexable. For them, if they are going to Ajax’ify the display of all of this content, they definitely need to be aware of how to keep Google able to individually access this content. Of course, Google could very well just index the entire page of tweets. But this leads to less robust indexing than if Google is able to individually access and index each distinct piece of content.

return;

Accessibility, SEO, and Ajax/JavaScript are three distinct practices that all modern web sites and developers should have strategies for. Combining those efforts may seem expedient, but it often leads to more confusion and failure to achieve the goals of any of the three. So it’s important you understand where they overlap and where they are separate, and have a robust strategy for managing each.

Tweet

4 Responses to “SEO that Ajax… Ajax that SEO”