Spring Cleaning out of Session

Announcement by Google
• Aardvark: Aardvark was a start-up we acquired in 2010. An experiment in a new kind of social search, it helped people answer each other’s questions. While Aardvark will be closing, we’ll continue to work on tools that enable people to connect and discover richer knowledge about the world.

• Desktop: In the last few years, there’s been a huge shift from local to cloud-based storage and computing, as well as the integration of search and gadget functionality into most modern operating systems. People now have instant access to their data, whether online or offline. As this was the goal of Google Desktop, the product will be discontinued on September 14, including all the associated APIs, services, plugins, gadgets and support.
• Fast Flip: Fast Flip was started to help pioneer news content browsing and reading experiences for the web and mobile devices. For the past two years, in collaboration with publishers, the Fast Flip experiment has fueled a new approach to faster, richer content display on the web. This approach will live on in our other display and delivery tools.
• Google Maps API for Flash: The Google Maps API for Flash was launched to provide ActionScript developers a way to integrate Google Maps into their applications. Although we’re deprecating the API, we’ll keep supporting existing Google Maps API Premier customers using the Google Maps API for Flash and we’ll focus our attention on the JavaScript Maps API v3 going forward.
• Google Pack: Due to the rapidly decreasing demand for downloadable software in favor of web apps, we will discontinue Google Pack today. People will still be able to access Google’s and our partners’ software quickly and easily through direct links on the Google Pack website.
• Google Web Security: Google Web Security came to Google as part of the Postini acquisition in 2007, and since then we've integrated much of the web security functionality directly into existing Google products, such as safe browsing in Chrome. Although we will discontinue new sales of Google Web Security, we’ll continue to support our existing customers.
• Image Labeler: We began Google Image Labeler as a fun game to help people explore and label the images on the web. Although it will be discontinued, a wide variety of online games from Google are still available.
• Notebook: Google Notebook enabled people to combine clipped URLs from the web and free-form notes into documents they could share and publish. We’ll be shutting down Google Notebook in the coming months, but we’ll automatically export all notebook data to Google Docs.
• Sidewiki: Over the past few years, we’ve seen extraordinary innovation in terms of making the web collaborative. So we’ve decided to discontinue Sidewiki and focus instead on our broader social initiatives. Sidewiki authors will be given more details about this closure in the weeks ahead, and they’ll have a number of months to download their content.
• Subscribed Links: Subscribed Links enabled developers to create specialized search results that were added to the normal Google search results on relevant queries for subscribed users. Although we'll be discontinuing Subscribed Links, developers will be able to access and download their data until September 15, at which point subscribed links will no longer appear in people's search results.
• Code Search, which was designed to help people search for open source code all over the web, will be shut down along with the Code Search API on January 15, 2012.
• In a few weeks we’ll shut down Google Buzz and the Buzz API, and focus instead on Google+. While people obviously won't be able to create new posts after that, they will be able to view their existing content on their Google Profile, and download it using Google Takeout.
• Jaiku, a product we acquired in 2007 that let users send updates to friends, will shut down on January 15, 2012. We’ll be working to enable users to export their data from Jaiku.
• Several years ago, we gave people the ability to interact socially on iGoogle. With our new focus on Google+, we will remove iGoogle's social features on January 15, 2012. iGoogle itself, and non-social iGoogle applications, will stay as they are.
• The University Research Program for Google Search, which provides API access to our search results for a small number of approved academic researchers, will close on January 15, 2012.
• Google Bookmarks Lists—This is an experimental feature for sharing bookmarks and collaborating with friends, which we’re going to end on December 19, 2011. All bookmarks within Lists will be retained and labeled for easier identification, while the rest of Google Bookmarks will function as usual. As Lists was an English-only feature, non-English languages will be unaffected.
• Google Friend Connect—Friend Connect allows webmasters to add social features to their sites by embedding a few snippets of code. We're retiring the service for all non-Blogger sites on March 1, 2012. We encourage affected sites to create a Google+ page and place a Google+ badge on their site so they can bring their community of followers to Google+ and use new features like Circles and Hangouts to keep in touch.
• Google Gears—In March we said goodbye to the Gears browser extension for creating offline web applications and stopped supporting new browsers. On December 1, 2011, Gears-based Gmail and Calendar offline will stop working across all browsers, and later in December Gears will no longer be available for download. This is part of our effort to help incorporate offline capabilities into HTML5, and we’ve made a lot of progress. For example, you can access Gmail, Calendar and Docs offline in Chrome.
• Google Search Timeline—We’re removing this graph of historical results for a query. Users will be able to restrict any search to particular time periods using the refinement tools on the left-hand side of the search page. Additionally, users who wish to see graphs with historical trends for a web search can use google.com/trends or google.com/insights/search/ for data since 2004. For more historical data, the "ngram viewer" in Google Books offers similar information.
• Google Wave—We announced that we’d stopped development on Google Wave over a year ago. But as of January 31, 2012, Wave will become read-only and you won’t be able to create new ones. On April 30 we will turn it off completely. You’ll be able to continue exporting individual waves using the existing PDF export feature until the Google Wave service is turned off. If you’d like to continue using this technology, there are a number of open-source projects, including Apache Wave and Walkaround.
• Knol—We launched Knol in 2007 to help improve web content by enabling experts to collaborate on in-depth articles. In order to continue this work, we’ve been working with Solvitor and Crowd Favorite to create Annotum, an open-source scholarly authoring and publishing platform based on WordPress. Knol will work as usual until April 30, 2012, and you can download your knols to a file and/or migrate them to WordPress.com. From May 1 through October 1, 2012, knols will no longer be viewable, but can be downloaded and exported. After that time, Knol content will no longer be accessible.
• Renewable Energy Cheaper than Coal - This initiative was developed as an effort to drive down the cost of renewable energy, with an REpublished our results to help others in the field continue to advance the state of power tower technology, and we’ve closed our efforts. We will continue our work to generate cleaner, more efficient energy—including our on-campus efforts, procuring renewable energy for our data centers, making our data centers even more efficient and investing more than $850 million in renewable energy technologies.

Google Removes Author: Search From Google News

By Navjot Singh
navjot singh
You can no longer search for articles from specific authors in Google News.

As Barry Schwartz reported this morning on Search Engine Roundtable, using the author: firstname lastname command at Google News brings up no results now, and Google has disabled it on purpose. If you think it has something to do with the rel=author movement, it seems that you’re correct. Here’s what a Google employee named Erik explained in the Google News help forum:



The author: search operator is no longer available. For author-specific Google News content, I would recommend use of the Authorship capabilities in Google News, introduced last month. Integration with Google+ circles means easier following and engagement between authors and readers.




The main problem here, as Barry points out on SER, is that rel=author markup rarely seems to show inside of Google News search results.

Google Adds Author Stats To Webmaster Tools

By Navjot Singh

Google has introduced a new report in Google Webmaster Tools named “Author Stats.”

Author Stats shows you how often your content is showing up on the Google search results page. This will show up under Google Webmaster Tools in the “labs” section in Webmaster Tools. It shows the impressions and clicks of the stories found in Google and shows up when you associate your content with your Google Profile.


Here is a picture:


Google said if you have issues with it, you can email them at authorship-pilot@google.com.

What Is “(Not Provided)” in Organic Search Traffic Keywords on Google Analytics?

For about two months we’ve noticed a (Not Provided) item on Google Analytics traffic reports under “Traffic Sources/Google Organic” section. This is an article that has done a good job explaining it. The basic answer is that the keywords surfers used to find this particular site were not shown because the searchers were logged into their Google account when conducting the search.


Google wants to further protect their users’ privacy by encrypting their search results pages (through https://www.google.com).
In Nov. our site received 1,144 visitors from organic Google search which their search keywords were not shown (see below). This is 19.6% of our total Google organic search traffic.

The numbers are similar across the board for our other clients. The fact that we are running blind for about 20% of our total Google organic search traffic is creating a bit of frustration for our team. Mainly because we’re unable to show our clients (or our team) what keywords were used when the site was found on Google organic search traffic with 100% certainty (as we did prior to Oct.).
However, since the total number of organic search traffic has not been effected, we can use the other keywords to get a clear understanding of what keywords people search to find a particular site.
My opinion is that Google needs to find a way to fully show the keywords people use in finding sites. Otherwise, we may have to use other software to monitor our clients’ traffic.

Raising awareness of cross-domain URL selections

A piece of content can often be reached via several URLs, not all of which may be on the same domain. A common example we’ve talked about over the years is having the same content available on more than one URL, an issue known as duplicate content. When we discover a group of pages with duplicate content, Google uses algorithms to select one representative URL for that content. A group of pages may contain URLs from the same site or from different sites. When the representative URL is selected from a group with different sites the selection is called a cross-domain URL selection. To take a simple example, if the group of URLs contains one URL from a.com and one URL from b.com and our algorithms select the URL from b.com, the a.com URL may no longer be shown in our search results and may see a drop in search-referred traffic.

Webmasters can greatly influence our algorithms’ selections using one of the currently supported mechanisms to indicate the preferred URL, for example using rel="canonical" elements or 301 redirects. In most cases, the decisions our algorithms make in this regard correctly reflect the webmaster’s intent. However, in some rare cases we’ve also found many webmasters are confused as to why it has happened and what they can do if they believe the selection is incorrect.
To be transparent about cross-domain URL selection decisions, we’re launching new Webmaster Tools messages that will attempt to notify webmasters when our algorithms select an external URL instead of one from their website. The details about how these messages work are in our Help Center article about the topic, and in this blog post we’ll discuss the different scenarios in which you may see a cross-domain URL selection and what you can do to fix any selections you believe are incorrect.

Common causes of cross-domain URL selection

There are many scenarios that can lead our algorithms to select URLs across domains.
In most cases, our algorithms select a URL based on signals that the webmaster implemented to influence the decision. For example, a webmaster following our guidelines and best practices for moving websites is effectively signalling that the URLs on their new website are the ones they prefer for Google to select. If you’re moving your website and see these new messages in Webmaster Tools, you can take that as confirmation that our algorithms have noticed.
However, we regularly see webmasters ask questions when our algorithms select a URL they did not want selected. When your website is involved in a cross-domain selection, and you believe the selection is incorrect (i.e. not your intention), there are several strategies to improve the situation. Here are some of the common causes of unexpected cross-domain URL selections that we’ve seen, and how to fix them:

1. Duplicate content, including multi-regional websites: We regularly see webmasters use substantially the same content in the same language on multiple domains, sometimes inadvertently and sometimes to geotarget the content. For example, it’s common to see a webmaster set up the same English language website on both example.com and example.net, or a German language website hosted on a.de, a.at, and a.ch.Depending on your website and your users, you can use one of the currently-supported canonicalization techniques to signal to our algorithms which URLs you wish selected. Please see the following articles about this topic:
   
   • Canonicalization, specifically rel="canonical" elements and 301 redirects
   • Multi-regional and multilingual sites and more about working with multi-regional websites
   • About rel="alternate" hreflang="x"
2. Configuration mistakes: Certain types of misconfigurations can lead our algorithms to make an incorrect decision. Examples of misconfiguration scenarios include:
   1. Incorrect canonicalization: Incorrect usage of canonicalization techniques pointing to URLs on an external website can lead our algorithms to select the external URLs to show in our search results. We’ve seen this happen with misconfigured content management systems (CMS) or CMS plugins installed by the webmaster.To fix this kind of situation, find how your website is incorrectly indicating the canonical URL preference (e.g. through incorrect usage of a rel="canonical" element or a 301 redirect) and fix that.
   2. Misconfigured servers: Sometimes we see hosting misconfigurations where content from site a.com is returned for URLs on b.com. A similar case occurs when two unrelated web servers return identical soft 404 pages that we may fail to detect as error pages. In both situations we may assume the same content is being returned from two different sites and our algorithms may incorrectly select the a.com URL as the canonical of the b.com URL.You will need to investigate which part of your website’s serving infrastructure is misconfigured. For example, your server may be returning HTTP 200 (success) status codes for error pages, or your server might be confusing requests across different domains hosted on it. Once you find the root cause of the issue, work with your server admins to correct the configuration.
3. Malicious website attacks: Some attacks on websites introduce code that can cause undesired canonicalization. For example, the malicious code might cause the website to return an HTTP 301 redirect or insert a cross-domain rel="canonical" link element into the HTML or HTTP header, usually pointing to an external URL hosting malicious content. In these cases our algorithms may select the malicious or spammy URL instead of the URL on the compromised website.In this situation, please follow our guidance on cleaning your site and submit a reconsideration request when done. To identify cloaked attacks, you can use the Fetch as Googlebot function in Webmaster Tools to see your page’s content as Googlebot sees it.

Ten recent algorithm changes

Ten recent algorithm changes by Google.com

Cross-language information retrieval updates: For queries in languages where limited web content is available (Afrikaans, Malay, Slovak, Swahili, Hindi, Norwegian, Serbian, Catalan, Maltese, Macedonian, Albanian, Slovenian, Welsh, Icelandic), we will now translate relevant English web pages and display the translated titles directly below the English titles in the search results. This feature was available previously in Korean, but only at the bottom of the page. Clicking on the translated titles will take you to pages translated from English into the query language.



Snippets with more page content and less header/menu content: This change helps us choose more relevant text to use in snippets. As we improve our understanding of web page structure, we are now more likely to pick text from the actual page content, and less likely to use text that is part of a header or menu.

Better page titles in search results by de-duplicating boilerplate anchors: We look at a number of signals when generating a page’s title. One signal is the anchor text in links pointing to the page. We found that boilerplate links with duplicated anchor text are not as relevant, so we are putting less emphasis on these. The result is more relevant titles that are specific to the page’s content.
Length-based autocomplete predictions in Russian: This improvement reduces the number of long, sometimes arbitrary query predictions in Russian. We will not make predictions that are very long in comparison either to the partial query or to the other predictions for that partial query. This is already our practice in English.

Extending application rich snippets: We recently announced rich snippets for applications. This enables people who are searching for software applications to see details, like cost and user reviews, within their search results. This change extends the coverage of application rich snippets, so they will be available more often.

Retiring a signal in Image search: As the web evolves, we often revisit signals that we launched in the past that no longer appear to have a significant impact. In this case, we decided to retire a signal in Image Search related to images that had references from multiple documents on the web.

Fresher, more recent results: As we announced just over a week ago, we’ve made a significant improvement to how we rank fresh content. This change impacts roughly 35 percent of total searches (around 6-10% of search results to a noticeable degree) and better determines the appropriate level of freshness for a given query.

Refining official page detection: We try hard to give our users the most relevant and authoritative results. With this change, we adjusted how we attempt to determine which pages are official. This will tend to rank official websites even higher in our ranking.

Improvements to date-restricted queries: We changed how we handle result freshness for queries where a user has chosen a specific date range. This helps ensure that users get the results that are most relevant for the date range that they specify.

Prediction fix for IME queries: This change improves how Autocomplete handles IME queries (queries which contain non-Latin characters). Autocomplete was previously storing the intermediate keystrokes needed to type each character, which would sometimes result in gibberish predictions for Hebrew, Russian and Arabic.

Should I Change My URLs for SEO?

Written By Navjot Singh Mail to Navjot
Every SEO eventually gets fixated on a tactic. Maybe you read 100 blog posts about how to build the “perfectly” optimized URL, and you keep tweaking and tweaking until you get it just right. Fast-forward 2 months – you’re sitting on 17 layers of 301-redirects, you haven’t done any link-building, you haven’t written any content, you’re eating taco shells with mayonnaise for lunch, and your cat is dead.
Ok, maybe that’s a bit extreme. I do see a lot of questions about the "ideal" URL structure in Q&A, though. Most of them boil down to going from pretty good URLs to slightly more pretty good URLs.

All Change Is Risky

I know it’s not what the motivational speakers want you to hear, but in the real world, change carries risk. Even a perfectly executed site-wide URL change – with pristine 301-redirects – is going to take time for Google to process. During that time, your rankings may bounce. You may get some errors. If your new URL scheme isn’t universally better than the old one, some pages may permanently lose ranking. There’s no good way to A/B test a site-wide SEO change.
More often, it’s just a case of diminishing returns. Going from pretty good to pretty gooder probably isn’t worth the time and effort, let alone the risk. So, when should you change your URLs? I’m going to dive into 5 specific scenarios to help you answer that question…

(1) Dynamic URLs

A dynamic URL creates content from code and data and carries parameters, like this:

It’s a common SEO misconception that Google can’t read these URLs or gets cut off after 2 or 3 parameters. In 2011, that’s just not true – although there are reasonable limits on URL length. The real problems with dynamic URLs are usually more complex:

• They don’t contain relevant keywords.
• They’re more prone to creating duplicate content.
• They tend to be less user-friendly (lower click-through).
• They tend to be longer.

So, when are your URLs too dynamic? The example above definitely needs help. It’s long, it has no relevant keywords, the color and size parameters are likely creating tons of near-duplicates, and the session ID is creating virtually unlimited true duplicates. If you don’t want to be mauled by Panda, it’s time for a change.
In other cases, though, it’s not so simple. What if you have a blog post URL like this?

It’s technically a “dynamic” URL, so should you change it to something like:

I doubt you’d see much SEO benefit, or that the rewards would outweigh the risks. In a perfect world, the second URL is better, and if I was starting a blog from scratch I’d choose that one, no question. On an established site with 1000s of pages, though, I’d probably sit tight.

(2) Unstructured URLs

Another common worry people have is that their URLs don’t match their site structure. For example, they have a URL like this one:

...and they think they should add folders to represent their site architecture, like:

There’s a false belief in play here – people often think that URL structure signals site structure. Just because your URL is 3 levels deep doesn’t mean the crawlers will treat the page as being 3 levels deep. If the first URL is 6 steps from the home-page and the second URL is 1 step away, the second URL is going to get a lot more internal link-juice (all else being equal).
You could argue that the second URL carries more meaning for visitors, but, unfortunately, it’s also longer, and the most unique keywords are pushed to the end. In most cases, I’d lean toward the first version.
Of course, the reverse also applies. Just because a URL structure is “flat” and every page is one level deep, that doesn’t mean that you’ve created a flat site architecture. Google still has to crawl your pages through the paths you’ve built. The flatter URL may have some minor advantages, but it’s not going to change the way that link-juice flows through your site.
Structural URLs can also create duplicate content problems. Let’s say that you allow visitors to reach the same page via 3 different paths:

Now, you’ve created 2 pieces of duplicate content – Google is going to see 3 pages that look exactly the same. This is more of a crawl issue than a URL issue, and there are ways to control how these URLs get indexed, but an overly structured URL can exacerbate these problems.

(3) Long URLs

How long of a URL is too long? Technically, a URL should be able to be as long as it needs to be. Some browsers and servers may have limits, but those limits are well beyond anything we’d consider sane by SEO or usability standards. For example, IE8 can support a URL of up to 2,083 characters.
Practically speaking, though, long URLs can run into trouble. Very long URLs:

• Dilute the ranking power of any given URL keyword
• May hurt usability and click-through rates
• May get cut off when people copy-and-paste
• May get cut off by social media applications
• Are a lot harder to remember

How long is too long is a bit more art than science. One of the key issues, in my mind, is redundancy. Good URLs are like good copy – if there’s something that adds no meaning, you should probably lose it. For example, here’s a URL with a lot of redundancy:

If you have a “/store” subfolder, do you also need a “/products” layer? If we know you’re in the store/products layer, does your category have to be tagged as “featured-products” (why not just “featured”)? Is the “featured” layer necessary at all? Does each product have to also be tagged with “product-“? Are the waffles so tasty you need to say it twice?
In reality, I’ve seen much longer and even more redundant URLs, but that example represents some of the most common problems. Again, you have to consider the trade-offs. Fixing a URL like that one will probably have SEO benefits. Stripping “/blog” out of all your blog post URLs might be a nice-to-have, but it isn’t going to make much practical difference.

(4) Keyword Stuffing

Scenarios (3)-(5) have a bit of overlap. Keyword-stuffed URLs also tend to be long and may cannibalize other pages. Typically, though a keyword-stuffed URL has either a lot of repetition or tries to tackle every variant of the target phrase. For example:

It’s pretty rare to see a penalty based solely on keyword-stuffed URLs, but usually, if your URLs are spammy, it’s a telltale sign that your title tags,copy, etc. are spammy. Even if Google doesn’t slap you around a little, it’s just a matter of focus. If you target the same phrase 14 different ways, you may get more coverage, but each phrase will also get less attention. Prioritize and focus – not just with URLs, but all keyword targeting. If you throw everything at the wall to see what sticks, you usually just end up with a dirty wall.

(5) Keyword Cannibalization

This is probably the toughest problem to spot, as it happens over an entire site – you can’t spot it in a single URL (and, practically speaking, it’s not just a URL problem). Keyword cannibalization results when you try to target the same keywords with too many URLs.
There’s no one right answer to this problem, as any site with a strong focus is naturally going to have pages and URLs with overlapping keywords. That’s perfectly reasonable. Where you get into trouble is splitting off pages into a lot of sub-pages just to sweep up every long-tail variant. Once you carry that too far, without the unique content to support it, you’re going to start to dilute your index and make your site look “thin”.
The URLs here are almost always just a symptom of a broader disease. Ultimately, if you’ve gotten too ambitious with your scope, you’re going to need to consolidate those pages, not just change a few URLs. This is even more important post-Panda. It used to be that thin content would only impact that content – at worst, it might get ignored. Now, thin content can jeopardize the rankings of your entire site.

Proceed With Caution

If you do decide a sitewide URL change is worth the risk, plan and execute it carefully. How to implement a sitewide URL change is beyond the scope of this post, but keep in mind a couple of high-level points:

1. Use proper 301-redirects.
2. Redirect URL-to-URL, for every page you want to keep.
3. Update all on-page links.
4. Don’t chain redirects, if you can avoid it.
5. Add a new XML sitemap.
6. Leave the old sitemap up temporarily.

Point (3) bears repeating. More than once, I’ve seen someone make a sitewide technical SEO change, implement perfect 301 redirects, but then not update all of their navigation. Your crawl paths are still the most important signal to the spiders – make sure you’re 100% internally consistent with the new URLs.
That last point (6) is a bit counterintuitive, but I know a number of SEOs who insist on it. The problem is simple – if crawlers stop seeing the old URLs, they might not crawl them to process the 301-redirects. Eventually, they’ll discover the new URLs, but it might take longer. By leaving the old sitemap up temporarily, you encourage crawlers to process the redirects. If those 301-redirects are working, this won’t create duplicate content. Usually, you can remove the old sitemap after a few weeks.
Even done properly and for the right reasons, measure carefully and expect some rankings bounce over the first couple of weeks. Sometimes, Google just needs time to evaluate the new structure.

Yahoo traffic data into Bing Webmaster Tools reports

Written By Navjot Singh Mail to Navjot
Bing Webmaster Tools will now be showing integrated data from Yahoo within certain areas and reports. Given the combined effort the Search Alliance represents, it makes sense to showcase relevant data from both engines within a webmaster account. Most areas and data within the accounts will not be affected. The short list of areas you will notice changes in are as follows:


On the Traffic Tab: Traffic summary report and Page Traffic reports will be impacted as follows:

1. Impressions – will go up based on combined data numbers
2. Clicks – will go up based on combined data numbers
3. Click Through Rates (CTR) as appropriate from above (change only due to the mathematics involved in the first two items)

Impressions data will rise because we will now be showing you combined impressions for your listings across both search engines. For each query term in the list within the report, your impressions represent the combined number of times your result showed, based on queries initiated by searchers at both Bing and Yahoo. Clicks data will follow the same pattern. CTR data is a factor of the first two items, and will rise or fall based on searcher click activity at each search engine.
The changes affect the numbers shown only. No actual rankings will be affected by the combining of data within Bing Webmaster Tools. As a visual reminder that data is now combined, you will see both the Bing and Yahoo logos directly above the graphs shown on these pages.


At this time the data will be combined, not selectable. The data will also update in any market where Bing is powering Yahoo search.

Yahoo! Rolls Out Redesign for Search Results Pages

Written By Navjot Singh

At Yahoo!, we’re always looking for ways to make the Yahoo! Search experience even more organized and streamlined while serving the most relevant content. We have been working to unify the search experiences across web, multimedia, and vertical search results pages with a design that is clean and intuitive. Today, we are pleased to bring the latest design changes to life across various search results pages!

The following changes are available now on the Web, Images, Video, News, Blogs, Finance and Sports search results pages:

• Clean and Simple – A cleaner and simplistic look and feel that helps you find what is most important to you and to enable you to take action faster.
• Automatic Tabs – Easily accessible tabs will automatically appear right below the Search box to give you the specialized content you may be looking for on our other vertical search results pages. The tabs that may appear, based on the search results content, are Web, Images, Video, News, Blogs, Finance and Sports.
• Left Filters – Filters on the left side of the results will appear, for sorting results by time and related searches.

The query-aware tabs make it easier for you to dive into a specific vertical search experience, such as the Sports search results page example below. The related athletes filter on the left, combined with sports videos results on the right, also enhance this results page.

The improved News search results page will also include filters on the left for news sources, as well as news videos to the right of the search results.

Since last month’s Image Search update, we have made the above changes to the Image search results page, plus we have added:

• A larger pool of Facebook images to also include public profiles and fan pages
• A richer “Latest” pictures experience from across even more Yahoo! content
• Better recommendations at the end of galleries

Below is an example of the Image search results page for the “President Obama” query, which brings you the latest, most relevant pictures to the top, and indicates how long ago each image was published.

Twitter Web Analytics

Written By Navjot Singh | Mail to Navjot

Twitter is a powerful platform for websites to share their content, and drive traffic and engagement. However, people have struggled to accurately measure the amount of traffic Twitter is sending to their websites, in part because web analytics software hasn’t evolved as quickly as online sharing and social signals.

Today we’re announcing Twitter Web Analytics, a tool that helps website owners understand how much traffic they receive from Twitter and the effectiveness of Twitter integrations on their sites. Twitter Web Analytics was driven by the acquisition of BackType, which we announced in July.

The product provides three key benefits:

• Understand how much your website content is being shared across the Twitter network
• See the amount of traffic Twitter sends to your site
• Measure the effectiveness of your Tweet Button integration



Twitter Web Analytics will be rolled out this week to a small pilot group of partners, and will be made available to all website owners within the next few weeks. We’re also committed to releasing a Twitter Web Analytics API for developers interested in incorporating Twitter data in their products.

Canonical Tags- Get the credit you deserve!

Written By Navjot Singh

Does copied content within your own site hamper your site’s ranking? How do you authorize others to use your content and still make sure that you get the search engine credits for the same? These are some of the questions which our SEO experts often face and we have tried to answer these questions here.

Google introduced the concept of the Canonical Tag way back in 2009. It intended to eliminate problems arising due to self-created duplicate content. Web site owners would be able to, by utilizing canonical url tags, give hints to search spiders on which pages to consider original and index higher.

How does it work for you?

The canonical tag is a link that is placed in the HTML header of a web page.

For eg:



This link is to be placed on the copied page. On encountering this link on a web page, search spiders would treat this page as a copy of the original namely http://www.myseopandit.com All the link metrics now flow to the original page. By using this tag, you can ensure that the right content is treated as original and gets the necessary credits for the same.

How is it different from 301 redirects?

Even 301 perform a similar function except that it redirects the visitor to the original page. Canonical tags, however, keeps the visitor on the same page while transferring the link metrics to the original page. In short, 301 redirects both visitor and search engine spider while canonical tag only redirects the spider.

Also from a technical perspective, 301 needs the expertise of a developer while canonical tags only need a basic understanding of HTML.

A word of caution:

DO NOT USE CANONICAL TAGS TO TRANSFER THE LINK CREDITS FROM YOUR INTERNAL PAGES TO YOUR HOMEPAGE. It is not at all a very SEO friendly decision. Your Home Page ideally should not be the only important page on your site
While placing the canonical link in your code, ensure correct formatting and double check the url of the original web page. A wrong url may do a lot of damage.

And now coming back to where we started, you can add canonical links to the copied pages on your site and advice search spiders not to crawl those pages but transfer all link credits and link juices to the original page. You can allow others to publish your content provided they are ready to add canonical links on their site page transferring all link credits to your page.

For more questions on canonical tags, you can post your query as a comment and we would be happy to explore the topic further together!

Google expands search results to include deeper site links

Written By Navjot Singh Mail to Navjot

Search engine result page element, Google sitelinks has been pushed forward with an extension for showcasing major webpages' popular sub-pages. It would therefore mean that the size and number of the sitelinks are on the rise.

Browsers can now dig deeper into the websites showcased in search engine results, thanks to Google adding more details of sub-pages within popular sites in its rankings.

The move will especially boost searches for particular products or brands, because such searches will now showcase results from deeper within a particular site.

Listings of sub-pages displayed in this way include a title and a snippet of the meta description for each page. The more certain Google is that the site presented is the one being searched for, the more deep-page links will be presented – up to a maximum of 12, according to some site

The sitelinks will also group together results from pages from the site concerned which would normally appear lower in the search rankings.

More detailed sub-page listings will improve the service offered to searchers who know approximately what they're looking for. "When Google predicts your target site accurately, the sitelinks work as a quick access point to the core elements of the site,"

Meta descriptions and titles would now be of much more importance which is a point worth noting. The optimization of the said aspects for the space provided would even be a point to think of as a googler.

A new beginning Bing Webmaster Tools

Bing announced the release of the updated Bing Webmaster Tools. Bing reached out to the webmaster and SEO communities to see how it could improve the webmaster tools. User wanted more transparency to see how Bing crawls and indexes their sites, more control over your content in the Bing Index, and more information to help you optimize your sites for Bing.

The redesigned Bing Webmaster Tools provide you a simplified, more intuitive experience focused on three key areas: crawl, index and traffic. New features, such as Index Explorer and Submit URLs, provide a more comprehensive view as well as better control over how Bing crawls and indexes your sites. Index Explorer gives you unprecedented access to browse through the Bing index in order to verify which of your directories and pages have been included. Submit URLs gives you the ability to signal which URLs Bing should add to the index. Other new features include: Crawl Issues to view details on redirects, malware, and exclusions encountered while crawling sites; and Block URLs to prevent specific URLs from appearing in Bing search engine results pages. In addition, the new tools take advantage of Microsoft Silverlight 4 to deliver rich charting functionality that will help you quickly analyze up to six months of crawling, indexing, and traffic data. That means more transparency and more control to help you make decisions, which optimize your sites for Bing.

create a wikipedia page

Before creating an article you should search to check that there is no suitable article that already exists. In the search box near the top right of a page, type the title of the new article, then click Go. If the Search page reports "You may create the page" followed by the article name in red, then you can click the red article name to start editing the article. The very first thing you should write in a new article is a list of the source(s) for the information in it.

Create article for Wikipedia page

Ø Consider creating the article on your user page first. Also make sure that an article does not already exist on the subject, perhaps under a different title. If you find an existing article on your subject, it is best to redirect the name you were thinking of onto the existing article.

Ø Gather references both to use as source(s) of your information and also to demonstrate notability of your article's subject matter. References to blogs, personal websites don't count—Extra care should be taken to make sure that articles on living persons have sources -- articles about living people without sources may be deleted.

Ø Do not create pages about yourself, pages that advertise, personal essays or other articles you would not find in an encyclopedia.

Ø Be careful about copying things, controversial material, extremely short articles that are just definitions, and local-interest articles about places like schools, or streets that are of interest to a relatively small number of people.

Ø If your article will require multiple edits or a significant amount of time to properly list references or make presentable, it is recommended that you place the template {{newpage}} on top of the page to signify to other editors that it's a work in progress. Another option is to start creating the new article in a subpage of your user page. This allows you to take as long as you need to complete a presentable article

Ø Keep making improvements

Ø Add references and External links sections at end of this page.