Does Google pass link juice a page receives if the URL parameter specifies content and has the Crawl setting in Webmaster Tools set to NO?

[sesertin]

I'm getting a bit lost with your explanation, maybe it would be easier if I saw the urls, but here"s a brief:

I would not use parameters at all. Cleen urls are best for seo, remove everything not needed. You definately don't need an url parameter to indicate that content is unique for 25%of traffic. (I got a little bit lost here: how can a content be unique for just part of your traffic. If it is found elsewhere on your pae it is not unique, if it is not found elswehere, it is unique) So anyway those url parameters do not indicate nothing to google, just stuff your url structure with useles info (for google) so why use them?

I am already using a link rel=canonical statement. I don't want to add this to the robots.txt file as that would prevent the juice from being passed.

I totally don't get this one. You can't add canonical to robots.txt. This is not a robots.txt statement.

To sum up: If you do not want your parametered page to appear in the serps than as I said: Set Crawl to yes! and use rel canonical. This way page will no more apperar in serps, but will be available for readers and will pass link juice.

[surveygizmo]

My fault for not being clear.

I understand that the rel=canonical cannot be added to the robot.txt file. We are already using the canonical statement.

I do not want to add the page with the url parameter to the robot.txt file as that would prevent the link juice from being passed.

Perhaps this example will help clarify:

URL = website.com

ULR parameter = website.com/?v3

website.com/?v3 has a lot of backlinks. How can I pass the link juice to website.com and Not have website.com/?v3 appear in the SERP"s?

[sesertin]

I can just repeat myself: Set Crawl to yes and use rel canonical with website.com/?v3 pointing to website.com

[Dr-Pete]

If you're already use rel-canonical, then there's really no reason to also block the parameter. Rel-canonical will preserve any link-juice, and will also keep the page available to visitors (unlike a 301-redirect).

Are you seeing a lot of these pages indexed (i.e. is the canonical tag not working)? You could block the parameter in that case, but my gut reaction is that it's unnecessary and probably counter-productive. Google may just need time to de-index (it can be a slow process).

I suspect that Google passes some link-juice through blocked parameters and treats it more like a canonical, but it may be situational and I haven't seen good data on that. So many things in Google Webmaster Tools end up being a bit of a black box. Typically, I view it as a last resort.

[surveygizmo]

I agree. The URL parameter option seems to be the best solution since this is not a unique page. It is the main page with javascript that calls for additional content to be displayed in the form of a lightbox overlay  if the condition is right. Since it is not an actual page, I cannot add the rel-canonical statement to the header.  It is not clear however, whether the link juice will be passed with this parameter setting in Webmaster Tools.

[Dr-Pete]

This sounds unusual enough that I'd almost have to see it in action. Is the JS-based URL even getting indexed? This might be a non-issue, honestly. I don't have solid evidence either way about GWT blocking passing link-juice, although I suspect it behaves like a canonical in most cases.

[Jen_Floyd]

This question deals with dynamically created pages, it seems, and Google seems to recommend NOT choosing the "no" option in WMT - choose "yes" when you edit the parameter settings for this and you'll see an option for your case, I think, Christian (I know this is 3 years late, but still).

BUT I have a situation where we use SiteCatalyst to create numerous tracking codes as parameters to a URL.  Since there is not a new page being created, we are following Google's advice to select "no" - apparently will:

"group the duplicate URLs into one cluster and select what we think is the "best" URL to represent the cluster in search results. We then consolidate properties of the URLs in the cluster, such as link popularity, to the representative URL."

What worries me is that a) the "root" URL will not be returned, somehow (perhaps due to freakish amount of inbound linking to one of our parametered URLs), and b) the root URL will not be getting the juice. The reason we got suspicious about this problem in the first place was that Google was returning one of our parametered URLs (PA=45) instead of the "root" URL (PA=58).

This may be an anomaly that will be sorted out now that we changed the parameter setting from "Let Google Decide" to "No, page does not change" i.e. return the "Representative" link, but would love your thoughts - esp on the juice passage.

Tim

[Dr-Pete]

It's really tough to say, but moving away from "Let Google decide" to a more definitive choice seems like a good next step. You know which URL should be canonical, and it's not the parameterized version (if I'm understanding correctly).

If you say "Let Google decide", it seems a bit more like rel=prev/next. Google may allow any page in the set to rank, BUT they won't treat those pages as duplicates, etc. How does this actually impact the PR flow to any given page in that series? We have no idea. They're probably consolidating them on the fly, to some degree. They basically have to be, since the page they choose to rank form the set is query-dependent.

[Jen_Floyd]

Agree...it feels like leaving a bit to chance, but I'll keep an eye on it over the next few weeks to see what comes of it.  We seem to be re-indexed every couple of days, so maybe I can test it out Monday.

BTW, this issue really came up when we were creating a server side 301 redirect for the root URL, and then I got to wondering if we'd need to set up an irule for all parameters. Hopefully not...hopefully Google will figure it out for us.

Thanks Peter.  Tim

[Jen_Floyd]

Update - Google has crawled this correctly and is returning the correct, redirected page.  Meaning, it seems to have understood that we don't want any of the parametered versions indexed ("return representative link") from our original page and all of its campaign-tracked brethren, and is then redirecting from the representative link correctly.

And finally there was peace in the universe...for now.  ;>  Tim