resources

Matt Cutts first mentioned speed publicly, as a potential ranking signal in November 2009 but, speed has always been important at Google. Google's homepage for example, is intentionally sparse so that it loads quickly. Larry Page recently said he wants to see pages "flip" online. Clearly the concept of speed and it's importance at Google is nothing new. Robert Miller, actually conducted the first research in this area over 40 years ago. According to Miller, when a computer takes more than one tenth of a second to load, the user feels less and less in control. When Google and Bing conducted their own tests in 2008 the results were similar to what Miller had predicted. Bing experienced a 1.8% reduction in queries when slowed by 2.0 seconds and Google experienced a 0.59% reduction in queries when slowed by 400 milliseconds. Bottom line, fast pages help marketers because users are far less likely abandon fast loading sites. Users expect pages to load quickly!

Page Speed was introduced as a ranking signal for English queries executed via Google.com nearly a month ago. It's defined as "the total time from the moment the user clicks on a link to your page until the time the entire page is loaded and displayed in a browser." In their first major update to Webmaster Guidelines in over a year, Google recommends webmasters monitor site performance and optimize page load times on a regular basis.

Because Page Speed data is missing from Analytics and other tools, it's best to use the Site Performance in Google Webmaster Tools for regular monitoring and optimization. To view Site Performance data in Google Webmaster Tools, you'll need to add and verify your site first. In Google Webmaster Tools, Site Performance data is processed in aggregate and without personally identifiable information. "Example" URLs are derived from actual Google Toolbar user queries and as a result query parameters are removed. "Suggestions" are based on URLs crawled by Google and not truncated. "Average" site load times are weighted on traffic. Site Performance data accuracy is based on the total number of data points, which can range from 1-100 data points (low) up to 1,000+ data points (high). As mentioned earlier, this data comes from Google Toolbar users with the PageRank feature enabled. While Google hasn't provided Toolbar PageRank user demographic information, this data seems fairly reliable. If anything, it would seem that Toolbar PageRank bias would point to more savvy users and that as a result Google Webmaster Tools Site Performance data might be faster than actual.

During our "Speed" session at SMX, Vanessa Fox and Maile Ohye (Google) seemed to agree that less than 4.0 seconds was a good rule of thumb but still slow. According to Google AdWords, "the threshold for a 'slow-loading' landing page is the regional average plus three seconds." No matter how you slice it, this concept is fairly complex. Page Speed involves code, imagery, assets and a lot more not to mention user perceptions about time. For example, the user's internet connection (Google Fiber), their browser (Chrome), device(Nexus One), its processor (Snapdragon), the site's host and other issues all impact user perceptions about speed. Don't worry though, according to most expert estimates, 80% to 90% of page response time is spent on the front-end. At the end of the day, relevance is critical but speed follows quickly behind.

Speed Resources:

It's becoming more and more clear that ranking reports are no longer reliable. Users are noticing personalized SERPs more and more and they're catching on to obvious inaccuracies generated by traditional ranking report software. These inaccuracies are caused by differences in query IP, query data, account status, web history, personalized settings, social graph and/or other. As a result, there is a growing shift away from rank report software to analytics for accurate SEO measurement.

Prior to personalized search results, SEO relied heavily on ranking reports in order to measure SEO campaign performance. SEOs create "ranking reports" with software that submits automated queries directly to search engines, a.k.a. "scrapes search engine results." Despite the fact that automated queries are against Google Webmaster Guidelines, waste energy and cost Google millions of dollars each year to process, scraping search engine results is still a popular practice. Obviously it’s in the engines best interest to take steps to prevent these queries.

Analytics software on the other hand is different, it works independently of search engines. Analytics relies heavily on code embedded within pages as well as human interpretation of data. Until recently, analytics software has been used only to “tell a story,” but not for the precise measurement SEO requires. Site analysis focuses on trending and establishing a “comfort level” with data determined to be "good enough" by the analytics specialist. Analytics platforms are designed for anyone to use, specialist and non-specialist alike. In many cases, analytics specialist themselves have little analytics experience, expertise, knowledge about how search engines work or an understanding of searcher intent. How can we expect anything different, when WAA itself still doesn’t teach things like transactional queries?

"To optimize scent trails, make sure that when the intent is transparent, the scent trail on any chosen term matches that intent. It doesn't matter if the trail starts with PPC (pay-per-click) or organic search. Prospects usually hope to find one of two things: the answer they seek or a link that takes them to the answer."

- The Web Analytics Association "Knowledge Required for Certification" (also available in non-www version)

Analytics tracking code is usually implemented by URL without consideration for user path, intent, source or origination. In most cases the implementation is performed by someone other than the analytics specialist interpreting the data. According to some estimates as many as 45% of pages implemented with Google Analytics contain errors. Conversions from organic SERPs are the most difficult to track back to the original referrer. To compound that problem, site issues often prevent even flawless analytics implementations from reporting. Analytics failures are costly, often go unnoticed and undetected because NOTHING is in place to report when analytics doesn't report.

Quick examples & thoughts:
- Even if Avinash himself, implements Omniture and Google Analytics tracking code on every page of your site, users entering from SERPs via 301 or 302 redirect won’t be attributed as “Organic.” According to Google, "If your site uses redirects, the redirecting page becomes the landing page's referrer. For example, if a user searches for a specific keyword, such as 'used books' on Google, there will not be any referring data showing that this keyword was searched on Google. Instead, the referral will be shown as the redirecting page."

- High traffic major converters or blank pages that send users to a competitor? Either way, nobody will ever know because these pages lack analytics tracking code. URL naming conventions for most sites follow a specific pattern. Use the site operator to quickly spot check for URLs that seem out of the ordinary to be certain they include analytics tracking code implementation and aren't redirected. It's pretty common to find legacy pages from older versions of sites indexed.

SEO Analytics

- If these folks are quick evaluators, analytics tracking code might not execute before a new page loads and this SEO conversion might be credited somewhere else. Analytics won't measure landing page load time even though it's a highly important metric for users. Flash or otherwise, pages like these always have issues when it comes to tracking organic conversions.

SEO Analytics

- If your site goes down chances are you'll never know because analytics reporting goes down as well. Using a website monitoring service is always a good idea, just to be sure that conversions really are down and not your entire site.

Takeaways, until SEO expectations are more clear to the analytics community, SEOs should insist on performing SEO analytics audits as usual. When hiring analytics specialists, look for applicants who are willing to address websites from the user perspective and outside of analytics. Folks willing to question data accuracy and those able to identify analytics obstacles are highly desired. Key being, SEO is as concerned with what analytics is tracking as it is about what analytics should be tracking.

While Google has condemned buying and selling links that pass PageRank, they've encouraged listing in paid directories like Yahoo for years. It seems that era may have come to an end earlier today. The following bullet points have been removed from Google's Webmaster Guidelines Webmaster Help Center*

  • "Have other relevant sites link to yours."
  • "Submit your site to relevant directories such as the Open Directory Project and Yahoo!, as well as to other industry-specific expert sites."

Does this recent move reflect a renewed emphasis on rooting out paid links passing PageRank and/or low quality links by Google?

*As mentioned, the bullet points above have been removed from the US version of Google's Webmaster Help Center. Other versions may not yet reflect this change.
-----------

UPDATE: Hat tip to Barry Schwartz who noticed John Honeck's post in Google Groups where Google's John Mueller comments on the change. Barry provides a full recap at SERoundTable.com and SearchEngineLand.com.

JohnMu aka Googler John Mueller, confirmed Google's use of sitemaps on Sunday and suggests using only quality meta data in xml sitemaps.

In his Google Groups post, John Mueller goes on to mention specifics as to how Google uses meta data in xml sitemaps submitted via Google Webmaster Tools :

URL - According to Mueller, it's best to list only working URLs in xml sitemaps and only the correct version for canonical URLs. For canonical URLs, he suggests providing the "/" version and not "index.html" in his example. He goes on to point out the importance of using the same URL found in the site's navigation and if necessary to use 301 redirects to that same URL when necessary. The navigation issue if important especially if something other than a crawler creates your sitemap. Either way, it's worth testing to be sure your Sitemap URLs are identical to those in the user path (I've actually had near knock down drag outs over this issue). JohnMu suggest only including URLs to indexable content like (X)HTML pages and other documents. In addition he points out, it's best to only include URLs webmastes want indexed.

Last modification date - In his post Mueller points out the difficulty Google can have with determining a "Last modification date" for dynamic sites due to their dynamic nature. He suggests either using the correct time or none at all. John suggests using a "Last modification date" but not "Change frequency" unless webmasters can establish a consistent frequency.

Change frequency - Like "Last modification date", Mueller suggests not using a date/time if the actual one isn't available.

Priority - Mueller suggests not including "Priority" meta data in xml sitemaps unless webmasters feel they can provide accurate data.

In summary, JohnMu suggests sitemap.org XML files that contain URLs for inclusion in Google's index and only those found in the site's navigation. He suggests "Date or change frequency" and "Priority" as optional meta data.

UPDATE: JohnMu has posted additional information over at Search Engine Roundtable in response to Barry's post.

- beu

Google recently announced that they will soon start including landing page load time as a factor in determining Google AdWords Quality Score. Here are a few simple and easy tips designed to help anyone decrease their load times and speed up landing pages. I've listed just a few below but, feel free to comment with more if you'd like.

  • Avoid 301, 302 and JavaScript redirects to your landing pages and don't use interstitial pages.
  • Reduce or eliminate the number of session ID and arguments in landing pages.
  • Use absolute URLs for dependencies.
  • Use external CSS and move calls for external CSS to the top of the HEAD in your landing pages and just below the TITLE.
  • "Prefectch" landing page image dependencies near the top of the HEAD in your landing page HTML.
  • Keep page dependencies within the same domain. In other words, try to avoid framed content and/or any content dependancy residing at another domain from loading into your page.
  • Remove unnecessary "white space" in HTML code including text that is "commented out".
  • Avoid embedded Flash content in your landing pages, especially when content in Flash is being pulled from another source.
  • Avoid animated gifs and unoptimized images of any type.
  • Reduce the total number of images in your landing pages and specify their size in the src container.
  • Reduce the size of images in your landing page by 10%.
  • Use CSS instead of relying on "spacer.gif" or "clear.gif" images to style the look and feel of your landing pages.
  • Allow caching when possible.
  • Use external JavaScript and move external JavaScript like analytics code and other to the bottom of your landing pages.

- beu