Welcome to the Q&A Forum

In Bing ads, you can't pick to target only Bing or only Yahoo, you have to target both at once.  Because of this, knowing how Yahoo performs vs. Bing isn't really actionable.  Someone has set this up in Google Analytics by setting up a separate profile and adding a filter (see here) if you're really interested to see the breakdown.

When you click one of your ads from Yahoo, are you seeing the utm parameters on the resulting URL?  If so, then there shouldn't be a Yahoo-specific problem.  If you're using something like utm_source=Bing on the destination URL, then all of your Bing/Yahoo paid search will be bucketed under Bing in your GA reporting.

My advice is to not nofollow any internal links.  It burns your link juice; it no longer sculpts it.  If you really don't want the page it's going out to indexed, either exclude it in your robots.txt, or even better, stick a meta noindex tag on it.

You should do redirects for these pages if you can.  The probable reason they keep showing up and getting crawled is because people linked to those pages before you redid your site, and Google is continuing to come across those links.  If you 301 redirect them to their new counterparts, people will be getting to the content they're looking for when they click those links, and also the link juice from those links will pass to the new pages, so the new pages should also rank better.

Some people do subdomains (like you've outlined above), and some do directories, i.e. mysite.com/en/, mysite.com/de/, mysite.com/fr/.  It used to be recommended that you do directories, as they keep your domain authority pooled better, since subdomains each have their own concept of domain authority.  That seems to be less true today, so I'd do whatever is easier for you to set up.  All else equal, I'd opt for the directory structure.

It may be that some of your destination URLs aren't tagged with the utm parameters.  I forget if you can do it in Bing, but I know in Adwords you can set destination URLs on keywords or placements as well, which will override ad destination URLs, so you may need to check on all of those and make sure they're all tagged properly.

My instincts say I'd rather exceed the 100 links than trying to get the count down by nofollowing footer links, but I've never had this issue before so I can't say for sure.  Google may follow nofollowed links, so I have a feeling this doesn't really get the link count down in Googlebots eyes.

What you have there is just blocking rootdomain.com/javascript:void(0).  Googlebot can execute and index JavaScript; you should not block it without a good reason.  I'd let it read the JavaScript and see the submenus.

I think it's very unlikely Google would index a test variant.  Although the test variations do use JavaScript to render, I think they also rely on setting cookies to be included in a test.  As bots don't accept cookies, I don't think they can receive test variant pages.

Also, the guys at Optimizely are awesome, if you want you can ask them this question and they'll get back to you ASAP with a response.  We've been a very happy customer of theirs for over a year now, and I've never had any problems with test variants getting indexed.

With their reports, you should be able to figure out what's going on and where all this extra traffic is coming from.  Is the extra traffic from Bing/Yahoo, or from their search partners?  From specific queries?  From specific locations?  Maybe a new advertiser is on the scene for a lot of your queries driving the price up?  It's hard to answer that question without digging into the data.

I read this recently from the SEER blog regarding separating Bing/Yahoo from their search partners, and I'm trying it out.  The performance difference between the two for us is large, so I'm hoping this will help!

The bots won't care about that.  If you have your site on www.company.com, your robots.txt will reside at www.company.com/robots.txt, and its directives will apply to any pages living under www.company.com.  When a bot comes to www.company.com/blog, it'll look for the robots.txt at www.company.com/robots.txt to see if it's allowed to crawl there.  It won't look in a subdirectory. Robots.txt always resides on the root level.

If you had your blog at blog.company.com instead of company.com/blog, then you would have to have a separate robots.txt at blog.company.com/robots.txt.  As you have your blog in a subdirectory rather than a subdomain, one robots.txt is all you need.

The Bing Webmaster Central article where they discuss how to set the language for your pages is here.

Since you're doing redirects already, I'd get rid of the .html.  They're not user friendly, and you're already doing a redirect anyways so why not.  Seeing them on URLs looks old to me, most sites don't have them anymore.

Trailing slashes I don't have a strong opinion on.  If these pages will never have pages after them, then I'd opt for no trailing slash, just because I think most sites do that now.

Our Adwords CPCs are less than our Bing CPCs pretty much across the board.  From what I've read, that's the norm.  So it does sound like something fishy is going on.  If your Bing CPCs are up, it's likely true for your competitors as well, so they're probably also suffering.

The search partners report in Bing is pretty great... sometimes I've seen spikes on specific search partners that have caused a fair amount of wasted spend.  I believe in their interface they call it the "Website URL (publisher)" report.  Thankfully, it's easy to exclude specific partners.  That would be my #1 suspect for wasted spend!

It should help to segment them because CTRs and CPCs are both much lower (at least for us) on search partners as compared to the Bing/Yahoo properties.

Alan is right. Your question reminded me of this relevant WBF. Enjoy! http://www.seomoz.org/blog/title-tags-is-70-characters-the-best-practice-whiteboard-friday

What you outlined sounds to me like it should work.  Disallowing /searchhere? shouldn't disallow the top-level search page at /searchhere, but should disallow all the search result pages with queries after the ?.

Your best bet is to place a meta noindex tag on each secure page.  If it's only a few pages, you could just add it by hand.  If it's many, you should be able to access each pages protocol with whatever server-side language you're using, and dynamically add it on all secure pages.

If you use robots.txt to exclude the pages, Google can still show them in search results, with the description below them that reads, "A description for this result is not available because of this site's robots.txt – learn more."  Personally, I don't care for that.

You can track conversions through both platforms, and still upload conversions from Google Analytics (GA) to Adwords if you want to.  It makes sense to track conversions through both, because I'm sure you have conversions coming from other marketing campaigns and from organic sources that you can't track through Adwords.  Adwords conversion tracking will only track conversions where the user clicked through from an Adwords ad, so you won't get a complete picture.

Unless you view conversions in GA showing all touches, you'll see some differences in conversion tracking between the two platforms, due to differences in attribution.  For example, if someone clicks on an Adwords ad, and then later that day clicks an organic listing to your site and converts, then in Adwords that'll count as a conversion for Adwords, and in GA that'll count as a conversion for the organic listing.

Who is the www version of the site supposed to target?  I'm with blu42media... you most likely should just target the US and the smaller group of international people outside the UK on the www version, and target the UK users with the UK subdomain.

Beyond that... here's what you can do to clue the search engines into what's what in terms of international content:

• Register each subdomain in Google Webmaster Tools, and geotarget it (see here).
• Set meta tags or http headers to let Bing know the language and country (see here).
• For duplicate or near-duplicate pages across different English speaking localities, you can try out the hreflang tags to clue Google in that they're the same page, but geotargeting users in different locations.  I haven't personally implemented this myself, so I can't speak to how well it works, but you can find more info about it here and here.

There will indeed be duplicate content with both solutions, but it's ok.  That guide is a bit outdated; one thing that's come about since then is the rel=alternate markup which is for this exact situation.  Read more about that here.  You'll put markup on your pages that tells Google what the alternate pages are, so Google can return the appropriate pages based on language and region.

EIther way, you'll also set your geographic target for the AU content in Google Webmaster Tools. You can also set your language and regions in Bing on your pages, either with meta tags or in your HTTP headers (Bing instructions).  That's more for if you decide to go with the subdomain solution, as Bingbot will know who your site is for with a .com.au TLD.

If you go with the .com.au site, it'll be starting from scratch and won't inherit any of the domain authority from your .com site.  However, Aussies would likely be more receptive to a .com.au site?

The best thing to do is set up the geotargeting in Webmaster Tools for Google, and for other search engines, set the country and language you're targeting on the HTTP headers or in a meta tag (see here).

Your English version is probably a lot more popular and has a lot more backlinks to it than your regional versions, so it will rank better as compared to your region-specific subdomains.

To make it easier to find the right version, you could make it more clear on your site how to find the different international versions.  For example, if you can't read English, you won't know to click a link that says "international versions".  We got around this on the site I work on by using flags in the UI, since most people are familiar with the concept of each country having a different flag. (see http://au.ixl.com/ for example).