Oh, sorry, it's a session ID, not a tracking/affiliate sort of ID. Honestly, the best solution is to avoid URL-based session IDs entirely, and store it in a cookie or session variable, but yeah, I realize that's not always feasible.

In this case, the 302-redirect should help keep link-juice at the root URL, and is probably a good bet. I think adding the canonical tag to the parameterized versions is a good backup, though. You could also block that parameter in Google Webmaster Tools, since it really has no search value at all.

Yeah, internally, "nofollow" still dilutes PageRank, so it doesn't really have a big impact. Practically speaking, I don't think there would be much difference. The links have a customer-facing purposes, I assume, and you just don't want the end result indexed. That should be fine. The only advantage to nofollow might be that it would waste a little less crawl bandwidth (instead of bots visiting the page and then seeing it's blocked, they wouldn't bother). I've tried it both ways in the past (after Google changed the PR-sculpting rules), and could never really measure much difference.

This can get tricky when you dive into the details, but I general agree with Takeshi and EGOL - consolidate or canonicalize. If the products are different brands/versions of a similar item, it's a bit trickier, but these variations do have a way of spinning out of control. In 2013, I think the down side of your index running wild is a lot higher than the up side of ranking for a couple more long-tail terms. It does depend a lot on your traffic, business model, etc., though. I'm not sure any of us can adequately advise you in the scope of a Q&A.

You should be able to customize a 410 just like you do a 404. The problem is that most platforms don't do that, by default, so you get the old-school status code page. That should be configurable, though, on almost all modern platforms.

I tend to agree with Martin - it seems like there's probably a way to preserve some of the power of the old site and 301-redirect selectively (or potentially use cross-domain rel=canonical tags), but it would take a much deeper understanding of the site than Q&A allows.

If you rebuild the site from scratch, you'd almost always want to de-index the old site. I'd flat out remove it via Google Webmaster Tools - it's the fastest method. Leaving both sites crawlable is only going to compound your problems and haunt the new site.

I'd warn, though, that if this is Panda-related, just moving the content won't solve your problems. You do have to sort out why they happened in the first place, or the same algorithmic issues will just come back. In other words, if the problems are content-related, then it doesn't really matter where the content lives. If the problems are link related, then moving will remove the problems. Of course, moving will also remove and advantages you currently have based on good links.

Unfortunately, this isn't a problem that can be addressed without a pretty deep audit. My gut feeling is that there may be a way to preserve some of the authority of the old site, but you really need to pin down the problems. Panda + Penguin is a wide swath of potential problems and just isn't enough information to do this right.

So, I'm confused - are you looking to keep both sites active? If you're just moving the tools to a new domain, you could NOINDEX the old pages. If the link-based penalty isn't too severe, you might try a cross-domain rel=canonical on the old site. Unfortunately, without understanding the penalty profile, it's a bit tricky to advise. It's really a cost/benefit trade-off - how much risk of carrying the penalty are you willing to accept vs. the alternative of cutting off all authority and starting over on the new site.

If you've had Panda-related problems, though, I wouldn't keep the tools crawlable on both sites. That seems more likely to prolong your problems than it is to solve them.

Unfortunately, the rules may differ from page to page and will be entirely dependent on how your pages are generated. If it's just a matter of the "index.cfm" version vs. root ("/") versions of pages, those canonical should be straightforward. For the other parameters, though (like "i", "fs", etc.), it depends entirely on the function of those parameters.

I know ColdFusion reasonably well, and even given that, I couldn't give you a one-size-fits-all rule that would solve the problem. It really has to be guided by your site structure and code/data logic. Personally, I'd start with the pattern that generates the most problems and solve that one first. In other words, if one template (like "/press-releases") generates dozens or hundreds of duplicates, deal with that first. If you solve the top 3-4 problems, you may clean up quite a bit. That could be more effective than trying to fix everything at once.

Unfortunately, what Google can do and what they actually do can really vary. If you're mixing signals and doubling up the canonicals, the odds that they'll get it right are pretty low, in my experience. I think it's worth the fix, if these are traffic-generating pages.

It's hard to be completely sure without digging into the crawl, but keep in mind that Xenu is crawl-based, to both things can be true. Somewhere, a link to that page is 8 levels deep, event if it 301-redirects to a page that is only 1 level deep. This could indicate a problem and/or a mismatch in your architecture. Ideally, if you're 301-redirecting the page, then there should be no internal links to the old URL. Mixed signals can make messes, so I'd try to pin down where this link is coming from. Xenu probably is seeing something real.

Yeah, don't use rel=canonical for the same purpose as rel=alternate - the canonical tag will override the alternate/lang tag and may cause your alternate versions to rank incorrectly or not at all. It can be a bit unpredictable. If you only wanted one version to show up in search results, then rel=canonical would be ok, but rel=alternate is a softer signal to help Google rank the right page in the right situation. It's not perfect, but that's the intent.

As for multiple canonicals like what you described, that's essential like chaining 301-redirects. As much as possible, avoid it - you'll lose link equity, and Google may just not honor them in some cases. There's no hard/fast limit, and two levels may be ok in some cases, but I think it's just a recipe for trouble long-term. Fix the canonicals to be single-hop wherever possible.

This is generally an exception Google supports - for example, they say that you can use rel=prev/next and rel=canonical in conjunction, where one handles pagination and the other handles sorts/filters. In the case of a sort (like ascending/descending) the actual results could be very different, but the intent is still legitimate. They generally understand you're trying to clean up these pages.

In a perfect world, these filters wouldn't create unique URLs, honestly, but now that they already exist, you have to manage them. The other option would just be to META NOINDEX those filter URLs or set them up in parameter handling in Google Webmaster Tools. I tend to prefer the canonical here, personally.

Ah... yeah, that's tricky. There's no magic solution, I'm afraid. You've really got three options:

(1) Leave it alone

(2) Re-organize your site architecture to push individual date pages down a level or two, so that they get less internal link-juice.

(3) Re-organize such that you focus search engines on chunks of time or maybe date/aspect combinations, but then de-index the individual date combos. This would take a much better understanding of your site structure than I currently have. The goal would be to focus your index on some smaller combination of pages that still covers 80% of your search traffic.

The big problem is just that this is a lot potential dilution, and I suspect that many of these pages look very similar to Google. I'm also certain that not all pages have the same value, either for SEO or users, so there's some hybrid approach where you could prune back but not lose everything. Long-term, I think that's worth the time and trouble to sort out, but it's not an emergency or something I'd rush into.

Dupe-content-wise, you should be fine. iFrames just make me itchy these days, and I've never thought they were good for users, but it shouldn't be a disaster for SEO. The biggest problem is probably just that you're not really getting any SEO value - it's really just direct traffic via a referring site. Granted, it's better than nothing, and I know from painful experience that sometimes you have to take what you can get in these situations.

Unfortunately, it depends entirely on your implementation, but the short answer is that it depends if the images are loaded all at once and only displayed by scrolling or if they're loaded as you scroll. The latter is essentially what "infinite scrolling is" - it's generally not actually infinite, but scrolling will cause load events until there's nothing left to load.

The key is that the content has to be crawlable somehow and can't only be triggered by the event, or Google won't see it. So, if you're going to load as you go, the infinite scrolling posts should apply. If the images are pre-loaded, then you shouldn't have a problem, but I'd have to understand the implementation better.

Keep in mind that just adding 20 images/videos to this page isn't going to automatically increase the quality. Images have limited Google can crawl, and unless they're unique images that you own, they'll potentially be duplicated across the web. If adding those 20 images slows down the page a lot, that could actually harm your SEO and usability.

Thomas is generally correct here, although Google has since begun treating .co as a "generic" TLD, which is to say they no longer geo-locate it to Colombia. See this reference:

https://support.google.com/webmasters/answer/1347922?hl=en

So, the Colombia association won't hurt, but it won't be geographically connected to Colorado, either. There is some chance that you could pick up the "Co" on a keyword match, if someone searched "Denver, Co" and you owned "denver.co", for example. That's speculation on my part, though. I certainly wouldn't count on any benefit.