A couple weeks ago, I published an article that suggested Google doesn’t care how many characters are in your SERP title–all it cares about is the pixel width. Today, I have similar news to report; this time regarding how Google truncates SERP snippets (aka, the meta description). Unfortunately, I don’t quite have the details nailed down. But I do have a couple pieces of the puzzle, which I’ll share with you now.

The Way Things Used to Be

Just as Google used to impose a 70-character limit on SERP titles, it also used to truncate SERP snippets after 156 characters. Unlike titles, however, snippets were permitted to wrap around to take up additional lines. It was this simple set of restrictions that allowed me to create the World’s greatest SERP snippet:

Something Changed

When Google updated its SERP display, my snippet started showing up like this:

The World’s Greatest SERP Snippet is Reborn

Using my SERP Snippet Optimizer Tool, I created a new snippet–this time limiting my ASCII art characters to 3 lines instead of 5. Also, instead of limiting my meta description to 156 characters, this time I used as many as I wanted (175 characters). See the result below or live in Google’s SERPs:

What Does It All Mean?

There’s not a whole lot we can deduce from these snippets, but here are some simple statements we can assume, based on what we’ve seen:

• The 156-character limit no longer applies.
• Google doesn’t allow snippets to wrap to more than 3 lines (at least not for simple / short queries).
• Most queries result in 2-line snippets. Using a bunch of non-textual characters in my meta description has somehow caused Google to permit a 3-line snippet.
• If a meta description begins with a period, Google SERPs will display a snippet that begins with the first alphanumeric character.
• Google can show as many as 206 characters in SERP snippets (possibly more).
• Google won’t show a meta description that consists only of numbers and underscores.
• This entire article was basically an excuse to show off my latest SERP snippet ASCII art.

Update: It was pointed out to me in the comments that my snippet didn’t work in Firefox. After closer inspection, I realized it was because Firefox was treating slashes as acceptable breaking points for word wrap, whereas Chrome was not. So I’ve updated my home page meta description once again–this time using pipes instead of slashes. Now I’m waiting for it to be crawled again.

Quick answer: the 12-word limit includes stop words. That is, Google will only index the first 12 words of a title, regardless of whether or not they are stop words. This conclusion is derived from the fact that searching for this post by the first 12 words–some of which are stop words–returns at least 1 intitle: match, but searching by the 13th word returns 0 intitle: matches. However, a search for the 13th word without the intitle: operator returns at least 1 result, which suggests that Google indexes all words of a title but only counts the first 12 as title hits. In simple terms, this can be translated into an SEO best practice: Make sure your keywords appear within the first 12 words of your page titles.

In my previous experiment, I hesitantly concluded that Google only indexes the first 12 words in a title. Shortly thereafter, some smartass San Francisco SEO and internet marketing guy named AJ Kohn rebutted my findings by claiming that he successfully queried the lyrics of a certain song by The Police:

I’m not sure this is accurate. I’ve been able to get 13 ‘words’ in a title by doing a search for: de do do do de da da da lyrics

However, this doesn’t necessarily disprove the 12-word limit theory. What it *does* do is indicate that I need to be a bit more clear with my definition of index. For example, in the following sentence:

Google only indexes the first 12 words in a title.

I’m using indexes to mean: parses the content from a document’s title tag and stores each of the parsed words in an inverted index as “title hits” associated with the given document.

In other words, I’m theorizing that Google’s indexer will only give a certain document “credit” for having a given word in its title if that word appears in the first 12 words of the title tag. I’m also assuming that the intitle: operator is reliably capable of querying this information. That is, Google hasn’t programmed its search engine to return 0 results as a way of refusing to serve intitle: queries containing more than 12 words.

This use of the word index has nothing to do with how many words or characters are displayed in Google’s SERP titles. In other words, just because Google displays 13 words in a SERP title doesn’t mean that document is actually getting credit for all 13 words. To understand why, you need to have a deep understanding of search engine architecture–which I’m too lazy to provide (and which I’m not convinced I myself have).

Instead, I’ll tell you that everything you’ve just read is merely unique content to help this page get indexed, because this page is actually another experiment…the hypothesis of which can be derived from the title…and the results of which will be posted later.

In my previous experiment, I showed that Google no longer limits SERP titles by the number of characters. In the comments on that post, a guy named Marco left a comment that claimed that Google only indexes the first 12 words of a title:

Google indexes 12 words in a Title tag.

For example, if you search intitle:"quanti caratteri google indicizza nel titolo della pagina vero che sono dodici tredici" — 0 results

If you search intitle:"quanti caratteri google indicizza nel titolo della pagina vero che sono dodici" — 2 results

Thanks Mark

However, I’m not entirely convinced this claim is accurate. Specifically, I’m not convinced that these results are due to a word limit (versus a character limit). So to determine if Google is in fact imposing a 12-word limit, I’ve crafted the title of this post such that it uses short, thin, non-stop-word words.

I’ll publish this and wait for Google to index it…

Results

Ok, the results are in. From what I can tell, it looks like this 12 word limit theory holds up.

Search for this post by the first 12 words of its title: intitle:"trill titi tit tirl tilt till til tiff ti rill rift riff" — it shows up in the search results.

Search for this post by the first 13 words of its title: intitle:"trill titi tit tirl tilt till til tiff ti rill rift riff fritt" — it does NOT show up.

Conclusion

I hate to say it, but it looks like this theory is true. Google only indexes the first 12 words from a page title. (If you can think of some other explanation for the above results, leave a comment.)

The original post is below, but for the impatient folks…here’s the quick answer. This post’s title is 107 characters long. In the past, Google would have cut off the SERP title after 70 characters. But now, Google shows the entire title–all 107 characters. You can verify this for yourself by clicking here. Based on this experiment, it is reasonable to assume that Google no longer cares how many characters are in your SERP title; all it cares about now is how wide (measured in pixels) your title is.

I’ve been working on developing a new version of my SERP optimizer tool. Part of that process requires reverse-engineering Google’s server-side logic through a series of trial-and-error experiments. For example, one of the things I have to program into the tool is a cutoff point for the SERP title. When I programmed Version 1 of the tool, Google’s logic was pretty simple:

• If the title has 70 characters or less, display the whole thing.
• Else, display as many whole words as possible, without exceeding the 70-character limit.

This logic was confirmed, for example, by this SERP experiment.

However, as I’m programming Version 2, I wanted to revisit those experiments and verify that nothing has changed.

Unfortunately, things *have* changed.

For example, in SERP Experiment No. 1, I created a title with 70 wide characters and Google showed them all:

Here’s what Google shows now:

The next word in the title is “warriors”, which would have made the title 54 characters long. But Google didn’t display it–Google cut the title to 45 characters. It doesn’t take long to test a few SERP listings and verify that plenty of them contain titles longer than 54 characters, so clearly Google’s server-side logic isn’t as simple as it used to be.

How does Google determine where to cut off your SERP title?

The first guess, naturally, is that Google is determining the actual pixel width of titles, regardless of how many characters it contains. If this is true, then I should be able to craft a title using a bunch of really thin characters–and then we can see how many of those characters get displayed in Google’s SERPs.

My thin title is in place. Now I publish this and wait…

Say hello to my 107-character title

Confirmed: Google no longer puts a limit on the number of characters in your SERP title. Rather, it limits the title based on the pixel width.

Mangler: 1, Mofo: 0

Okay so my previous bout with The Mangler was basically a loss. Here’s what we were trying to achieve:

HTML title: 200 pipes + keyword
SERP title: Some Alternative Title That Does *NOT* Contain the Unique Phrase

…and here’s what happened instead:

HTML title: 200 pipes + keyword
SERP title: keyword – SEO Mofo

In other words, we wanted Google to throw away our HTML title and generate something completely different–something that does *NOT* include our unique phrase–but instead, Google merely threw away the pipe characters and displayed our unique phrase by itself. This gives us some basic insight into how The Mangler mangles, but it’s not the answer we’re looking for.

I’m going to update the title content to something trickier and try again. First, I’m heading over to Google’s help page for a refresher on what it considers to be characteristics of a crappy title…

Okay, according to Google, if you want to minimize your chances of being visited by The Mangler, your title content should follow these basic guidelines:

• Make sure every page on your site has a title specified in the <title> tag.
• Avoid vague descriptors like “Home”.
• Avoid unnecessarily long or verbose titles.
• Avoid keyword stuffing.
• Avoid repeated or boilerplate titles.
• Brand your titles concisely.

New HTML title

With those guidelines in mind, here is how I’ve structured my title for Round 2:

“If Google changes your SERP title, does the original title content still count?”

+ (100 pipes)

+ (the first half of the Gettysburg Address)

+ keyword

+ (the second half of the Gettysburg Address)

+ (100 pipes)

+ (ten occurrences of “- SEO Mofo – Home”)

+ (100 pipes)

Let’s get it on!

Okay, Mangler, touch gloves and let’s dance…

SERP Experiment No. 7 »

I was reading a discussion thread in the SEO Training Dojo about how Google doesn’t always use the content of a page’s title tag to generate that page’s SERP title. (For those of you who aren’t Dojo members, you can get the gist of it via this article by Dave Harry about how Google changes your page title in search results.)

In the discussion thread, esteemed SEO professional-slash-SEO radio celebrity Terry Van Horne brought up an interesting question, which I’ll paraphrase for you:

If Google changes your SERP title, does the original title’s content still count towards the page’s relevance score?

That’s precisely the question I’ll attempt to answer with this post.

The Setup

I’ve created a post (i.e., the thing you’re currently reading) with a title that is specifically engineered to bother Google. That is, it intentionally tries to trigger Google’s newfangled Title Mangler algorithm, which theoretically generates more-relevant SERP titles when the original title tag content sucks.

For this experiment, the title I’ve chosen contains 200 pipe characters, followed by a unique phrase that currently returns 0 search results in Google. (I know from experience that Google hates pipe-stuffed titles.) The unique phrase is only mentioned in the title; it is not in the page content itself (and let’s keep it that way, ye commenter of little thinkitthroughedness).

The goal here is to see if Google will return this page for search queries that contain the unique phrase–while refusing to display the original title in the SERPs.

I wanna play too!

Itching to verify the results of this experiment for yourself? Of course not, you lazy bitches! But for the 0.01% of you who might be curious…here’s how you can play along:

1. Find the “unique phrase” at the end of this page’s title. If you’re viewing this page in a typical desktop web browser, then the page title is probably displayed at the top of your browser window. If not, you can find it by viewing the HTML source code of this page and looking at the content right before the </title>.
2. Search Google for that phrase (wrapped in quotes).
3. Did Google return this page in the search results?
4. Did Google display a SERP title that’s different from what I used in the title tag?
5. If you answered yes to #3 and #4, then you might conclude that Google does in fact count original title content towards a page’s relevance score, even if the Title Mangler deemed it useless!

Even if that’s true…so what?

If Google refuses to display your ugly, keyword-stuffed title in its SERPs–but it still gives your page credit for having keyword in the title–then the time-consuming task of balancing SEO-friendly and User-friendly just got a helluva lot easier, didn’t it? Think about it…

I could change my home page title to something like:

The Web’s best search engine optimization website offering optimal SEO tips to search engine optimizers opting to optimize their search engine optimisation options.

…and thanks to Google’s title mangler, my SERP listing would show something completely different–probably something like this:

SEO Mofo

Maybe that’s not the best example, but your mileage may vary depending on what alternative title signals you feed to The Mangler. Like what, you ask? Well, I know of at least 3: create a User-friendly DMOZ title, start the page content with a User-friendly heading tag, and/or point links to the page with User-friendly anchor text.

If this exploit works, is the potential benefit worth all the extra effort?

Highly unlikely. But remember: SEO isn’t about ROI, it’s about proving to yourself that you’re smarter than those assholes in Mountain View.

1/27/2012, 17:50 GMT: Okay, my bothersome title is apparently too easy to unfuck, since The Mangler simply hacked off the leading string of pipes and used the unique phrase as the alternative title. This unfortunately prevents us from making any kind of logical conclusion (I’ll explain why in the next post), so I’ll need to rethink my title content and try again. Click the link below to see what happens in Round 2.

SERP Experiment No. 6 »

<h2>Google Snippet Experiment No. 4</h2>

The purpose of this experiment is to see if Google has changed the (server-side) character limits of SERP titles and snippets. I’ve been seeing SERP titles with more than 70 characters (which has historically been the limit), and I suspect the new logic is tied to the overall width of the title’s block element (limit is set at 512px via CSS). The reason width has become more important than character count is because Google’s Instant Preview feature needs that screen real estate set aside for it.

The weird thing about width-based limits is that different browsers render certain text characters at different widths (including spacing between them). For example, look at the difference between how Firefox and Chrome display 100 pipes…

It’s possible that Google completely ignores character counts now and only cares about the rendered width. To test whether or not this is true, I’ve used a title and meta description on this page that consist mostly of pipe characters. I’ve used Chrome to make them as long as possible–without exceeding 512px wide. (Note that in Firefox, they definitely do NOT fit inside 512px, for reasons shown in the image above.) The title of this page is 154 characters long, and the meta description is 478 characters long–but in Google Chrome, they both fit…

↑ Click the pic, yo!

Okay, now let’s see what happens…

booooooo!

Looks like Google deemed my title useless and used the first non-useless heading on the page, with my site name tacked onto the end. Pfffft. I’ll change my h2 tag slightly–to verify that this is indeed what Google is using–but other than that, I’m leaving this post as-is. I’ve realized that the best SEO experiments are ones that I can leave up and anyone can verify the results at any time. The next variation will get its own post. See you then…

UPDATE: Confirmed that Google is using <h2> tag for title. See image below.

SERP Experiment No. 5 »

The Quick Answer:

Title

As many characters† as you can fit into a block element that’s 512px wide and doesn’t exceed 1 line of text.

Snippet/Description

As many characters‡ as you can fit into a block element that’s 512px wide and doesn’t exceed 3 lines of text. (These limits are for normal queries; long queries have higher limits.)

Display URL

70 characters or less and can fit into a block element that’s 512px wide.

† usually ~70 characters or fewer
‡ usually ~156 characters or fewer

The DIY Answer:

Don’t take my word for it; use the bookmarklet below to figure it out for yourself! Just drag the bookmarklet onto your bookmark toolbar (in other words, save it like any other bookmark), adjust your Google search preferences to show 100 results at a time (optional), search for something in Google, and click on the bookmarklet (with Google’s SERP still active in your browser). If everything works the way it’s supposed to, you should see a draggable table of SERP data appear. Give it a try!

The Long Answer

It has been awhile since I’ve updated my Google SERP Snippet Optimization Tool, and Google has been constantly redesigning their SERP interface since then, so I figured I’d run some tests and see if the maximum character counts have changed.

To figure out the max values previously, I had manually copied + pasted random SERP content into Excel and rigged up some custom functions/filters to count characters. That’s kind of a pain in the ass, especially since Google changes their interface roughly 87 times per day, so this time I wanted to use a test method that’s easier to update.

I decided that the best solution was a bookmarklet that I could run directly from a Google search result page (and distribute to others, so they can verify results for themselves). I wrote a JavaScript function that traverses the SERP DOM, scrapes the Title content from each listing, counts the characters, measures the width, throws everything into a nice-looking table, and then automatically finds the maximum character count and maximum width (in pixels). Then I modified the bookmarklet to work with snippet content (aka, the meta description content) and the content of the displayed URLs (i.e., the URLs shown in green text).

Find a bug…get a link!

If you find bugs, errors, etc. while using these bookmarklets, then please let me know. As an incentive, I’ll give a big fat juicy backlink to anyone who reports a legitimate bug they found in my bookmarklets.

Known Issues

CSS-generated Ellipses Might Be Hiding Characters

Google’s SERP titles use a CSS property called text-overflow with a value set to ellipsis. This CSS declaration causes some titles to display fewer characters than are actually in the DOM node. In other words, if a title exceeds the 512px maximum width, the overflowing words/characters will be hidden from view in a web browser (i.e., replaced with an ellipsis), but the underlying HTML code will still contain the entire title. Therefore, in some instances, my bookmarklet will show a character count that is higher than the number of characters Users can actually see. (I’ve tried to program the title bookmarklet to highlight these instances (i.e., table rows) with a red-tinted background color, but I haven’t thoroughly tested this yet.)

Quick Answer Was Half-assed

The limits stated in the “Quick Answer” section are not 100% accurate. I’ve seen several anomalies that I have yet to investigate. If you run a bookmarklet and discover a SERP listing with character counts that defy the stated limits, then feel free to leave a comment about it. However, if you want to earn a link, you need to explain why the anomaly occurred. That is, simply identifying a discrepancy isn’t enough.

Google Instant Breaks Jump Links

If you have Google Instant enabled in your search settings, then your search results are probably being served from the URL: , in which case the on-page anchors (i.e., the arrow links in the left column of each table row generated by these bookmarklets) will not work as intended. That is, instead of jumping to that SERP listing, you’ll be taken to the Google home page (more accurately: something that looks like the Google home page). If you want the jump links to function correctly, go to your Google search settings page and toggle the Google Instant predictions option to OFF.

Google Chrome Complains About Inserting Non-secure Scripts Into HTTPS Pages

Github Pages apparently don’t support https requests, so these bookmarklets have to insert the external .js files via normal http requests. Depending on whether or not you’re signed into Google, the SERPs might be https…and if they are, some browsers (e.g., Chrome) are going to be all like WTF. Just ignore it and proceed anyway. I won’t steal your identity and empty your bank account, I promise.

Fork me, report issues, & view the code on Github

You may have noticed that these bookmarklets do not execute the JavaScript code directly. Instead, they insert a script tag, which references external .js files hosted on Github. I did it this way for a number of reasons:

1. Github can serve the files faster and more reliably.
2. I can update the .js files on Github and magically update the functionality of everyone’s bookmarklet.
3. You can use Github to submit bug reports, fork the code, make comments, etc. You won’t…but theoretically you could.
4. Using Github makes me feel smarter and better than you.

1/18/2012, 20:15 GMT: Changed bookmarklets to use document.getElementsByTagName('head')[0] instead of document.head. Thanks to Fabian Salomon for this suggestion.

1/18/2012, 21:25 GMT: Fixed a bug in the snippet character counter that was caused by setting the initial value of the minChar variable too low. Thanks to Stefano Gorgoni, who is a professional SEO and certified Google Analytics expert in Malta, Italy, for reporting this bug.

1/18/2012, 22:50 GMT: Added info to the Known Issues section. Thanks to Alan Bleiweiss, a search marketing professional, author, blogger, industry speaker, sustainable SEO best practices advocate and forensic SEO site auditor, for bringing this to my attention.

3/30/2012, 22:15 GMT: Changed the bookmarklet to my new all-in-one script.

4/2/2012, 01:35 GMT: Updated the all-in-one script. Looks prettier. Fewer bugs.

Ladies and Gentlemen, I proudly present my entry into the 2nd Annual Bad Ass SEO Guest Blogging Contest:

Using JavaScript to Hide Content: Advanced White Hat SEO?

In the article, I suggest some best practices for hiding text content from Users. Don’t assume it’s black hat SEO until after you’ve seen the working example. It might just be the single greatest example of white hat hidden content the World has ever seen. (It’s so amazing, I even created a new sub-domain for it!)

I’m also working on a follow-up article that exposes a website that is hiding text content in a not-so-white-hat kind of way (TEASER: the perpetrator is a really big company who works with Google). I’ll publish that here on my own blog as soon as it’s ready. Until then, go read my contest article, spread it around, comment on it, retweet it, print it out, fold it into a miniature human, and snuggle with it.

Oh yeah, and I’d like to thank the following people/companies for sponsoring this year’s contest…

With all the patents, research, and academic papers that are attributed to Google/Googlers, especially in the area of natural language processing, you would probably guess that Google is really good at understanding English. I mean, just looking at this list of papers written by Googlers should give you an idea of the relative importance of this topic. Or…just check out this amazing graph I made for the sole purpose of helping you understand said importance.

Considering the fact that Google has been obsessing over natural language for something like 15 years–combined with the fact that they have more query logs, search history, and indexed content than any other organization in the World–you might expect them to ace a test question like:

Please sort the following documents into 3 groups (Basic, Intermediate, and Advanced), depending on their reading level difficulty.

Seems simple enough, right? So I tested Google, using the search query [darren slatten]. According to Google, only 3% of the documents in its index (that are relevant to [darren slatten]) are considered to be “Advanced” reading level material. Curious to see what Google marked as “Advanced,” I clicked to filter out everything else. The results were nothing short of embarrassing (for Google, not me). Here is how the top 10 results looked:

1. scraper site that picked up a post that contained my name
2. a directory of people that contains someone with the first name “Darren” and someone with the last name “Slatten,” but doesn’t mention me specifically anywhere (henceforth written as “a directory of names”)
3. a directory of names (Excel spreadsheet format)
4. a directory of names (Excel spreadsheet format)
5. a directory of names
6. a directory of names
7. a directory of names
8. a directory of names
9. a directory of names (site appears to be Polish or Swedish, judging by the snippet, but I couldn’t get the page to load)
10. a directory of names (site is in Spanish)

If you want to try this test with your own search query, here are the steps (at least until Google changes their entire search UI…probably 5 minutes after I publish this article):

What results did you get? Is it just me or does Google suck?