Welcome to the Q&A Forum

Blog Engine is just a dotnet framework. Use dotnet url rewriting to redirect properly, you just have to edit web.config to have iis redirect urls with trailing slashes to urls withiut trailing slash.

To avoid any risk of being penalized you need to be very careful to do not cloak. For example, in my experience if you tweak content serving different version of the page to javascript enabled browser and browser without JS is fine. But if you change something when you detect the http request is coming from googlebot, even if you change just a title, google gets very very angry.

Link building is not affected, do not encourage people to link using hashbang.

I don't remember about canonical, I don't think so, but just check the google docs I linked earlier.

But, as I said earlier, I strongly suggest to do not use hashbang, and redesign the app to use ajax the way I described earlier.

Google official blog think otherwise:

http://googlewebmastercentral.blogspot.de/2010/04/to-slash-or-not-to-slash.html

Also my direct experience tell changing the image name greatly improve image ranking in serp.

You can iframe those chunks of content and block with robots.txt or just meta tagging noindex in the iframe source.

But I would not, if you can't build a plan to make the content unique just canonicalize, or let google choose which page to pick among the duplicate bunch.

That was also my concern but all the four websites are related to the same branch of business I would say.

It's a software house basically, site 1 is just about them as a company. Site 2 and site 3 are about old technologies they do not resell/implement anymore. Site 4 is an online webservice to exchange messages anonymously, they actually never launched it. It's the one more distant from what they are doing and I agree with them it really looks unfinished and not so professional.

I would expect product pages to have AggregateRating markup for that specific product. Not for the organization. Google is not going to show that rating anyway, so why put it there?

Keep in mind, you want star rating to appear in SERP because will improve CTR.

To have star rating appear in SERP you need markup and a user query matching the target of the rating.

Let's assume you sell vegetables and your organization name is "Veggie Inc".

Would you expect the product page for "Early Girl Tomato" to show up in SERP when people search for "Veggie Inc."? Unlikely. So if you add organization aggregate rating markup on that page no one will see that.

Do you think the star rating will appear on "Early Girl Tomato" page for other queries? No way.

Best practice is Organization AggregateRating on 1 page, usually the homepage, which people will likely search for using your brand as query, a query which will match your Organization name...

Hope I was clear.

Pages and posts are all content, I never heard of google crawler/algo to make distinction. And I don't think the fact of having a date is a making a page a post. I believe a discussion about posts and pages nature would be like a discussion about the sex of angels.

Depending on the user search query google notoriously give a boost to fresh content in SERP, but that depends on the search query. If you search about soccer results on sunday night, google guess you are interested in the actual results of the day and gives a boost to fresh content. But that's it. As far as I know if you search for plumbing in Chicago it's unlikely fresh content get a boost.

I thought this one was carved into stone, max number of results from the same domain in SERP is... two. Or... three?!

I was searching for some familiar keywords and found three results from the same domain, isn't that... unusual?

Check my answer to a similar question: http://moz.com/community/q/angular-seo

I am a big advocate of Angularjs, it's a great framework and I use it in every project. I always put SEO on top of my priority list when starting a new project and I never use hashbangs.

In my opinion hashbangs are fundamentally wrong, an old hack born when pushstate was not available.

The only case where Hashbangs make sense is for old complex application/javascript website developed without thinking about SEO, when you evaluate to modernize the app is too complex and not worth it.

You can happily use angularjs and benefit from its routing api without messing around with hashbangs.

Thanks for the long answer EGOL.

What I intentionally didn't mention in my question (because I was curious to learn if the fact by itself was revealing of anything special going on) is that those results are from one of my sites, the one with the lowest PR/DA/mT, where I write freely, without a schedule and not caring much about keywords, density, and all the usual suspects.

It is about a niche subject, and I think you are totally right.

What keywords are driving traffic to each page?

If semantically they share the same traffic, and if after merging the content and skimming the fat you don't loose too much, I would merge them and 301 one url into the other.

If each page is having traffic from different keywords you have the option of just do nothing and leave them the way they are.

Imagine being a visitors of those pages. Would they better serve your need for information split or merged?

For which keywords are you seeing a fluctuation?

Anyway fluctuations are normal. Particularly during or after a spike in link acquisition, which you are undergoing according to both ahref and majestic.

And let's assume you are referring to keywords like "virginia beach va", it's a rather generic keyword, and even if competition doesn't seems high, in my experience it's hard to get a stable ranking for generic keywords.

If I was you I would check keywords using semrush.com but seems you did a nice job already analyzing them.

I actually agree with what Monica said, theoretically is better to have two pages on serp for CTR.

But if I look at serp for those keywords and I open the two pages I feel a bad taste in my mouth, I have the feeling I have been cheated because the meta title before to click and the content after the click seems too similar (I didn't read through all the content I confess), but I may be biased since I know what you are trying to do, a regular visitor my feel different.

Nevertheless I think the theoretical benefit of having two pages in serp could be balanced by the ranking benefit of merging the two pages; iif a big jump was possible (http://moz.com/ugc/click-through-rates-in-google-serps-for-different-types-of-queries). Which seems highly unlikely, but you can test it.

To merge or not to merge?

I changed my mind, I would not merge. I would start to slightly change one of the pages, both meta-title and content, to remove that bad taste in my. And monitor ranking variation after each change.

Given you are after page juice only, as far as I know after the third link from a certain domain, no matter it's DA, the incremental page juice transferred is negligible. Only exception in my experience is when 1) the additional links are deep-links, 2) content targeting heterogeneous keywords and 3) you work on to get exceptional PA for that linking page.

In addition to what Robert just said. If you add a 301 now to format url properly, and later add a second 301 to move to HTTPS, you will add redirect to redirect losing that little bit of page juice twice.

Open this url on any browser:

http://webcache.googleusercontent.com/search?q=cache:http://www.site-you-want-to-check.com/page-you-want-to-check.html

You can reasonably take that as the date when the page was last indexed.

You could also programmatically store the last google bot visit per page, just checking user-agent of page request. Or just analyze your web server logs to get that info out on a per page basis. And add a couple of days just to have a buffer (even google need a little processing time to generate its index).

"cache:" is the most update version in google index

if you fix the duplicate content next re-indexing will fix the duplicate content issue

Ryan, I don't agree. It's true external factors (in other words backlinks) nowadays have the biggest impact, but on-page optimization as far as my little experience tell, still does affect ranking and it's worth working on.

And if we don't keep track of changes on pages and change on ranking how can we know what is working and what is not?

Especially since there's no gold rule and what works for one site doesn't necessarily work for another.

To make some example, I had a page which was ranking in position 1 for a search query with a volume of 50+k and very high competition. I expanded content to improve ranking for some additional queries, and it worked, it climbed from 2nd and 3rd serp page to 1st for a couple of those queries (I use both Moz ranktracker, semrush, and proracktracker to monitor ranking).

Unfortunately ranking for the search query with the highest volume moved from position 1 to postion 2, I changed the content a little bit, to add some keyword, which made sense because was re-balancing the keyword density now that the content was bigger. And in 24 hours it got back to position 1, without damaging the other search query improvement.

**In many other cases, I improved ranking on pages without any backlink, just improving the content, and I am talking about business critical pages with a high competition.

So I would say on-page optimization is still worth spending time on, to test the effect of the changes is a must and to monitor google ranking fluctuation is a must too.

Of course I am not saying off-page optimization is not important, is fundamental, I am giving that for granted.**

Let me say straight forward, all that bot blocking is not a good idea.

I have been there in the past few times, especially for e-commerce, scraping to compare prices is very common, and I tried blocking scrapers many times, maybe I am not that good, but at the end I gave up because the only thing I was able to do was annoy legitimate users, and legitimate bots.

I do scrape other website too for price comparison, tens of websites, since I don't want to be blocked I split the requests among different tasks, I add a random delay between each request, I fake header data like user agent pretending to be Firefox from a windows pc, and I cycle through different proxies to continuously change IP address.

So as you can see, it's much harder to block scrapers than it seems.

Neither I would use JS to block cut&paste. I have no data to base my judgement on. But it's annoying for users, it doesn't sound compliant with accessibility, it stinks and google usually doesn't like things which stinks. Plus... If someone wants to scrape your content you are not going to block him that way.