Putting keywords in the GMB business name has a very high risk associated with it. It's against Google Terms of Service and they say they will suspend any account they catch doing it.

But as you note, many businesses are doing it and getting away with, at least for some period of time.

So the question becomes "how much risk is the client willing to accept"? Because if they get caught, their account gets wiped out and they lose all the work they've done to build up ranking, reviews, images etc for their GMB page.

I tend to agree with Miriam Ellis who just wrote about exactly this on Monday in her post. Build a good-quality GMB page within Google's guidelines to ensure long-term survival, including optimising for the "housecall" terms in description, reviews, etc. Then spend a bit of time reporting the offending pages as spam

Hope that helps?

Paul

Love the whole "like spending money on jewelery" analogy! Especially the part about not spending on it when your roof's leakin' or your fridge is empty. So gonna steal that

Paul

You've asked a great question, Wagada. The fact that the version of the content on Constant Contact's page has already been indexed does mean that you'll have a duplicate content challenge, but there are ways to address it.

The whole problem with duplicate content is not that it generates some kind of penalty, (it doesn't) it's just that search engines then have to decide which of the dupe pages they should point to in the search results.

The version you publish on your own site already has several things going for it, and you need to add additional signals to help the search engines prioritise your site's version. First, at least part of the rest of your site is probably already talking about the same topics, so there will be more relevance there than from the random topics on Constant Contact. Plus, if your newsletter is like most, it will be linking back to your site, giving the SEs another signal.

The biggest thing you can do to get your site's page considered as the canonical (primary) version is to get at least a few links pointing to it. Social media links can be very useful for this, especially from Google Plus, but a solid link or two from other sites will go a long way as well. Also, make sure your page does NOT link to the CC page - that way there's a clear authority signal that only travels one way.

For future reference, if you're going to publish newsletter content on your own site, there are a couple of steps to take in preparation.

• Publish the content on your own site a day or a couple of days in advance
• Use the Fetch and Render tool in GSC to help it get crawled and indexed before sending the newsletter (SEs take "first published" date into account when trying to ascertain which page to return in results.)
• Make sure it's strongly-linked internally - maybe even put a link to the newsletter content page on your homepage before sending the newsletter
• Get a few incoming links to the newly-published page before the newsletter goes out.
• Use the newly published page's address in the newsletter's preheader text link where it says "If not showing up well in your email, you can read this in your browser" so the dupe page actually links back to the page you want to be considered primary.
• Or best yet, do the above and also turn off the newsletter archive on Constant Contact altogether and make the prepublished page on your site the only version. This is the best, but obviously takes a bit more work and preparation to pre-publish. It also offers the massive benefit of delivering those newsletter viewers who do want to read in a browser to your own pages where you can induce further activity/conversions. Though it should be said that in the newsletters I've managed, very few people click the "view in browser" links anymore anyway.

Hope all that makes sense?

Paul

As someone who helps a lot of clients with Social Media, Peter, I'm going to agree with you wholeheartedly.

Specifically as relates to a SM feed widget, they can be a disaster! Their coding and external API calls can slow down page rendering horrifically, they create significant clutter, and as you point out, they server to pull hard-won visitors away from your site where you had a chance to convert them. (And that's assuming you have consistently valuable feed content in the first place.)

The one time I've found them effective is if they are placed on specific pages the sole purpose of which is generating SM engagement i.e. NOT in the sidebar of every page.

Social media engagement can definitely be used to help build a reputation or to drive more effective customer service. But far too many folks are just "doing it because they can" without actually building a strategic plan for how the work will benefit them, and measuring and adjusting to know whether it's actually working.

Paul

Just to be clear - when you say both sites are identical, do you mean that there is actually just one site that will have both the .com and .ca pointing to it?

If so, and as long as you correctly use a 301 redirect to point your .ca to the .com, you won't have any problem with duplicate content.

That's exactly the sort of issue 301 redirects are specifically designed to solve.

Just a tip for useability...

As a Canadian, when I get redirected to a US .com site, I'm often left to wonder whether the US company can actually serve me well in Canada.

You might want to consider pointing the .ca domain to a landing page on the .com site that functions as a "Canadian home page" and includes explanations to potential CDN customers about all the great ways you can take care of them.

• assurance that you ship inexpensively and efficiently to Canada
• whether pricing is listed in US or CDN dollars
• how service is provided to Canadian users if needed
• that your product meets Canadian safety standards, licensing etc if applicable

The landing page can graphically mimic the regular home page, but with enough Canadian-market-specific content to keep it from being a dupe of the regular home page.

Paul

NameCheap.com is another that will definitely let you 301-redirect one domain to another in the DNS admin (ie no hosting needed)

If you need multiple levels of redirecting, you could just set up the old site as an additional site on the server account that's hosting the new site, and install the htaccess file at its root, with no actual site installed. Then use the old domain's DNS to point to the new location containing the htaccess.

Paul

You're ruining your site's usability for no reason, unfortunately. Google doesn't care about the bounce rate on your site as ranking factor in the example you have given (specifically because it is so trivial to manipulate as you are doing, for one reason). For many users, encountering this kind of behaviour on a site would be a major security.spam signal.

If you want to better understand your visitor behaviour on single-page visits, you'd be far better off to implement event tracking on your external links. You could even set the event to "interactive" so it would no longer register as a bounce visit if that's useful to your Analytics plan, but again, just manipulating the bounce rate does absolutely nothing for ranking purposes.

Hope that helps?

Paul

The primary purpose of alt text (alternative text) is for usability. It is designed to provide an alternative description of the photo for users who either can't or choose not to view images - blind users using screen readers for example.

If you do it right, you'll also get a little SEO benefit as well. Like all good SEO - do what is best for your reader and you'll get rewarded by the search engines as well.

Specifically, alt text should be a natural language description of the photo. Keep it to one sentence long, and my preference is to keep it under 10 words - usually 5 or 6. Since the photo should be relevant to the page, describing it will naturally include the page's keywords. If possible, try to get the keywords towards the beginning of the description, but don't make it unnatural in order to do this, as the benefit just isn't that great.

DO NOT artificially stuff unrelated keywords into the photo's description. That'll defeat the whole purpose, and the search engines will recognize it and ignore it.

Title text is a little different - it's designed to be the text that shows up in the tooltip as you hover over an image. The reason it gets confusing is good old Microsoft. In IE, if an image has alt text but no title text, the hover text will show the alt text. In other browsers, if there's no title text, there will be no hover text.

So best practice is to include both alt and title. NOTE! Title text is pretty well considered NOT to contribute to SEO. It can be used to describe the photo (you can just duplicate the alt text) but more importantly it can be used to create a call to action or instructions that will show when the photo is hovered over.

So... using your example of the backpack photo:
alt text: Lightweight blue backpack perfect for traveling.
title text: Click for more lightweight backpack ideas for travelers

Or for the second example...
alt text: Miniature TV fits in a backpack
title text: See more miniature backpacking TVs

There's no reason not to mention the second item in the photo, assuming it's related to the content of the page.

Don't use generic file names for your images! Before you upload them, give them a sensible file name that includes their keyword. So instead of uploading _DSC459083748.jpg, rename the file to lightweight-blue-backpack.jpg. Sensible means a couple of words long max, and separate words with a dash - not spaces or underscores. (This goes for any file you upload to the web.) Again, search engines assume the file name likely relates to the file contents, so that's another slight ranking signal.

To get the greatest benefit out of your posted images, it's also a good idea to include a caption for the photo that includes a slightly more thorough description of the photo as well. This can be in actual caption code, or just text entered right under or beside the image. Search engines assume text close to the image is about the image (since they can't understand the content of the image on their own).

There's a whole separate area of SEO dedicated to getting images to rank specifically in photo searches, but the above will serve you well to optimize them to help your page rank for your chosen keywords.

Paul

Sorry, missed your question about having 10 backpack images on one page...

In that case, you'll want alt text that describes each in a way that clearly differentiates it from the others on the page. You can also use the opportunity to work in some synonyms and closely related terms to help introduce some variety to your keyword use. (Too much use of the same keyword even in alt text is still seen by SEs as keyword stuffing.)

So...
Lightweight blue backpack ideal for traveling.
Expedition pack for mountain climbing.
Knapsack for women hikers.
Comfortable computer daypack for students.
etc....

Make sense?

P.

My take on it is that it's good old keyword stuffing and dodgy at best.

The content is of absolutely no use to a human reader - there's no reason for them to care what other search terms led visitors to that page. And since it clearly looks like those phrases don't actually link to other articles (correct me if I'm wrong) they can't be considered "related content".

So a spammy tactic for SE manipulation only. If the site owner knows the page is targeted at those terms, he should be using them properly within the content instead of stuffing them at the end.

This is the kind of stuff Panda's been finding and killing for the past year or so. I sure wouldn't want to bet my rankings on it - and look like a douche to my readers in the process.

Paul

As all 3 of us have said here, Pioneer, there is no issue with setting things up the way you are proposing. Can't make it any clearer than that.

To answer your specific point - /sitemap and /sitemap.xml are categorically NOT seen as the same URL by search engines. They are absolutely considered two different pages. Your statement "...two items with the same url, but different file extensions..." is a non-sequitur. If the URLs have different file extensions, they are by definition NOT the same URL. The file extension (or lack thereof) is an integral part of the URL.

Since 3 different people have given you the same answer and you still don't believe us, why not simply test for yourself?

• Implement the two files as above, then use Google Webmaster Tools to report your XML sitemap location, and confirm that it's finding and recognizing it correctly.
• Then use your browser to go to the URL of the regular sitemap and you'll see that it renders the html version of your sitemap map just fine.

Paul

I'm going to suggest a hybrid of a number of the approaches mentioned, Cocoon. And the reason is because you essentially have two different purposes in mind.

The footer links should be thought of as click-generating links for real eyeballs. You want to make it easy if someone like the site you designed to be able to find you as the developer. So it's primary purpose is click-throughs. Design it as the call to action you think will best generate clickthroughs.Making the anchor text a little different on each site can't hurt either.

Being sitewide, and on several different sites, these footer links are prime candidates for Penguin devaluation, so no-follow these. Which isn't a problem because you're designing them for clickthrough, not rank-passing anyway.

Then, see if you can get an editorial link from the website as well. "About" pages can be ideal for this as they usually rank fairly well so can pass some juice. And it makes sense that an About page might talk about the folks who built the site. An added advantage is that About pages don't generally have a huge number of additional links, so there's more juice to pass.

And DEFINITELY try to get reviews from your satisfied clients on Google and Yelp at least. Web designers don't typically show up in local search features, but getting the reviews to help your Google+ Local page to rank as well is still very valuable.

Interested to know what you think of this approach.

Paul

<object id="plugin0" style="position: absolute; z-index: 1000;" width="0" height="0" type="application/x-dgnria"><param name="tabId" value="undefined"> <param name="counter" value="166"></object>

What you actually want to do is get rid of that index.htm address for your home page altogether, Oscar. You want your visitors to only be able to reach your homepage at one URL. This means you need to use 301 rewrites to make your /index.htm page redirect to your primary domain name. (E.g. the website name with no filename after it.)

You also want to make sure that you have chosen between www.youdomain.com and yourdomain.com (without the www) as the primary address, and rewritten the other one to point to the primary. This is called canonicalisation of the home page. The search engines see each of those addresses as completely different pages because they have different URLs - even though they display the same page. As a result, they'll be considered duplicate content and will effectively be competing against each other.

There are many questions here in Q&A that explain how to do these kind of redirects. Let us know if you can't find one that works for you.

Hope that helps?

Paul

The short answer, Kevin, is no, updating the protocol to HTTPS won't have any negative effect on your archival GA view.

Just having the visitor connection resolve at the HTTPS address "should" transmit the referrer info fully (it's the browser that determines this, not GA), but always good to back this up by having the GA property properly configured for the HTTPS update.

Little sidenote - since your site is now HTTPS, any referrals it sends to other non-HTTPS sites will get stripped. If it's important to you to have those other sites recognise you sent them traffic (this is important in some partnership/affiliate,/advertiser situations for example) you can add a Meta Referrer tag to your site so that it will send at least some of the referrer info even to a non-HTTPS site. You can select how much info gets passed based on your security sensitivities.

That what you were looking for?

Paul