Welcome to the Q&A Forum

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.

If you're not experiencing any serious problems and just want to prevent future issues, I'd probably use rel=prev/next here:

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

It was designed specifically for paginated content and won't block your link-juice flow to deeper pages. Google has in the past said you can canonical to the "View All", but don't canonical back to page one. I've heard mixed results on the "View All" technique.

One thing, though - you currently have all these pages NOINDEX,FOLLOW'ed, so it's kind of a moot point. What you could do is just lift the NOINDEX on page 1 of results and keep it for pages 2+. That may be your least risky move at this point.

My gut reaction is similar to Stefan's  - a #1 to #5 drop may not be Penguin-related. If you saw a clear drop from 4/24-4/25, though, then that's a different matter. Penguin 1.0 did seem to hit all on one day across all countries and TLDs.

If it was Penguin and you made fixes, keep in mind that they may not have any impact until the next data update, so it depends on when those fixes happened. Penguin 1.1 rolled out on 5/25. If it was Penguin, the data still isn't very conclusive - some people are saying it's mostly on-page keyword issue and others that it's link/anchor-based. I do think toning down the exact-match anchor text is a good bet and definitely take care of any blatant on-page keyword stuffing as well.

If Google just turned down the dial on your EMD, so to speak (and maybe the US took a bigger hit just because of competitiveness), there's not a lot you can do, to be brutally honest. It's not a Capital-P penalty and changing your domain probably won't help - they've just adjusted the volume.

If it's really just for your own reference or limited use, I'd probably set up the cross-domain canonical and keep it off of Google's radar. Later, if you wanted to self-publish, you could remove that.

If it's just your site and theirs, it's probably not a high-risk situation. In some ways, it's more about the relationship. If your pages started ranking instead of theirs, I don't know if that goes against your general agreement with them. I'd probably play it safe for now.

I think you have to be a little careful here, and not just from an SEO standpoint. Now, you're talking about potentially taking someone else's content from behind their paywall and posting it publicly. I don't know the context or the industry very well, but you may be encroaching on a legal gray-area.

I think it's all a matter of degree, which is why these questions are tricky. Generally, I agree with @Crimson - it's like a testimonial. If you use them sparingly to supplement your own, unique content, they're fine. If you build a site out of a line of text and 20 "Acclaims" that are plastered across 500 other website, then you're site is going to look thin. It won't rank for much, and it could even be filtered out or penalized.

So, are they bad? Not necessarily - they can even be good. They should only be a piece of the puzzle, though. Any content re-use should be done sparingly, to enrich your site experience.

I'd just add to what Jason said, which I think is generally on-target. If the magazine really is the "source", then posting all those articles again on your site could look "thin" to both users and search engines. In general, you're not ranking for them now, so you probably won't lose out, from an SEO standpoint. There is some risk if you copy a lot of articles, though. You don't want to look like you're scraping your own content, in essence.

The cross-domain rel-canonical should remove the risk of any sort of search penalty or problems. So, again, it's a question of whether it provides value to your site.

At some point, you have to ask - would it make sense to only post them on your site? In other words, if you're building an audience, does it make sense to build it for someone else? Granted, that's a much larger business and marketing decision (far beyond SEO).

I'm very confused about where the 404 fits in - are these dead pages? To re-capture the link-juice, you'll need to 301-redirect (which it seems like you're also putting into play). In some cases, if the pages are gone or never existed, just let them be gone. If you take every single URL everyone could ever visit to the home-page, you may generate so many 301s that Google starts to get suspicious. We've seen some issues with this lately. In many cases, it's also just not a good user experience.

I tend to agree with Catalyste - in theory, those links will help you, but in practice Google is probably going to devalue that blog network over time. It's just too easy to link to your own sites that way.

Contextual links like that are definitely safer these days then obvious, sitewide links (like footer links), but I'd definitely proceed with caution. At least make them relevant and vary the anchor text - don't over-engineer it.

In most cases, it's more of a filter issue than a penalty. If you link a handful of blogs you own to your own site, it'll probably help for a while, and then Google may turn the volume down. If you're cross-linking 20+ sites, then you're risking a more severe problem.

Yeah, my gut reaction (although there's no one-sized-fits-all answer for every site) is in line with @blu42 - it's not so much about the folder-depth here, it's that this structure is inevitably going to create "thin" content, possibly by the truckload. Post-Panda, the days of just spinning out state+city+product are pretty much gone. It used to work great for long-tail search. Now, you risk it not only not working, but actually damaging your entire site.

It would be much better, IMO to have some kind of state/city structure but then land on the same make/model page, regardless of geography. You can get some kind of geo-targeting that way AND landing pages for products, but don't try to cross them on every variation. The tiny amount of long-tail traffic you pick up will probably be dwarfed by the problems you'll have.

It's not usually a big issue these days, but I'd agree with Zach that the canonical is probably your best bet. Since it's all one page, you just have to put the canonical on either version - they both resolve to the same place. To Google, any URL variation is a new "page", but there's just one page of HTML/code on your site.

Make sure your internal links are consistent. The most common problem is when you're linking to both versions. It's not a disaster, but it can send mixed signals to crawlers (including Google's and ours').

Yeah, it can be tough to tell. Adding to Ben's list, which I'd agree with:

(1) There's a conflicting crawler signal in place - META Robots, 301-redirect, etc.

(2) Internal links still point to the non-canonical version (also a conflicting signal)

(3) It's not duplicate enough, for lack of a better way to say it (Google has over-rided it)

(4) There's something wrong with the target page, like a bad header

Ah, got it - late to the party, as usual I strongly suspect it'll make a noticeable difference, but give it some time and collect data like a madman.

Did you modify the site recently? I'm only seeing about 74 links on the home-page.

In general, I think the other commenters raise good points - 100 links isn't a hard limit, but there's a fundamental truth for both search spiders and human visitors: the more links you have, the less love each link gets. It's always a balancing act, but building a more heirarchical approach can focus attention and internal PR at the top. For 74 links, it's just tweaks (I think you could improve the left side-bar a bit). For 1,000 links, I'd definitely consider a new information architecture.

Matt's statement also implies the changed the codename and/or didn't release the internal codename, so it's really tough to say. Even publicly, they called it the "Webspam update" prior to "Penguin".

I suspect that's just Penguin 1.1 - you could look to the previous month's highlights for Penguin 1.0 - two stand out, IMO:

Keyword stuffing classifier improvement. [project codename "Spam"] We have classifiers designed to detect when a website is keyword stuffing. This change made the keyword stuffing classifier better.

Improvements to how search terms are scored in ranking. [launch codename "Bi02sw41"] One of the most fundamental signals used in search is whether and how your search terms appear on the pages you’re searching. This change improves the way those terms are scored.

The first one is obviously related to Penguin, hard to say on the second. Codename "Spam" isn't exactly telling us much we don't already know

It's tough - on the one hand (especially pre-Panda), the geo-targeted content could help you rank. On the other hand, all those duplicates pose a real risk. These days, I think the risk is substantially greater than the reward. You could end up seeing the entire site devalued, even the non-geo pages.

Technically, Google could ignore the canonical tag if it thought the pages were actually different. You could use META NOINDEX instead, but here's my question - is it currently hurting you?

In other words, Google is ignoring the canonical in some cases and ranking those pages, but are your rankings overall doing ok? If they choose to ignore the tag, but that's not hurting you, I don't think I'd worry about it much. If you're seeing all the pages re-indexed and the duplicates are harming you again, then you may have to get more aggressive.

I do find things get weird with Google when you're home page isn't at the root, and ASP seems to often do this.

Unfortunately, if you 301-redirect to the deeper level, you shouldn't canonical back up to the root - it's a mixed signal. I'm with Martin - if you can't change it, you should probably 301-redirect to "/content/default.asp" and then use that as the canonical version as well (internal links, inbound links where possible, etc.). It's not ideal, but it may be the least worst solution.

Although I generally find NOINDEX works better than Google claims, I think @donford is essentially right - you still need to solve some of the architecture issues, or Google will attempt to re-crawl.

It's a complex problem, and sometimes a combination of NOINDEX, canonical, 301s, 404s, rel=prev/next, etc. all come into play. You don't usually need a "perfect" solution, but one tool rarely fits all situations these days.

Google has suggested that you try parameter handling in GWT. NOINDEX won't prevent crawling (just indexation), but GWT parameters help save crawler bandwidth. I've had mixed results on large sites, honestly, but it may be worth a try.

Unfortunately, it does get tricky in those multi-parameter situations. Googe has suggested that you NOT use canonical to solve pagination issues, unless you canonical to a "View All", and that has some restrictions. So, don't use canonical if it covers "page=2", etc.

Adam Audette has a great post on the subject, but it is complex (he just didn't an updated talk at SMX, but I don't have that link offhand yet):

http://searchengineland.com/five-step-strategy-for-solving-seo-pagination-problems-95494

Basically, you can use canonical and rel=prev/next together:

(1) The canonical tag would point to "?category=used&page=2"

(2) Rel=prev/next should include the "price=high" parameter, and other parameters.

Unfortunately, this makes for tricky code. See the end of this post:

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

I'm not thrilled with Google's solution, but it does seem to be working. Bing only partially supports rel=prev/next, to complicate matters.

The other option is to use Google Webmaster Tools (and Bing Webmaster Central) parameter handling to inform them of the functions of "price=" and "page=". If you're just trying to prevent problems, that's viable (i.e. you don't have any current issues).

You can also NOINDEX the variants - Google says they don't recommend it anymore, but I still find it does work in some cases. I just wouldn't combine NOINDEX with rel=prev/next/canonical - you can end up with a mess.

Do you have any notion of whether their posts are getting indexed faster than yours? Even if they re-post your content, they could get indexed first if they seem to have more authority. You can ping certain services before you roll out to your RSS feed, for example. This post at BlueGlass talks about it:

http://www.blueglass.com/blog/content-scraping-prevention-benefits/

There is always the legal route, include DMCA takedowns. At some point, unfortunately, it may come down to that. If it's just one site (and not 100s), that's more feasible.

Generally agree, although I'd just add that Robots.txt also isn't so great at removing content that's already been indexed (it's better at prevention). So, I find that it's not just not ideal - it sometimes doesn't even work in these cases.

Rel-canonical is generally a good bet, and it should go on the duplicate (you can actually put it on both, although it's not necessary).

I'd agree that, theoretically, 301-redirects are better here, but if it's just the home-page, a canonical tag can definitely sweep up any problem duplicates. If you're getting www and non-www versions of multiple pages indexed, then you probably need 301s. I'd check the index with the site: operator and see. If you're really getting multiples of both indexed, you probably have internal linking issues (inconsistencies). Step 1 in any de-duplication is to make sure you're always linking to the same version. Same with "index.html" - link to "/" internally or the absolute URL of the site (without "index.html").

PHP (code-based) redirects should be fine, as long as they resolve correctly. I've used code-based headers in some other languages (like ColdFusion) and it's generally been ok. If that gets messy, though, and if it's just the home-page, the canonical tag will do in a pinch.

I wouldn't both canonical to the "View All" AND use rel=prev/next - that could be sending mixed signals to Google. I'd let one do its work, if possible. There's another issue, though - you're canonicaling to:

http://www.soundcreation.ro/chitare-chitari-electroacustice-cid10-pageall/

...but the "View All" link goes to...

http://www.soundcreation.ro/chitare-chitari-electroacustice-cid10_-pageall/

...with an "_" (hard to see, since it's linked above). These are two different URLs and could be causing you some serious problems. You're basically sending 3 potentially conflicting signals to Google.

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

It's unlikely the canonical is to blame here, if I'm understanding it correctly. If you tried to canonicalize Page B to Page A, and they were clearly different, one of two things should happen:

(1) Google will just ignore it.

(2) Google will follow it anyway, and drop Page B from the index.

Now, it's theoretically possible that, if Google thought you were using the canonical tag inappropriately to benefit Page A, they could punish Page A, but I've honestly never seen that happen (I've seen it with 301-redirects). Typically, Page B would also have to have a lot of links that you were trying to "clean" (think money laundering). Since Page B is new, this seems very unlikely.

If you're hitting exact-match (or close to it) anchor text hard on Page A, it's certainly possible Penguin came into play, especially if Page A is pushing keywords a bit too hard. It's been tough to confirm Penguin cases, but most of the verified ones I've seen are sudden drops. It's not a subtle, gradual impact.

You could wait for the next Penguin data update, but I suspect you may have to do some link clean up. If there's anything that's not only exact-match anchor text but is sitewide (especially footer links), I'd start there. They seem to be major targets of Penguin. Truthfully, though, we're still collecting data on it.

Unfortunately, I don't know Etsy well, but I think Thomas is right on track - you don't necessarily want to pre-emptively add them, especially if you're not clear on how they work. Typically, it's more for preventing duplicate content issues. We're re-evaluating how we grade the canonical tag, since this is a bit confusing. It's a good practice on some pages (like your home-page) that naturally tend to have more than one version, but adding it sitewide can be tricky.

I've seen some reports of sites being hit by the Penguin data update ("Penguin 1.1") on Friday night, but I'm not clear on the severity. If it's just one page, though, and it was completely de-indexed, that's pretty unlikely.

It is definitely possible for a bad canonical tag to drop a page from the index. I'm a little confused on what you're saying about the two pages. Are they both canonical'ed to a third page, or to each other? Could you give an example (maybe show us two tags that are similar to what you have, but with the exact details changed)?

Technically, Google doesn't recommend the canonical tag in these situations, but it's a gray area. They do say that you can set a canonical to the "View All" version in paginated search results, and you've got something similar here - each sub-page is a sub-set of the full results.

Other options are to simply META NOINDEX the break-down pages or tell Google to ignore the parameters in GWT. Unfortunately, it really depends a lot on the situation and URL/crawl structure, so it's a bit hard to speak in generalities.

I'd be very surprised if this caused you any kind of Penguin problems. I've seen bad canonicalization cause problems in general, but it's probably just coincidental timing here. The biggest risk would be if you had direct traffic/links to the sub-pages. The canonical should pass most of the link-juice, but if a lot of people were running queries like "glass blue widgets" and "plastic red widgets" then canonicalizing those back up to the root page may have weakened your ranking ability.

It's a tough call - often, cleaning up these kinds of near-duplicate pages can be helpful, but it really depends a lot on your audiences and the nature of your traffic. Can you isolate the lost traffic? See if it was coming directly to these deeper pages or via long-tail keywords. If it was, it's very likely cutting off these pages caused some harm. If you've lost ranking on broad keywords or across all pages, then I suspect something else is going on.

One of these URLs just seems to be the encoded version of the other, which should appear as identical. I'm not seeing any evidence that Google is indexing both. I have a feeling that you may have some bad internal links that need to be fixed. I'm seeing the English/German version of this page in the index, but that should be fine. As Khem said, you could use .

Be careful about converting to a "static" version. It's not that it's a bad idea, but the problem is that you could end up turning 2 duplicates into 3 duplicates. You'll still have to canonicalize the dynamic version to the static version. In other words, done badly, changing your URLs could actually make the problem worse.

Rel=prev/next is for paginated series, such as internal search results. While I see you have a pagination parameter on these pages ("idpagina=13"), it doesn't seem like this is a series or that the two pages are even duplicates. I'm a bit confused on the intent, but my initial reaction is that rel=prev/next doesn't fit the bill here.

I'd actually do it the other way - redirect "index.php" to the root ("/") version - Google seems to prefer that and many of your inbound links will be to the root domain (people naturally default to it). Make sure your internal links point to that ("/") as well. See this post that expands on that and gives some .htaccess examples:

http://www.searchmasters.co.nz/articles/78/redirecting-indexphp-to-root-using-htaccess/

You can add the canonical tag to help sweep up the problem, but I think it's best to have a solid 301-redirect in place here, especially if both versions are showing up in analytics.