Welcome to the Q&A Forum

Be sure to check in Webmaster Tools to make sure you don't have a manual penalty.  I was doing a test on a temporary site to try and spot when Penguin did a data update, and I just copied text from other places to make "filler" content, and I got a manual penalty in just a couple of days because of that :-).  So it doesn't have to be links that get you in trouble.

The new Search Analytics is really a major step forwards, in my opinion.  But it doesn't seem to have been tested very thoroughly.  For instance, on any screen that shows total clicks, if you click the Download button and export that page to Excel, then add the clicks column in Excel, it's off by about 30%.

So you may be looking at the effect of one of a number of basic bugs here.

Comment out both.  The Rewrite Cond is the test condition that if satisfied, causes the rewriterule on the following line to be executed.

There isn't really any limit, like there is for page titles, meta descriptions, etc.  Typically you'll want the ALT text to explain what's in the image--the original purpose was to show the user what the image was before it was downloaded, and also for vision impaired folks, the screen readers would read to them what was in the image by reading the ALT text.

If you're looking for the image to reinforce the relevance of the page for the page's target topic, then make sure that the topic term is in the ALT text, usually as part of a long phrase or sentence.  If you're looking for the image to rank well in Google image search, then I'd keep the ALT text to just what the target term is (and of course make sure the page title reflects that term as well).

So you've got a big performance issue if you put all 20 images in img src= notation, as the browser is going to try to download those, of course.

What I've done with my travel website with big hotel images (I'll have as many as 75 or more sometimes) is specify the 1st image in img src= notation, then use Javascript to update the src attribute on click or timer.

The downside of this: good luck getting Google to index the other 19 images, even if you put them in an image sitemap.  In my experience, Google didn't want to index anything it couldn't verify was really on the page.

You can use @media queries to point at different images for different resolutions, but only if they're background images....which most likely means they won't be indexed, and they won't be seen as content by Panda.

What I've ended up doing is a bit of a hack; I use client-side Javascript to detect the screen resolution, then I can select different sized images based on that.  I use Joe Lencioni's SLIR library to take any large image and automatically create and cache the various smaller sizes I need.

I would definitely update that sitemap.  If your sitemap is telling Google one thing, and the pages themselves are contradicting the sitemap, AND it's happening thousands of times--that's a negative quality signal to Google, and could affect all sorts of things, from crawl budget to indexation to rankings.

ALT tags are worth fixing as well.  That's really the #1 clue Google has to what the images are about.  (Other clues:  the image filename, and the page title, if it's the main image on the page).  Here, I'm presuming that the images are ones you hope to have show up in image search results (otherwise why would you bother creating an image sitemap?)...in which case, you really, REALLY need to put the ALT text on them.

I've not seen instances where Google would index an image that's on a page that's marked noindex.

Be sure that you have consistency between your sitemap and your noindex/index tags on the pages, i.e. don't include a page or image in your sitemap where the page itself (or containing page) indicates noindex.

If you look at how Webmaster Tools OOPS I guess I mean "Search Console" (will Google EVER let a product keep the same name forever???) shows indexation of images in a image sitemap, you'll notice they pair the image indexation count with the web page indexation count.  I take that as an indication that they're not interested in indexing images on noindexed pages (which I have to say makes sense to me).

Correct.

Captcha is one of the most hated web technologies out there.  Personally, I'm a fan of the simplistic solutions that just involve a checkbox.  See Mike Blumenthal's blog for an example (look for "confirm you are not a spammer").

Be sure you follow the best practices outlined here for separate mobile sites.  In short, you want the desktop pages to have a rel alternate tag pointing at the mobile equivalent, and the mobile pages having their rel canonical pointing at the desktop equivalents.

In general, you should expect Google to look at your desktop pages when it's calculating PageRank, link juice flow, etc., NOT your mobile menu.  So if there are links to your category pages in ONLY your mobile menu and not your desktop, then your category pages won't rank as well as they should.

So if you're talking about www.mysite.com/blog vs. www.mysite.com/blog/ I think I wouldn't worry about it too much.  I'd definitely see if you could set a rel=canonical on that page to point to one or the other though.

But honestly, your blog homepage isn't generally going to be a search target anyway....it's the blog posts themselves (and possibly the category archives or tag archives) that will be search targets.  Plus your site's homepage, of course, and other non-blog pages.

Well, it's not going to pass link juice to www.domainlinked.com, that's for sure.  And I bet you're right about the tracking.

Hi Dev,

It's really going to depend on how much of the content is duplicated.  From what I've seen, Google isn't very good at chunking pages up YET.  They're good at spotting entire pages duplicated (e.g. press releases or articles syndicated across multiple sites), and pages on your site that have the majority of the content the same.  But I don't think you're going to run into trouble with a page that has a number of sections, each of which is an entire page on its own.

Where you MIGHT run into trouble is with Panda and thin content.  If the content you have for each of the manufacturers is very light, i.e. just a few sentences and an image or two, then those pages might be seen as thin content.  While I don't think you have to hit the magic 2000 word mark on every page to avoid being seen as thin content, you certainly are going to want more than 100 words.  And, if those manufacturer pages are important search targets for competitive terms--well, then, you probably WILL want those pages to contain somewhere near 2000 words each.

In THAT case, you'll probably want to change the content on the all-manufacturers page, and instead just put a short excerpt for each manufacturer there, along with some sort of "learn more" link to the single manufacturer page.

I'm pretty sure that Moz Local only supports US locations at this time.

Really, I think people have gotten themselves all twisted up unnecessarily over dynamic URLs and hiding the fact that they're dynamic.

If you're dealing with a URL that really is dynamic, I'd stick with the ? & = notation that's pretty standard for this sort of thing.  In my experience, Google is seeing ANY of those characters as word separators, and I'm not really seeing any downside in terms of ranking for terms when using those terms as traditional parameters, e.g.

www.homes.com/listings/ca/san-francisco/?q=single-family-home&b=3-bedrooms&t=2-bathrooms&u=swimming-pool-garden-wood-exterior

I'd be careful with using a "+" sign if you go that route, as various conversions from text to URL-safe to HTML-encoded etc. will replace spaces with + signs...and if something is un-encoding that, you might end up with spaces there.

FYI where this all came from was URLs like this:

www.homes.com/showproperty.asp?pid=115235423ion=ABX&type=723

In THAT case, those numeric parameters (which tend to be database record identifiers) are NOT of use to Google in terms of relevance or ranking.  But the english parameters in my example further up ARE useful, as they may match some of the query terms.

Make the old m dot URLs 301 redirect to the responsive version (the new pages).  That'll take care of users landing on the m dot pages until Google removes those from the index, and will transfer over any link juice the m dot pages have gathered up (although that should have already happened from rel=canonicals on your m dot pages pointing at the desktop versions...but, if you missed any...).

While it might be questionable, throwing away a well-aged domain, it sure sounds like it's causing you some other issues, including bounce rate issues for people who find you simply because of partial domain name match against their queries.

I'd be inclined to take the hit on domain age and move to the new site.  301 redirect the old site's pages to corresponding pages on the new site.  You can set up your old email address to forward to your new one, so people using the old will still get to you fine.  I wouldn't use the old email address on the new site, as you'll get people ignoring your emails because it's not from a site they recognize.

Typically Google is expecting you to use rel=alternate to tell them about (a) mobile vs. desktop versions, or (b) different language versions.  If it's neither a device difference, nor a language difference, then really all you should be doing is using rel=canonical from the less important/less original version to the more important/more original version.

No, keep doing it the way you're doing it.  That's perfectly good link juice flowing between those pages.

Breadcrumbs are a nice way to communicate the hierarchy to Google--not because they're breadcrumbs, but simply because of their nature: all pages at each level contribute link juice back up to each of its ancestor pages.  A child page has the least internal links; its parent has more; its grandparent even more; etc.