Not directly. However you could implement an internal tracking method by looking at the referrer "google.com", "bing.com" and "yahoo.com" (+ any other major source you would like to track) and then set a session variable to track the visitor around the site and finally, if he/she converts you can fire an Analytics event based on that session variable.

Not at all, if the URL language matches the content of the page then it should be even better that using a full English URL.

However, I would suggest using domain.com/ar/blog/عنوان بلوق عربية طويلة حقا على شيء مثير جدا للاهتمام for the arabic blog and if there's an english or french version of that page, you can also implement hrelang on them and point them to domain.com/blog/English-blog-title-really-long-on-something-very-interesting

Hope that helps!

Are the same classes in the future link to the same page? are you using canonical tags correctly? Your URL should help diagnose the problem and guide you better,

Does your sitemap include duplicate pages or pages that crawlers wouldn't want to list? (like search results pages, pagination of duplicate pages, etc.)

How do you know that you have 50K indexed pages if GWT reports 700 and a site: search reports over 50k?

You don't see traffic from bit.ly as they actually redirect the user without serving any content, therefore is just a redirection, instead, you should see the actual referrer, facebook, or whatever. However, if you are getting the hit from a facebook page, it is probably an HTTPS page, and therefore, if redirected to a non-SSL page referrer information isn't passed along. However, you could see something like facebook.com/u.php?.... You should use Analytics tracking variables to better understand from which posts are those visitors coming: https://support.google.com/analytics/answer/1033867?hl=en

As for your second question, just like you can interpret the redirection, so can Google or whatever search engine scrapes the page looking for signals. It won't matter if you pass them through bit.ly or services alike, the link ends up in your site (as long as there's a 300 redirection in place, which it is in bit.ly).

Hope that helps!

Those suggesting not to add the SSL pages to the HTTP sitemap are using data back from 2007, when indeed Google showed an error on those sitemaps listing both HTTP and HTTPS pages as they were being recognized as different domains. Those days are long gone. Google had evolved and can now handle sitemaps with both HTTP and HTTPS pages just fine.

G,

It wouldn't do any difference to serve the sitemap over HTTP or HTTPS. As for the http and https pages within the same sitemap, it isn't a problem either.

The only reason I can find for creating multiple sitemaps is for HTML pages, images or videos that do require separate sitemaps.

Does you site uses PHP? If yes, I suggest you test xml-sitemaps.com and it will create the full sitemap for you. If you have a dynamic site, then I suggest getting their commercial version. I've been using it for over 7 years I think and I always get a copy for each site I create. And they offer lots of extras in case you need them (news sitemaps, etc).

Hey G!

You can serve your sitemap in both versions, that won't be any problem and won't trigger the duplicate content issue. So you are safe both ways.

As for the second question: Yes, you should, unless you don't want your pages indexed (any HTTP or HTTPS). I think I saw your site before, and if I remember correctly you had your homepage and login script under SSL, right? Then you should definitely include your homepage in the sitemap but you can leave the login script file out as you don't need that indexed nor google will index it either.

Once you have your sitemap ready, consider including a path in the robots file, like this:

User-agent: *
Sitemap: http://[your website address here]/sitemap.xml

Hope that helps!

Have you tried looking at the headers response you get when accessing those pages? Try with http://web-sniffer.net/ to verify that your site is actually responding with a 301.

Anyway, I think Mozbot AKA Roger, scrapes sites once a week, so if you made the changes only 4 days ago, I would hold for a few more days.

How about using the robots file to disallow those pages? However, if you have a 301 and in the new page a noindex it should work (but who knows, they are still showing the old URLs after a year).

Did to try using the "Fetch as Googlebot"? in WMT? if not, go ahead and then hit the "submit to index" that usually speeds up big changes in sites.

Hope that helps.

Sorry, I do not provide SEO services/consulting. If you are looking for a SEO, you can search in the recommended companies section: http://moz.com/article/recommended

I only contribute here as a hobby and a way to learn more every day

Having a link in the image linking to it's own file does not help your image to get indexed faster or added to a sitemap, at least not that I know of.

In my blog, I don't have the images linking to their file and they are indexed just fine, plus added to the image sitemap that is being generated by "xml-sitemaps" automated script.

Having the image file redirecting to the page having the post is actually serving users with different content that what Google may see, hence the penalty of the image mismatch. If Google offers a link the the image, it should load the image. That's why they also offer link to the page or clicking the image links to the page where the image is. You can read more on the "Image Mismatch" penalty here: https://support.google.com/webmasters/answer/3394137

The "page" you see only the image is the image file itself, there's no page there, just the file.

Wordpress does that by default but you can simply change that default to other options they offer and it is "saved" as the default, like no link, link to another page, etc.

The only benefit of having the link to the image file is that usually images are scaled to fit into posts, and therefore someone may want to see the image in its full size, hence the link to the image file. There are also other ways to deal with that like lightboxes to display images.

You could redirect the image to the page where the image is, but that requires some coding (detecting from where your image is being requested, etc.). Doing that may also carry a penalty from Google (recently announced) called "Image mismatch".

There's no "best practice" here, the best is what you consider best for each image. Take the image scaling example I mentioned, say you post an infographic, perhaps the image is much larger than the size you have available, so it makes sense linking to the image file, so the user can see the infographic in its full size.

Hope that helps!

Hey Daniel,

The canonical should point on every possible filtering to the main page without any filter.

Check the following Q&A from Yesterday: http://moz.com/community/q/canonicalization-w-search-and-filter-operators-parameters

Hope that helps.