Welcome to the Q&A Forum

I assume this is ASP or .NET. When your page is rendered, it will appear as a normal HTML. Google doesn't hate HTML.

Are you removing the pages or just trying to de-index them? If you're trying to remove them, make sure the old pages return a 404 so they can't be restored to the index. If you're trying to remove them, make sure they are excluded by robots.txt or meta tag.

Here's the WMT Help page on the topic

http://support.google.com/webmasters/bin/answer.py?hl=en&answer=1663427

Tags, in blogging, are a collection of posts by type. They are very useful for sorting content.

In your case, you're describing where they have tagged a given post with, say, 10 tags. But the post itself cannot be accessed via multiple URLs, can it? If the answer is no (and I suspect it is) then duplicate content doesn't come into play because, using your example, the post in question would be something like domain.com/posts/bourne-movie and simply linked in those different categories.

At worst, they are wasting efforts making so many categories (and I probably wouldn't make so many myself) but multiple categories isn't a horrible thing as long as the content pages are unique.

I dunno that I would be as scary as Robert about it. With Facebook, it's perfectly acceptable to link and then attribute the image. This way nobody sees it as your image.

I would not do this on your website but, within social media, it seems to be acceptable.

The larger question is what's inside that element? Google ignores semantics and markup. They want your content and if your content is spammy you'll suffer. But I've never heard of anyone suffering because they named a CSS class "SEO".

Major question:

Obviously they're running a 64 bit OS but what about the browser? For instance, Mat said he tested in Chrome, Firefox and IE. Of those, only IE has an official 64 bit version (and Windows defaults to the 32 bit version by default).

Using Waterfox (unofficial 64 bit build of Firefox) and IE9 64 bit the ads page loads fine. However, there was a 64 bit build of IE 8. Is it possible that could be the issue? My bet is that it's an IE issue and not a 64 bit one.

Good stuff. I was always under the impression they still crawled them (otherwise, how would you know if the block was removed).

Robots.txt prevents indexation, not crawling. The good news is that Googlebot stops crawling 404s.

Here's what I would do for starters

1. Set up a campaign for your site. It will take a few days to run so start it running now
2. Link your campaign to your Google Analytics
3. Go to Open Site Explorer and do a backlink analysis on your site. With penguin looking for unnatural links, it's a good idea to make full use of this tool

You can but the 404s should stop being crawled on their own. There's a webmaster tool that you can use to make that happen faster as well

http://support.google.com/webmasters/bin/answer.py?hl=en&answer=64033

A 404 should cause Google to de-index the content. Go to one of the bad URLs and view the headers to make sure that your webserver is returning a status 404 and not just a 404 "page".

As hard and time consuming as it might be, I would still pursue a 301 option. It's the cleanest way to resolve the issue. Just start nibbling at it and you can make a dent. Doing nothing just lets the problem grow.

The SEOMOZ PRO tools can actually do that for you. They crawl your site looking for duplicate content (and other problems) and then give you a handy report.

Do you have an automated sitemap? On at least one occasion, I've found that to be a culprit.

Noindex means it won't be kept in the index. It doesn't mean it won't be crawled. I'm not sure how it would affect crawl timing , tho. I would assume that Google would assume that you would want things not indexed crawled less frequently. Something to potentially try is to use the GWT Fetch as Googlebot tool to force a new crawl of the page and see if that gets it in the index any faster.

http://googlewebmastercentral.blogspot.com/2011/08/submit-urls-to-google-with-fetch-as.html

Remember that SEOMOZ simply crawls the web, parses that crawl, and then updates its index. If these were recent links, they might not show up yet. Also, according to Rand's blog, the index has shrunk for some technical reasons. They are working on fixing them.

Better still, get your own virtual dedicated server and don't share anything except hardware resources

If you're going to track stuff like that, I would use a URL shortener (like tinyurl.com, goog.gl, etc) that redirected to your site with the appropriate utm_source added. Referrals won't cut it because their browser is probably not going to report it, especially since it wasn't a URL.

I use this most commonly with Bing PPC, since it gives me better numbers over referrals (which savvy users can turn off altogether).

You can read more about custom campaigns here.

What you're talking about would be an IP ban or filter. I've never had anyone prove such a thing exists. At worst, someone hacks a server that is shared hosting dozens of sites and does something to directly attack Google. In that case, I would assume Google would ban the IP from incoming traffic but not from outgoing (like a bot).

Google ranks domains, not IPs. So even if you're shared hosting on the same IP as an adult site, Google won't see your site as related to theirs unless you LINK to them. So your SEO and their SEO are like ships passing in the night, sharing an ocean and nothing else.

Yeah, your options involving DNS are severely limited. Really, you have to have a web server send the proper codes (in your host's case they're using their own). So point them to your server and have it return the 301s you need.

Does your host not offer you something like a .htaccess file or something similar? Do you not have any access to programming languages on the server (.NET, PHP, etc)?

A less-than-optimal way to do this would be to CNAME your domains to the root and then make sure you canonical the pointed domains to the main one.

Except for geolocation purposes, your IP has no real effect on your SEO. The only thing I would suggest is making your TTL on your DNS records very low about a day before you move so when you do move you minimize the chance that you're hitting the old IP.