Welcome to the Q&A Forum

I'm using the Raven Tools app for iPad... although admittedly, you can get an almost identical experience by visiting the website in Safari.

The effect will be minimal and other factors will outrank these subtle variations by far. I recommend that you do what makes sense for yourself and your users. Go easy on bolding terms on the page, excessive amounts are not a good thing.

Have you checked the backlinks? The only logical reason I can think of for the index.php versions of the URL to outperform the friendly versions is more sites have linked to them. I would make every effort to convince the client to use friendly URLs. Users clearly prefer them and technologies change. Even if they are using .php today, in a couple years it may be a dead technology and they will have to redirect their entire site. It's not a logical business move. With the above noted, if you wish to perform the redirect of all pages except the home page to the index.php form of the URL, it is doable with the proper regex expression. The issues I foresee have already been shared: URLs are harder to read by users and are therefore less friendly URLs are longer so therefore more difficult to share naturally in tweets (for example) without a URL shortening service URLs include "php" so when the site's technology changes the URLs will need to be redirected Users may experience confusion related to the inconsistent URL formats of the home page and the rest of the site Long URLs are cut off. You mentioned using other languages. If a page's title involves foreign characters, those characters are converted in the URL to ?unicode. It is where you see characters like "%20" replace a single character. With foreign URLs the length can often exceed maximums which is an issue. Keeping index.php is an extra 9 characters added to every URL. This decision approaches the SEO equivalent of a patient going against their doctor's advice. If it was my client, I would want a very firm acknowledgment this decision was against my advice and industry best practices.

We program our cart in house and we need the SKU numbers to be passed. I looked at a lot of ecommerce sites and they all have their skus somehow int he URL in one way or another.

Hi Joe Thanks for your advice, however, if you look at the websites, gansbaai.com it is really bad, only has 1 page, I really only bought it for the domian age and couple of links it has (and because I want to launch my new sit under this domain)....so there are not enough pages to 301 all danger-point, and I want to loose as little link juice as possible....Any feedback would be greatly appreciated. Thanks

This is actually a best practice IMO. If that page for whatever reason is duplicated somewhere else (could happen a year down the line) then you automatically eliminate the issue of dupe content and are already providing a directive to Google on which page is the original and which page to count.

The tag should work fine with the partial URL. If you are still concerned about the warning, try adding the base href tag within the of your page. It would be as follows: <base href="http://www.aircycle.com/"> This tag explicitly specifies the base URL to which all partial URLs are built upon for a given page. Try adding this tag to just the one page, then running the report again to see if that resolves the issue. If it does, then you know what change the tool is requesting. To be clear, the canonical tag you are using should be fine for search engines assuming there is no other issue. This may be a specific issue with the tool. Since testing the base href tag, and the full URL are relatively quick and easy to do, my suggestion is to spend 10 minutes performing these tests to see the results. If the tests work, then you can contact the SEOmoz help desk and report your findings as an issue with the tool. It could be a bug or limitation with the tool.

Lots of great feedback has been offered. In short, it's up to your personal preference. I can't help but add a link because I have watched too many Matt Cutts videos (they are starting to auto-play in my head) and he answered your exact question. http://www.youtube.com/watch?v=971qGsTPs8M

Yes Trellian keyword discovery, it's not free but it's good. http://www.keyworddiscovery.com/engines.html Keyword Discovery collects search term data from over 200 search engines world wide. As a result we have the largest keyword database that contains nearly 38 billion searches. KeywordDiscovery also offers many language specific keyword databases sourced from regional search engines and users from those regions, including: Australian, Canadian, Dutch, French, German, Italian, Norwegian, Polish, Portuguese, Spanish, Swedish, UK and US with plans to offer many others.

Bots can burn through script... I don't think an extra line is  really a speed bump. .. but yes... always fun to test things.

Michael, I would be interested to understand this question in a different way.  While you may optimise a page for say one or two keywords from an SEO point of view, how might that vary (if at all) for an SEM campaign.  In many cases the same page (especially a product page) will be used for SEO and SEM so I would be interested to extend your question and say in addition how many keywords should you optimise for an SEM campaign and then for a combined SEM and SEO campaign as well as just the SEO campaign?  Is there any real difference?

Hey tommo, you are correct- and I understand your concern. For rank tracking.... Yes, it is 'technically' against Google's guidelines to scrape for rankings, however- Google is very aware of SEOmoz, and has never publicly stated anything against them. (They did ask SEOmoz to stop reporting pagerank a few years back though.) Although this is anecdotal and doesn't prove an endorsement.... at a lot of conferences, and on some whiteboard Fridays, Matt Cutts has been in touch with the Moz team. This puts me at some ease about Google penalizing all Moz users. After-all, this is an entirely white hat community As for everything else besides 'rank tracking'... seomoz uses linkscape, their proprietary crawler and index of the web. This means, whether you are signed up or not, they may still crawl your site (and probably will), because that's how OSE gets data to return in open site explorer. One final point to keep in mind... SEOmoz uses several data centers around the US, so using their rank tracking would lead back to them, not you. Anyone could just as easily track your rankings as you could, so how would Google know to penalize you? They really couldn't because otherwise, all you'd have to do is setup a campaign for your competitors and watch their rankings fall. If you're super concerned, you could use everything in the web app besides rank tracking, and you'd have absolutely nothing to worry about (and the price would still be worth it- in my opinion). Does this help? [edit] Please Note, I am completely white hat, and if I had once ounce of suspicion that search engines frowned on the rank tracker in the web app, I'd stop using the rank tracker. And that's a decision everyone needs to make for themselves. Above all else, I study the hell out of webmaster guidelines and try to follow every rule and piece of advice that I can.

Make sure you redirect the existing pages to new URLs using 301 permanent redirects. This would help retain the value of page to some extent and the existing visitors as well. Defining everything in a .htaccess file would be the best option, and can also use a code in a PHP file to further manipulate the redirects.

My understanding is the C-block bar has nothing to do with social factors, but instead is being used as a control measurement. Prior to social sites becoming so popular and other algorithm changes, the strongest off-site correlation for Google ranking factors was the number of linking C-blocks to a website. The graph is being used to demonstrate how Facebook shares and other social metrics are so incredibly strong they overshadow the number of linking C blocks metric. That is how I interpreted the graph. If anyone else read it differently I would welcome the feedback.

Thanks, Heather. Getting a clearer picture now.