Crawl Diagnostics Error Spike

[Brother22]

It looks like Rodger found his way into your variable URLs!

This could definitely cause a problem if the engine crawlers are seeing this path as well. Have you made any changes to the code on your site or the URL structure lately?

Regardless, you might want to examine in your Webmaster Tools for both Google and Bing.

For Google you will want to check the blocked URL's under the Health menu. This will give you the information on what pages are and are not blocked. If you notice that the Head Match term you are looking to exclude is not listed make sure that you upload the term to the robots.txt file on your site. Other fixes for this include canonicalisation tagging or the implementation of the rel=prev / rel=next tags. There are a few other ways that are more complicated and I recommend avoiding unless absolutely necessary.

But good news everyone! Google has a few ways to go about fixing the indexation.

Bing is a little Different but just as easy. In the Bing Webmaster Tools under the Index tab, there is a tool called URL Nor<a class="cpad Subject message-low-priority-icon marginleft5 bold">malization</a> you can tell the crawlers to exclude a portion of the query string without changing anything on your database. It also automatically finds and suggests <a class="cpad Subject message-low-priority-icon marginleft5 bold">query parameters for normalization as well. This is a recent change for Bing and could account for the sudden jump in warnings.</a>

I hope this helps and you keep being awesome!

[VanadiumInteractive]

Hey Jake;

Thanks for your feedback, i did make some changes to the code (posted in the reply to Jamie).  I'll take a closer look at the webmaster tools to make sure things are OK on that end.

FYI: The "rel=prev / rel=next tags" are implemented

I added code to manage

to pages that are accessed through

• /Blog/?tag=
• /Blog/category/
• /Blog/archive.aspx

As a secondary concern, with Roger now reporting all these issues in SEOMoz, I provide these reports to my clients and thus having 16k errors is not a good PR thing. How do I tell Roger no to crawl these blank pages?

[jenmcardle]

** How do I tell Roger no to crawl these blank pages?**

Any easy solution is to block roger in robots.txt

User-agent: rogerbot

Disallow: [enter pages you do not wish to be crawled]

But a better solution would be to fix the root problem. If your only goal is to provide clean reporting to your client the above will work. If your goal is to ensure your site is crawled correctly by Google/Bing, then Jake's suggestion will work. You can help Google and Bing understand your site by telling them how to handle parameters.

I would prefer to fix the root issue though. Do the pages which are being reported as duplicate content have the "noindex" tag on them? If so, you can report the issue to the moz help desk (help@seomoz.org) so they can investigate the problem.

[Brother22]

Rodger crawls like the Google bot and takes his hints from the robot.txt file. So whatever Rodger is seeing is usually what the other spiders are seeing as well. From time to time I have encountered slight glitches to the SEOmoz crawler as they change and update their algorithm.

When it comes down to it, Google examines a link profile through a microscope akin to the Large Hadron Collider. where as we have to examine it through a magnifying glass from 1935.

The wonderful people here at SEOmoz are always trying to give us a better view, but it is still imperfect. I would say if all else fails and this report continues to show errors in moz then get your reports for your clients directly from webmaster tools.

[VanadiumInteractive]

Thank you again for the input, the goal here is not provide accurate reporting and ensure that the site conforms to the search engines requirements.

Currently the "?page=" parameter is not blocked through .  it sounds like this maybe the issue.

I will update the code to address that and see what kind of results we get with the next update.  I think this is best addressed at the code level, rather then the robots.txt.

Thanks

[Brother22]

Cool glad we could help!

if you want to clean up your code and are posting site wide for them I would recommend the none tag

Accounts for both noindex, nofollow

[VanadiumInteractive]

Hey Jake;

Whats your option of using "nofollow" vs "follow" on the pages i'm blocking from indexing?  Is there a reason to prevent them from following the links on these pages?

[Brother22]

Unless you have some super secret page that is buried somewhere deep down in your site that you can ONLY get to from those pages, it wouldn't make sense to have them follow the links. All that will happen is they land on the next page, scrape it to the noindex tag and move on. They won't index and this just waste your sites bandwidth and slows everything else down. If it's a noindex it should usually be a nofollow unless you are looking to track conversions or some other specific only navigable through those pages.

[VanadiumInteractive]

Makes sense

[VanadiumInteractive]

One last thing;

It seems that I have a game plan for addressing this issue, but as I think about this one thing has me concerned in the way Roger crawled the site.

The site has maybe a total of 100 articles, which would account for ?Page=10, but what I'm seeing is errors on ?Page=104.  When you look at that page its a blank.  Where is Roger coming up with that parameter?

Do you think this is a Roger issue or something else?

[Brother22]

This would be another issue. I would need to look at the code to give you more insight. But off the bat I assume that this is an issue regarding mislabeling the rel=next and rel=prev. They can be kind of tricky to work with on a broad based update due to the fact that they are intended to refer to specific pages. If you do not have the end page labeled Google says :

"When implemented incorrectly, such as omitting an expected rel="prev" or rel="next" designation in the series, we'll continue to index the page(s), and rely on our own heuristics to understand your content."

I would look into this first. If the answer is still elusive to you the next option would probably be finding a different set of eyes on the code to see if there are any minor oversights that you may have overlooked.