Welcome to the Q&A Forum

Hi We used Addthis for a while as well, but had the same issue. At times it really slowed our page load. We wound up doing what others have suggested, manually coding in the share links.As for recommended products, we now use an extension which does a great job. Ken

Great answers here by Josh and Alan. I'll touch upon the informational/blog pages and social buttons. Social share buttons can be great on Informational pages, sure to get people to share your content, but a lot of the benefit is for social proof. Pat Flynn has a great episode about social proof here. Check it out. Keep in mind social share numbers can work against you if they are low. Also, I'd add social buttons only for the networks your target audience is most likely to be using. I recently started checking out the SumoMe suite of tools. I was pretty impressed on first glance - I think there's a lot you can do with heat maps, content analytics and analytics integration which help you measure the results of each piece of informational content.

I'd maybe run some A/B tests with and without the plugin on your store, and see what happens to your conversions, including everything you'd want to track- sales, social shares, and any other important metrics. You could use something like Optimizely for this I believe, though I've not used it for testing plugins before. I'm a big fan of putting usability at the forefront of all of my marketing efforts, so I'd maybe consider finding out from some of your other customers their opinions, too. Is the share button on all of your website, certain pages, or just your checkout page? Is there a way to make it less intrusive, or easier to close/get away from, for customers who struggle? Have you conducted thorough browser testing to ensure the plugin isn't causing extra issues for those using certain browsers? I've had issues in certain browsers with other similar plugins before so it might be worth checking. Hope this helps, good luck!  Zoe

Yeah, echoing Dmitrii, Google does this quite a lot these days, and a rewrite to include the brand is very common. It's especially common if they consider part of the title to be low value or low relevance, and I'm afraid Google would probably consider "Buy Online Australia" to be low value in most cases. At this point, there's almost nothing you can do about it, other than adjust the title to be more relevant to common searches. If you start hacking away at you G+ business listings, you're just going to harm your brand signals. It's not worth it for a couple of title tag rewrites.

Thanks - I'll give it a try!

You can test this in keyword planner by simply searching for "Nike Shoes" and "Shoes by Nike". In this case, the first is searched 368,000 times monthly, the latter is searched 40.

Google considers this to be spam. Sometimes pages get away with doing this, but generally you're going to eventually get a manual action reported in Search Console.

Thanks.  Realistically the Currency specific pages are purely for google shopping to verify the right price corresponds with their experience - so I didn't really need to have offers in the page. My workaround was to remove the offers in multi currencies for regular page and only show the offers when a currency was selected.  Snippets ( stars ) have returned Kind Regards Martin

Hi Marty, I don't think this will hurt your SEO, but I'd think of this more in terms of user experience and your goals for the website. For instance, if the site is primarily an ecommerce site, perhaps driving traffic from the money pages to the blog is not advisable.  On the other hand, if brand awareness and the blog are a big part of your overall strategy, then maybe driving traffic to recent posts makes more sense. For user experience, recent posts may not be relevant to all pages like you mentioned, so you have to make a judgement call regarding how many pages they will provide value and how valuable they will be on those pages vs how much value they take away on other pages where they aren't as relevant. Make sense?  Feel free to message me with any other questions Mark

wonderful thanks.

As I understand it, you are asking about rendering the same content to two different domains that differ entirely in the tld (.au & .nz). Based on my reading of Google webmaster guidelines, if the only difference is the domain and what country the visitors are from, you should not have any issues so long as you use rel-alternate-hreflang as you described. If you have multiple domains targeting the same users, just be sure to add a rel="canonical" tag. Google's webmaster guidelines state: "Websites that provide content for different regions and in different languages sometimes create content that is the same or similar but available on different URLs. This is generally not a problem as long as the content is for different users in different countries. While we strongly recommend that you provide unique content for each different group of users, we understand that this might not always be possible. There is generally no need to "hide" the duplicates by disallowing crawling in a robots.txt file or by using a "noindex" robots meta tag. However, if you're providing the same content to the same users on different URLs (for instance, if both example.de/ and example.com/de/ show German language content for users in Germany), you should pick a preferred version and redirect (or use the rel=canonical link element) appropriately. In addition, you should follow the guidelines on rel-alternate-hreflang to make sure that the correct language or regional URL is served to searchers." source: https://support.google.com/webmasters/answer/182192?hl=en#3

Thank you for confirming my thoughts. In the meantime, that's exactly what we've implemented anyway It didn't seem logical to me either - nice to have a sounding board over here.

Personally i prefer to go for the longer url because of the breadcrumbs and the easier url navigation structure. A lot of people delete part of the url to get back to a previous step in the website architecture. Your 1st way allows that to be done fairly easily and the url explains exactly where someone is on the site. When someone sees your url in the SERP's this would also indicate that they are finding a product in the proper category. The problem with this is that if the webshop has a product in several categories. I build a female clothing webshop a while back and they had categories for top-wear, bottom-wear, specific clothing articles(blouses, jeans, shoes etc) and for each brand. This meant that a product would be in at least 3 different categories within the site. For this reason i chose to set the canonical to: http://www.domain.com/product/ in this particular case. If your webshop does not have this problem and will not get this problem in the future i would recommend the longer url's.

Thanks @Chris, Sounds totally agreed, one has to know first all about their products/services, employees, audience, market, prices, and competition etc.

I agree with everyone above. I use tags for internal search which it is fantastic for, but I don't use it for SEO purposes

Passing page juice to sources is a good idea in most cases. Moreover, if you are linking to websites with good quality and unique content, you must pass the page juice for sure.

Webmaster Tools isn't telling you that it thinks your website is about Dollars, its telling you that it sees that mentioned often on your site.  You really don't need to fix anything, but perhaps adding more content about your target keyword will help push that down a bit.  Are you saying something costs "88 Dollars" all over your website or actually using a $? If its the latter, that would be very interesting.  If its the former, remove dollar and use $ instead.  Cheers!

Mmm... tricky question, as I usually don't like to have the currency changing depending on IP. Therefore, I don't if my idea is correct and surely should need to be tested. As you probably know, the Schema.org/Offer preview the mark up for currencies. What I'd probably do should be calling the product description, photo, prices and currencies with a PHP call (if your site is on php), and the code snippet called would be mark-up with the Schema.org corresponding to the "country".