Welcome to the Q&A Forum

Sadly, the short answer is that you can't have it all. Either you index the separate calendar pages, get more pages/content out there and risk some "thinning" of your index, or you focus on one page, maximize the SEO value, but then lose the individual pages.

I would not 301 or 302 to the individual calendar URLs - that kind of daily URL shifting is going to look suspicious, Google will not re-cache consistently, and you're going to end up with a long-term mess, I strongly suspect.

I actually tend to agree with Muhammed and Paragon that a viable option would be to let the individual days have their own content, but then canonical to the main calendar page to focus the search results. That way, users can still cycle through each individual day, but Google will focus on the core content. In a way, that's how a blog home-page works - the content changes daily, but you're still keeping the bots focused on one URL.

Think of it in terms of usability, too. How valuable is old/outdated content to search users? They might find something relevant on an old page, but they still probably want to see the main calendar and view recent content.

Where are the links to the individual days, if "/calendar" always has today's content? I'm wondering if there's a hybrid approach, like letting the most recent 30 days all have their own URLs, but then redirecting or using rel-canonical to point to the main page after 30 days.

There's no "have to" in most of these situations, but it boils down to this - the more canonical your canonical URL actually is, the better chance you have of Google honoring it. In other words, if you set a canonical tag but then never use that in internal links or your XML sitemap, odds are pretty good that Google may ignore the tag in some cases. You're basically saying "Hey, this URL is canonical! No, this one is! No, this one!" - it's a mixed message, and they're going to try to interpret it algorithmically.

I definitely think pointing to yet another version in the XML sitemap is a problem. Ideally, it would be great to unify your URLs, but if that's not possible, getting the canonical version in the sitemap would be a big help (and introducing yet another variant isn't good, so you'd kill two birds with one stone). As Andy said, if you could create some kind of internal link to the canonical version, even if it's not the main link, that could also help. I only hesitate on that one, because you don't want to end up with a weird, artificial linking structure (just creating links to have links).

Please note, this isn't necessarily a disaster the way you have it. Google could honor the tags properly and generally rank your site correctly. In my experience, though, it's a recipe for long-term problems, and it's worth fixing.

The only evidence is anecdotal. Google is recognizing the canonical in the breadcrumbs, but is ignoring it for the main site. My gut feeling is that they've decided the .ie website is the better match for Google.ie, and so they're ignoring the canonical in that case. There's no way to prove that other than inferring their intent from what we see in the results.

So, here's the question - if you're going the canonical route, you have to start asking if it's worth having two sites at all. If you're not going to let both sites rank, then they have limited utility. At that point, you might just want to 301-redirect to one, unified site, and focusing the link profiles and your SEO efforts.

Obviously, that's a big decision, and you could lose ground in the Irish market (on Google.ie), but by using the canonical, you've already started moving that direction. The hreflang tags are more subtle, which is why I recommended them initially. If your canonical implementation succeeds, you're basically suggesting Google only recognize one site in search results.

Cross-TLD/country, it is possible Google will continue to rank the Irish site on Google.ie even with the canonicals, but now you're leaving it open to their discretion. If you're comfortable with that, no problem. If you really want to consolidate, though, I wonder if it wouldn't be better to completely unify the sites and just make price a user option that Google doesn't see.

Unfortunately, this is a complex problem, and once Google starts mismatching the sites to TLDs, there's not an easy answer. I've seen many international SEOs who I respect struggle with this.

I'm not quite sure I understand what the other 10 translated products are below it, but my gut reaction is that, yes, I would probably canonicalize these particular pages. They're not going to be high-value pages in Google's eyes. From a user perspective, it's good to have a placeholder (until you can put up a translation), but you may want to keep it down to a single page in the index until the translated versions roll out.

Just to clarify - you can use rel-canonical cross-domain, but it's use is a bit more restrictive and Google may ignore the tag in some cases. I haven't seen this particular issue before, but it does seem  like Google is selectively applying your canonical tag.

Did the "hreflang" tags not help? I see you have them in place (I think we may have even discussed this on another question. That would be the more appropriate choice here, but again, Google's application isn't always consistent.

They deprecated the syndication-source tag, so short of 301-redirecting, the canonical tag is about your only other tool. Personally, I'd probably let Google stick with just the hreflang tags for a bit and drop the canonical, giving it a few weeks to see what happens, but it does depend on your goal. Google can be really stubborn about same-language content in nearby countries. We see it a lot with England/Ireland and Holland/Belgium.

It can be frustrating, but definitely give any change time to work (unless it seems like it's actually harming you). It can take Google a long time to re-index/re-cache deep pages, even if they visit your site daily.

So, the "/login" page gets redirected to https: and then every link on that page goes secure and Google crawls them all? I think blocking the "/login" page is a perfectly good way to go here - cut the crawl path, and you'll cut most of the problem.

You could request removal of "/login" in Google Webmaster Tools, too. Sometimes, I find that Robots.txt isn't great at removing pages that are already indexed. I would definitely add the canonical as well, if it's feasible. Cutting the path may not cut the pages that have already been indexed with https:.

Sorry, I'd actually reverse that:

(1) Add the canonicals, and let Google sweep up the duplicates

(2) A few weeks later, block the "/login" page

Sounds counter-intuitive, but if you block the crawl path to the https: pages first, then Google won't crawl the canonical tags on those versions. Use canonical to clean up the index, and then block the page to prevent future problems.

That's pretty much typical search pagination. You can use NOINDEX on pages 2+, but Google currently recommends the rel=prev/next tags:

http://googlewebmastercentral.blogspot.com/2011/09/pagination-with-relnext-and-relprev.html

The new tags seems to be working better over the past few months, but they can be tricky to implement, as they're different for every page (you have to create them dynamically). Historically, I've found that NOINDEX works pretty well for search pagination.

In this particular case, you wouldn't want to use canonical tags. Pagination is a bit unique. Unfortunately, even within internal search, different aspects can require different tags. It gets tricky fast these days.

Sorry, I'm a bit confused, because these sample URLs/situations seem very different from the ones you originally asked about. Search filters vs. sorts vs. pagination all have potentially different solutions and implementing them on a large e-commerce site is very tricky.

Typically, rel=prev/next is better for pagination. For filters, you can use rel-canonical or NOINDEX, but it's often better to try to block some parameters from being crawled at all.

In the examples, you just gave, I suspect that rel-canonical may not have worked properly because Google saw the pages as being too differently. Honestly, though, for deep pages like this, it can also just come down to time. Sometimes, it takes Google quite a while to honor the tags.

There's no harm in trying NOINDEX, but I'd give it time. Don't change tactics every couple of weeks, or you could end up with even more mess.

A canonicalization strategy that covers your entire site is well beyond the scope of Q&A, I'm afraid. It's very tricky on large sites, and I've often found that the results have to be measured and strategies adjusted as you go. You can do it by the book and still have Google ignore it. It depends a lot on your internal architecture and link structure.

Ideally, control the crawl structure first. The less of these duplicates that are available for Google to crawl, the better. Canonical is often effective, but it's also a band-aid in situations like these. NOINDEX sometimes works better, but it's also a patch, too often.

You could use NOINDEX in concert with blocking some of the parameters in Google Webmaster Tools. I don't think it's an ideal long-term solution, but if your index exploded and you've got hundreds or thousands of thin pages, it may be worth doing in the short-term.

So, technically, according to Google, the answer is really ugly. You should canonical to the page level (e.g. "page=2"), but then rel=prev/next to pages 1 and 3 with the same parameters have the current page. So, if you call page 2 with "sort=20" then, "sort=20" should be in the rel=prev/next tags, BUT the canonical should go to page 2 without the "sort=20".

Repeat this for every possible parameter, and welcome to Hell.

You could just use rel=prev/next with the base URLs, and then rel-canonical to the page level. The other option, though, is to hide these parameters completely. Could you store the results/page option in a cookie, for example (that's what I do on a lot of sites) or leave it default, unless someone changes it? If Google always gets the default, then they'll never see that in the URL.

You could also block the sort= parameter in Google Webmaster Tools, although I think combining that with rel=prev/next gets a bit messy.

This is a really weird blend of virtual folder and CGI-style parameters. Typically, we'd see a URL either like:

(1) /page.php?condition=New&keywords=Ford+Focus&category=Exterior

OR

(2) /New/Ford-Focus/Exterior

I think either would be preferable to what you have. By using the hybrid style, Google isn't going to understand how to interpret your URLs, and it could lead to some minor SEO problems. I don't think it'll disrupt crawling or anything huge, but it's always dicey to use strange URL formats. If you can move to something like (2), I really think that's preferable, but even the longer (1) style would probably be safer.

Honestly, though, I've never seen this style of URL in the wild, so I'm making an educated guess here. I just find that different isn't always good, in these cases.

I'm assuming that Irving means "not letting" (sorry if that's not the case) - spinning out every search into a unique page can definitely cause some problems with thin content. Not sure if that's what you're doing, but I'd tread carefully.

Assuming that you have no options (and I really hate to see anyone rely on iFrames in 2012, especially for the home-page - it's a recipe for problems), I agree with Sanket - you can put a rel-canonical tag on the sub-domain pointing back to the main URL. That should at least help Google consolidate the pages.

Unfortunately, it's very likely you're losing ranking value for the content in that frame. There are ways to host content on sub-domains, but mask/rewrite the URLs so that they look like they're part of the main domain. Load-balancing systems (with content across multiple IPs and sub-domains) do it all the time. Obviously, I don't know the details of your situation, but I'd strongly recommend looking for a more permanent solution. The canonical tag will be a bandage here, at best.

I'm afraid that there's no one-sized-fits-all answer to that question. I'd be very wary of being charged by the link, because anyone who focuses on quantity is going to inevitably sacrifice quality. If I promise to build you 50 links for $500, you'll get what you paid for (i.e. not much). Worse yet, below a certain quality threshold, you're taking a long-term risk. In other words, you won't just risk spending your money poorly - you'll risk a penalty or serious SEO problems.

On the other hand, I definitely don't think you should settle for "give us some money and we will do our best" - your link-building company should definitely have a plan and be transparent about it. Preferably, that's going to be a mix of helping you develop content and build/attract links to it, but it should be quantifiable.

Anything related to real estate is going to be competitive, and that means expensive (done right). I'd definitely stay local, honestly - someone who knows the UK and even London market will have not only more relevant experience but more relevant connections. A bunch of links from Istanbul aren't going to help you much. A really great firm may even have PR connections, but obviously that's a different price level.

I'm not sure how helpful it is, in the sense of being good news, but I did something like this to one of my sites on purpose once, and wrote it up:

http://www.seomoz.org/blog/catastrophic-canonicalization

A couple of tips:

(1) I think what Oleg is saying, which I agree with is that if Page A had a canonical to Page B, instead of just removing the canonical tag, put in a canonical tag pointing from Page A to Page A. Sometimes, the self-referencing canonical will help over-ride the old/bad canonical.

(2) Fetch is a good bet, but I'd also re-submit an XML sitemap with just the "bad" URLs. It's not a cure-all, but it can help nudge Google.

Unfortunately, it really can take time to sort out. Make sure your internal links are correct as well. You could temporarily build new internal links (list a few resources on your home-page, for example) to push link-juice temporarily. You could also post the proper URLs on Twitter/FB, etc., to kick them a bit. Of course, that only works for a few pages, not for hundreds.

It's tricky, honestly - even if the content is legitimately/legally syndicated and provides user value, it's still possible for Google to consider it "thin", low-value content. There are a lot of caveats, though:

(1) It's possible for two or more sites to both rank for a piece of content, but the winner usually depends on a mix of signals, ranging from Google's best guess as to the source to the authority of the domain. In some cases, it's possible for a strong syndicator to outrank the source.

(2) It really depends a lot on your content balance. If you use partially-syndicated content in pages with some unique content, you're usually a lot safer. If you use a small percentage of syndicated content across your site, you're also usually pretty safe - worst case, that content may just not rank or get filtered out. The problem is when you rely heavily on syndicated content - it can make your entire site look low-value and trigger issues with Panda.

(3) It depends a lot on the type of content. Many resellers use OEM product descriptions, for example. These pages often don't rank well (as they're plastered across the internet), but it's unusual to see them harm the entire site. If you have a blog that's just re-posts from other blogs (even completely legit ones), though, Google is just going to see your site as a copy and low-value.

If the content is solely for users and doesn't have SEO value for you, you can always NOINDEX it or rel-canonical to the source (cross-domain). That will prevent an risk. Usually, though, it does have some SEO value, so you don't want to block it entirely. In that case, I would just say proceed with caution. Content syndication is perfectly valid, but you don't want to over-use it.

@Streamline is right - as soon as the engines encounter both versions, they see it as two pages. It's no problem for human visitors, but it can create issues with duplicate URLs in the Google index. You can either 301-redirect the "index.asp" version back to the cleaner, root URL or use a canonical. ASP/.Net can be weird about 301s, so the canonical is probably easier.

Generally, we suggest people canonical to the shorter/friendlier version, but the trouble here is that you're using the "/index.asp" version in your internal links. If you can change the internal links to the "/contact/" version, I'd prefer that, but if not, then set the canonical tag to the "/index.asp" version. The most important thing is consistency. If you link to one version but canonical to the other, Google could ignore your canonical tag. Put simply, your canonical URL isn't really canonical, in that case.

Keep in mind that, even if the nofollow does block that path (and I agree with others that that's dubious - I've seen Google take a lot of liberties), there are still potentially other paths to those deeper pages, including old, inbound links. Even if there are no paths at all, but Google previously indexed this pages, they may keep indexing them. Ultimately, you'll probably a need some stronger medicine here.