Welcome to the Q&A Forum

I can't argue that that would be useful, but to tell you why your ranking changed would basically require reverse-engineering the algorithm. If we could do that, believe me, we would

In terms of future directions, I see us heading a couple of places (this is partly my knowledge of the product, and partly speculative):

(1) Tracking more aggregate metrics, as opposed to individual keyword rankings (including aggregate rankings). The value of any individual ranking is declining as the SERPs become more diverse.

(2) Tracking broader analytics, including landing-page metrics. This may be a necessity as Google strips away more and more keyword data. We expect [not provided] to only increase, for example.

(3) Separating keyword visibility from keyword opportunity. Visibility is a broader sense of how well a keyword or group of keywords are performing (not just ranking, but CTR, social, etc.) and opportunity would be areas that you may be missing out on. I think opportunity metrics would be a lot more actionable than just rank-tracking, but it's not an easy task.

This is something many people on the team put a lot of thought and time into, but as Google and SEO both evolve, the target is always moving.

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.

In theory, it would, but right now we don't have a lot of data about actual changes on any given site. We could track the ranking changes, but not the causal factors. We're working on metrics like what we use on MozCast - basically trying to figure out baseline "flux" for any given campaign, so that you can understand how much movement is normal vs. unusual. Even that is tricky. Rankings fluctuate all the time (even on page refresh, in some cases), so step 1 is sorting out what's abnormal. Then, we have to tie it to things like known algorithm updates and on-page changes.

Your original question had two URLs, one of where the "=" was replaced with "%3D". If that was an actual crawled URL (and not a copy-and-paste error), then it's likely coming from bad links within your own site. That's malformed, so you should definitely check it out. A desktop crawler like Xenu or Screaming Frog could help track down the culprit:

http://www.seomoz.org/blog/crawler-faceoff-xenu-vs-screaming-frog

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.

I'm not finding a great example, offhand, but basically, I'm suggesting that you could have city/state URLs, like:

www.example.com/illinois/chicago

...make model URLs, like:

www.example.com/honda/crv

...and individual product URLs, like:

www.example.com/honda-crv-1234

... but that you DON'T mix the first two and end up with something like:

www.example.com/illinois/chicago/honda/crv

....because you're going to spin out a ton of thin content. There's no perfect way these days to even do a lot of state/city pages - Panda hasn't been kind to that. Ideally, you need to have some sort of unique content for each one. If you're just spinning out content to target keywords, you're likely to harm your site eventually.

My gut reaction is that this sounds much more Panda-like. We've seen many sites with geo-targeted pages and searches gradually lose ranking and traffic over the past couple of years. The problem is that Google has just generally started frowning on spinning out long-tail phrases just to target keywords, and in situations like "serviced apartments + city" I'm afraid that the content quite often ends up being thin.

In your case, though, I'm only seeing about 400 pages in Google's index, so it doesn't look like there are very many variations or that it's enough volume to trigger Panda-scale problems. I don't think these pages are very strong, as they're basically search results with minor variations in the copy/title/etc., but I'd be surprised to see a sudden ranking drop because of these pages.

Your link profile does seem to be populated with a lot of low-value directories and you're using long, exact-match anchor strings. It may not be the branded text so much as a lot of text that just looks unnatural. I also notice, though, that some of the links we have in OSE appear to be gone now:

http://impulsesdirect.org/detail/link-3883.htm

You may have started removal - I'm not sure. You could remove some of these, but frankly, you won't be left with a lot. Anything you do moving forward is going to have to involved building or attracting higher quality links and developing content that is more than just directory-style pages. Google just doesn't value niche directories the way they used to, and I think that attitude is here to stay, unfortunately (I have a former client in the same boat).

Unfortunately, pagination + sorts gets ugly fast. Technically, the rel=prev/next tag should contain the sort parameter AND then you should canonical to the main pagination page. So, for example if you had a page like:

www.example.com/search.php?page=2&sort=asc

You should have tags like:

• Rel=Prev: http://www.example.com/search.php?page=1&sort=asc
• Rel=Next: http://www.example.com/search.php?page=3&sort=asc
• Canonical: http://www.example.com/search.php?page=2

In practice, it's incredibly hard to implement. So, you could do a couple of things:

(1) Block the sort_by parameter with Google Webmaster Tools parameter handling

(2) Use META NOINDEX, FOLLOW on all pages 2+ of search and sort URLs

I don't find Robots.txt works that well, in practice, and 800K blocked URLs can make Google jump. I'm actually confused by how Google is crawling the sorts at all (since they're form-driven). It looks like you put the sorts in your pagination links. Would it be possible to store any sorts in a cookie or session variable and not add those to links?

Given your current situation, and that Google has indexed thousands of sort URLs (from what I can see), I think the Google Webmaster Tools approach might be the safest. This is a complex problem, though, and you may need to consult someone.

So, I've probably dug into "Phantom" as much as anyone, and I'm afraid the picture isn't very clear. I've heard of people who got hit by Phantom and then recovered at Penguin 2.0, people who got hit and then hit again, and I've seen multiple situations where people got hit by Phantom only.

My gut feeling so far is that this was an independent update and not a Penguin 2.0 test. They might both be related to link factors or seem conceptually similar, but I don't think Phantom was an early or partial release. It happened across data centers and appears to follow a pretty typical algo change pattern.

From a "pure" SEO standpoint, here's what I'd say we know about user metrics:

(1) Bing has confirmed using click-through rate (CTR) and "dwell time" as ranking factors. Dwell time is the time it take a visitor to return to search results from a site, so it's related to both bounce rate and time-on-site.

(2) Google has officially said that they do not use bounce rate as a ranking factor. Google historically defines things narrowly, so we don't know if they factor in dwell time. Reading between the lines, they seem to find it unreliable.

(3) I'm not sure if Google has confirmed this, but they very likely factor in CTR.

(4) We don't know for sure how user factors fit into Panda, although people have certainly suggested a connection. My gut reaction is that, if it's part of Panda, it's not a large part.

Of course, looking beyond SEO, reducing your bounce rate and increasing your page-views and time-on-site is great. You've improved your engagement and it will help you. This is in no way wasted effort, and even if it doesn't have a direct, immediate impact on SEO, it will have indirect effects.

You mentioned the CMS spun out a lot of duplicates. If you have text-thin pages AND a ton of duplicates, that certainly could cause some problems. Have you taken steps to control and de-index those duplicates? That would probably be the first place I'd look, from your description of the problem.

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.

Essentially yes - pages 2+ of search just look "thin" to Google. They tend to have similar title tags, META descriptions, etc., and Google honestly isn't all that fond of indexing search pages in the first place (they don't want their search to land on your search). Those 2+ pages also don't tend to attract links or make a lot of sense for someone landing on them. By using META NOINDEX,FOLLOW, Google can crawl those searches to deeper pages, but the actually search pages don't dilute your overall site and search index.

Google's preferred method (or so they say) in 2012 is rel=prev/next, but I find that implementation can be much trickier than META NOINDEX. It's a difficult topic, and I honestly find that the ideal approach varies wildly from site to site. It's important to plan well, implement careful, and measure the results.

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.

Google's official advice is that rel=prev/next should include the additional parameters, but then you should rel-canonical to the non-parameterized URL for that individual page. Setting it up properly, unfortunately, is difficult and I feel that it's too confusing to be adopted by most sites.

You can META NOINDEX pages 2+ and sorts and see how it works, or you can also block parameters in Google Webmaster Tools (or tell them those parameters are for pagination). Unfortunately, the "right" answer often depends on the size of the site and the scope of the problem. In some cases, I've found that the by-the-book approach works fine, and in others we had to throw out Google's book and improvise. I wish I could tell you that there's a one-sized-fits-all answer, but there doesn't seem to be, in my experience.

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.

Unfortunately, I don't know the Twylah system, but Google is indexing 138 pages from your main site and 1,650 (about 12X your main site) from the "tweets." sub-domain. I strongly suspect that this is going to look like thin content, and when it's overpowering your main site's content, you could see really SEO problems.

I'm not sure what the goal is, but I doubt the gains from this system will offset the losses. If it's valuable to users, no problem. From an SEO perspective, though, I strongly doubt this is beneficial.

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.

The truth is that we're not entirely sure "AuthorRank" even exists, at least not yet, and not in the way most people mean it. Google+ certainly seems to have an impact on personalized rankings, especially time-sensitive (QDF) queries, and authorship mark-up is a nice thing to have, but whether rankings are boosted by the strength of an author's profile is an open question with circumstantial evidence at best, IMO.

Right now, company profiles and author profiles have different advantages. A strong company profile might get a Google+ "brand box" in the SERPs, whereas a strong author profile (or, at least, a properly set up one) could get authorship thumbnails in individual searches. In most cases, though, that's still going to take other signals, like links, and isn't just a result of having a lot of followers.

So, I think it depends on your goal. If you want your business to potentially register "brand" signals ("entity" signals may be a better way to say it), then building your G+ business profile is one piece of that puzzle. If you want to be seen as an influential individual and help your posts rank, then pushing your individual authorship signals and G+ account may be more advantageous. It really depends on what you want to accomplish long-term.

It's really tough for us to tell what those parameters do, so you have to be careful. Just because a URL has certain parameters doesn't mean it's a duplicate. If these really are duplicate or near duplicate pages, you've got a few options:

(1) Consolidate them with rel-canonical

(2) Block them with META NOINDEX (Meta Robots)

(3) Block/ignore the parameters in Google Webmaster Tools

It's a complex subject, and I have a mega-post about it here:

http://www.seomoz.org/blog/duplicate-content-in-a-post-panda-world

I'm not a Magento expert, though - Joost de Valk has some resources worth checking out:

http://yoast.com/articles/magento-seo/

Hmmm... I'm seeing the same page for both searches and you rank higher (about #5) for the longer-tail search (#10 for me on the broader search).

Unfortunately, the violin/viola pages are very similar, content-wise, and might appear thin. I realize that they're legitimate products, but you may be diluting your ranking ability by indexing every variation in this way. You've got 39 arrangements of Für Elise indexed on Google - while they're all unique products, when you multiple that against all of your products and then start to consider search pages, etc., odds are that you may just be trying to rank too many pages.

There's no easy answer here. You could build more authority, of course, or you could consider consolidating somehow - possibly trying to rank one parent page for each score and then let people select the variations/instruments from that parent page (most likely with canonical tags). There's always a trade-off, but right now you're spreading your ranking ability across a lot of similar pages.

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.

Anthony's definitely got the basics covered. How to handle any particular situation can get pretty tricky. I wrote a post about it, and that post got very long very fast:

http://www.seomoz.org/blog/duplicate-content-in-a-post-panda-world

I took a quick look at your campaign (I have Staff access), and it seems your login page is carrying an event ID - so every event is creating a different URL, but they all land on one page. That could spin out 100s of duplicates on Google, and that login page has little or no search value. A canonical tag would definitely be a good bet here.

You may have other issues going on, but clean up one at a time - getting that number down can definitely be beneficial and help boost your ranking power.

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.

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.

Yeah, I'm afraid Chris is right. There's really no way to tell Google to index both pages but then not give them control over which one ranks. Google is naturally going to prefer the full content page, because they want to get people to the best "answer", in a sense.

Truthfully, I think it's a better search user experience, in most cases. Internal search users can travel from the snippet to the post, but search users may get frustrated at going from Google's results to your results, and not straight to the resource. If you force the first step on search users, you may actually increase your bounce rate and harm your overall performance.

Are these live pages, or did something page (I can't seem to access them). Looking at the URLs, it seems like these are slightly different products, so I'm not clear if the canonical tag is appropriate.

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.

It honestly sounds like you're on the right track - you do need to explicitly mark those (and META NOINDEX should be fine). Could you just request removal for all private pages? Worst case, Google removes some that aren't in the index, or attempts to. Since the public/private setting can be changed, you can't really put the private pages all in one folder (real or virtual) - that would make life easier, long-term, but probably isn't useful/appropriate for your case.

I'd also recommend having a clean XML sitemap with just the public entries (updated dynamically). That won't deindex the other pages, but it's one more cue Google can use. You want all of the signals you're sending to be consistent.

I agree with Doug, though - this is really tricky, because ideally you would want people to share these pages, and if you NOINDEX then you're losing out on that. My gut feeling is that, until your site is stronger, you probably can't support 3K near duplicates (and counting). If you want to get sophisticated, though, you could dynamically NOINDEX and only noindex posts that have very little content or our obvious dupes. As people fill out or share a product, you could remove the NOINDEX.

Definitely review George's comment as you need to figure out why they're being crawled. As Andrea said, any solution takes time, I'm sorry to say. Robots.txt is not a good solution for getting pages removed that are already indexed, especially in bulk. It's better at prevention than cure.

META NOINDEX can be effective, or you could rel=canonical these pages to the appropriate non-AJAX URL - not sure exactly how the structure is set up. Those are probably the two fastest and more powerful approaches. Google parameter handling (in Webmaster Tools) is another option, but it's a bit unpredictable whether they honor it and how quickly.

You can only do mass removal if everything is in a folder, if I recall. There's no way to bulk remove unless all of the pages are structurally under one root URL.

I'm not 100% sure, but their messaging on this has been pretty inconsistent, and it's clear they still treat the disavow tool as a beta. If you didn't get any errors and the file seems to be in place, you're probably ok, and it's just going to take some time. I wouldn't take lack of confirmation as necessarily a bad sign, as long as you know the file format was ok. At best, they acknowledge receipt - the timeline of when they actually disavow and when that could impact a Penguin problem could be weeks or months, unfortunately.

It really depends on the platform you're on and the way the page level redirects are set up, but if you list all the rules for the existing pages, you can always add a redirect at the very end. If implemented properly, anything left over should just that rule.

The alternative is to build a custom 404 handler that actually implements a 301-redirect to the new site.

I'd agree with this post, though - if the content really is dead, in some cases, it's better to let it 404 -

http://www.seroundtable.com/archives/022739.html

If you're really starting over, and for pages that aren't very active (no links, very little traffic), it can make more sense to clean things up. There's no one-sized-fits-all answer - it depends a lot on the scope of the site and the  nature of the change.

Could you explain the business model a bit? If people can land directly on the product page, why do you want to take them to the log-in page? What are they logging into? Is the product an actual, physical product, or a service, SaaS, etc.? I realize you many not be able to provide all details, but if I can understand the business logic a bit, that would help. This is as much a business/conversion issue as a technical SEO issue.

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.

If these are all coming from one site, and you're worried about them, this is actually a good case for the disavow tool. You can disavow an entire domain in a single line:

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

As Michael said, getting Google to actually recrawl/recache all of those pages can take quite a while. With the ad gone, it's probably a non-issue and they'll eventually clear out, but disavow would remove any lingering doubt.

Unfortunately, there's no way to tell if you've been penalized without knowing more about the site, traffic, etc. I'd say its unlikely for a paid link from a single site, especially if that link was subsequently removed. Googles isn't usually that aggressive about it, especially if your site generally has solid authority/reputation.

While I think keyword cannibalization is a valid concern, it's natural for there to be some overlap when a site is clearly focused on a topic. I hate to over-generalize, but my gut reaction is that the home-page and a single category page aren't a big problem. Sure, they'll compete a little, but we're only talking about two pages, and the home-page is generally already stronger. I think the canonical might be artificial here (these aren't true duplicates, and it could look a bit odd to Google).

I'd think more about how the two pages can co-exist - are their certains aspects of the keyword that one more naturally fits than the other? Could you reflect those in the on-page content/tags (TITLE tag, especially)? If the topic merits an entire site, there almost definitely enough facets to it that two pages can live together perfectly well.

Again, don't to over-generalize, but I think you may be worrying too much about this one. If the pages compete in an undesirable way later, you can always add a canonical, but two pages shouldn't be a big issue.

Unless I'm misunderstanding, do NOT 301-redirect. That's going to kill your category page, as 301s impact human visitors as well as search bots.

Just want to add one comment. Where people end up in trouble is when they apply the canonical tag too broadly (to non-duplicates). This tends to happen when you have a CMS and one template drives multiple pages. So, let's say that all of your product pages are created by:

http://example.com/product.php

...and you just add IDs to that to create a product, like:

http://example.com/product.php?id=123

If you add a canonical tag to "product.php" pointing to a single product, you would essentially tell Google to canonicalize every product page on your site to just that one product. This is because that one physical file impacts hundreds of URLs. So, in that case, you would have to make sure the code logic was in place to apply the proper ID.

I tend to agree that it could just be a short-term re-evaluation period, but I do understand that patience is hard to come by in these situations. I have one concern - I assume the META refresh was acting as some kind of redirect to a different URL? When you removed it, did you canonical the other URL somehow? Just removing the refresh wouldn't consolidate the link "juice" of the various URLs, so it could be that you went from one form of fragmentation to another, different form.

That's just speculation, since I don't fully understand the old/new setups. If you can provides some details with fictional URLs, we might be able to dig in deeper.

If reconsideration worked and you got a reply from Google, it's likely that you were facing a manual penalty (either instead of or in addition to Penguin). So, it may be that Penguin or some other algorithmic penalty is in play (echoing what Andy said).

Once a penalty expires or is lifted, I'm unaware of any kind of dampening on the site (like, 50% penalty for 3 months and then 25%, etc.). This is much more likely to be a situation where you have multiple layers of problems (some could be technical, etc., and not penalties) and you've removed just the top layer.

Sorry, I'm not really clear on what the question is - these seem like general IT items unrelated to the SEO problem. The JS rewrites definitely can be tricky and depend completely on the code in question - I can't really provide a general resource.

Not sure how the alias domains tie in, but they definitely need to be part of any redirection scheme. I've used mod_rewrite for pretty large-scale stuff (as do many large sites), but it's possible to write bad/slow rules. It really depends on the scope. I'm not sure if you're talking about 100s or 1000s (10000s, etc.) of pages. Writing the rules for a big site is beyond the scope of any general Q&A. That's something your team is going to have to really dig deep into.

I feel like they might be over-thinking this one issue and trying to fix everything all at once, but I can't say that confidently without understanding the situation. I think it might be better to tackle these things one at a time.

I wish I had a good answer. When Google takes liberties with snippets, it's not always easy to sort out why. The first stop is usually making sure the query is in the META description and the description isn't too long, and you've got both of those covered. Two long shots, but easy to try:

(1) Add the NOODP Meta Tag (). Sometimes, it prevents not only descriptions from the Open Directory Project, but also Google taking liberties. Sometimes.

(2) Consider pulling your domain name out of the META description. You're saying "Myrtle Beach Hotels" twice in both the title and META descriptions, and it's possible that that looks very slightly spammy to Google. If you can, make the description slightly more natural - the length is about right.

Again, these are in no way guaranteed, but they're easy to try. I don't think tweaking the structure of the page is going to help. It's not Google recognizing the search results that's a problem - it's why they choose to rewrite. Unfortunately, we don't have a good handle on the why, at least in some cases.

I can't prove it would cause substantial improvement, but right now it's just in your way, and you'll never know. To me, that kind of clean-up is a no-brainer, because it's no risk. At worst, it cleans up the code, improves caching (and load times as you said), and makes updating easier. At best, you see measurable gains.

As a former developer and dev-team manager, I have to say, too, that it's not a tough fix to split out that JS. It would probably make the dev teams life easier down the road. If they're acting like it's a Herculean task, then either (1) they just don't want to do it, or (2) you need a better dev team.

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.

It's just one of those things where you're always going to be wondering if the bloated code is causing problems, and it's going to drive you nuts. Fix it, and worst case, you'll rule out a cause. Some days, that's the best we can do.

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.

This is a constantly changing area of SEO the past couple of years, but my general feeling is that the rel=next/prev tags are working pretty well. They're low risk, and it can help you reduce duplication in Google's eyes without de-indexing the pages (page 3 could still rank, for example).

The biggest downside of the tags is that they're a bit tricky to implement, especially if you have search filters and sorts (in which case the proper tags get pretty complicated fast). Another option (as Nakul mentioned) is to NOINDEX pages 2+, which is simpler but would knock those extra pages out of ranking contention. That's a route I'd go only if you seemed to be getting hit hard for thin content.

The only area where I'll disagree slightly with Nakul is that handling pagination for SEO isn't always one of those areas where usability considerations help much. From a core architecture and internal search perspective, give your users a good experience, absolutely. From the standpoint of how to index those search pages, though, it's almost all about how Google views near-duplicate content. This is an area of SEO that is getting more technical and really comes down to the quirks of how Google indexes content.

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.

Sorry, I'm not clear on whether these are paginated search results or actual property pages that vary only by a small amount. As @SEO5 said, if these are paginated search results, you could use rel=prev/next. It's a bit tricky to set up with search filters (you need rel=prev/next + rel=canonical).

If these are nearly identical property pages, then it depends on how they differ. If they only differ by one attribute, I'd probably lean toward the canonical tag.