Welcome to the Q&A Forum

With HREFLANG tags, you are sending weird signals. I would recommend ensuring that /ie/ is claimed in Google WMT and targeted to Ireland. The content in the subfolder needs to be specific to your Ireland market, meaning it needs to have different content. It doesn't have to be completely different, but different. Otherwise, it looks like duplicate content and the SEs are going to pick the stronger of the two.

Right now, you are telling them that the only difference in the content is that /ie/ is in Irish English, and /gb/ is in British English. It's not different enough to warrant showing the other content over your main homepage as that is stronger.

Does that all make sense? I would remove the HRELFANGs, ensure the right targeting is in place and that the content is different per country to target those countries.

Hi Angelos.

You have a great question and there are a few ways to take this.

What I would recommend is having your www.example.com be a starter page that doesn't have your "homepage" content, but rather, asks people to pick a language. You can detect it from their browser settings or from the IP (whatever you do, do NOT redirect anything based on IP address) and prompt them from there, or just list them all. That page would be your x-default in HREFLANG terms. It's the page that doesn't have a language. Then all of the others would be linked to from there. This would of course have English as /en.

You don't have to do that though. If you prefer, you can totally have www.example.com as all English, and just have the other languages under their subfolders. I would detect if you think the user prefers one of the other languages and use Javascript to popup a prompt to ask if they would prefer that language. If they say yes, then set a cookie and take them there. If not, it keeps them on the English URLs.

Just please don't redirect anyone based on IP address. This can cause problems down the line.

I hope that helps.

These are geo-targeted sections and not translations right?

If so, the HREFLANG tags are not needed. Those are for translations. If you have the subfolders marked in Google WMT as geo-targeted to those countries, you should be okay.

How long have you had this setup?

The best way to go about this is to keep the URLs with the language in the structure. Redirect (301) the ones that don't have it to the ones that do.

However, it sounds like that causes a problem. If the above isn't a possibility, use a canonical from the non-language URL to the one with it. Then do your HREFLANG in sitemaps, and only use the URLs with the language tag in the sitemaps. You can also do the coding on the page, just make sure the HREFLANG tags are not on the non-language pages.

• Example URL: http://www.test.com/boeken would have a canonical tag that points to http://www.test.com/nl/boeken
• Only http://www.test.com/nl/boeken is listed in the sitemaps
• OR Only http://www.test.com/nl/boeken has HREFLANG tags. http://www.test.com/boeken would only have the canonical.

That should solve your problem.

My answer was going to be much like Dirks. There are some Google properties that send traffic as referral, not as search. Can you take a look at the referral traffic from google.com and add "Full Referrer" as a Secondary Dimension and let us know what that is?

Hey! I am going to try to help. I haven't seen this issue either, but I'll try to work through it with you. First, a few questions.

1. Are you using Universal Analytics? It doesn't seem so based on your answers above, but I wanted to verify.
2. The tag manager change you mean is for the new updated interface mentioned here, right: http://analytics.blogspot.com/2014/10/making-tag-management-more-accessible.html
3. Is your AdWords account still attached to your Analytics account? Stupid question, but have to check to be sure.

Thanks for the shout out Ryan!

Hi Angelos.

1. The short answer is yes, you should do all of those entries. Annoying right?

The best way to go about this is going to be writing a script to do the heavy lifting, but I am not cool enough to tell you how to do that. The idea would be to make one sitemap in one language, and if the URLs are identical except for the language code, then changing up everything for the next language and moving on one at a time.

You should have one main sitemap per language if you can get all of your content into one sitemap. Then have one sitemap index hosted at domain.com/sitemap.xml.

If that's not possible due to the sheer number of pages, do a sitemap index per language that references multiple sitemaps to cover the content in that one language. Then have another sitemap index that references the other indices per language.

2.  See above. The main sitemap index should be at domain.com/sitemap.xml, BUT you can have each language sitemap hosted in each subfolder. Example: English sitemap at domain.com/en/sitemap.xml and Spanish sitemap at domain.com/es/sitemap.xml. This requires listing many sitemaps in the main robots.txt file or having a robots file for each subfolder. It's a lot more work than working with sitemap indices.

3. If you have claimed all language subfolders as independent sites in WMT, you can submit the corresponding sitemap. You don't have to put the sitemaps in the subfolders to do this though, you can still use the indices. You also don't have to submit them all individually, but you can and I would as I would want to see the index information in each corresponding account. That's just me though.

Does that all help?

Did you figure this out?

I have not had to deal with this myself and I see where you are having an issue understanding how much data you'll lose. I'll hunt some more and what I can find. I am hoping some others can jump in here and let us know what they have seen.

I don't see anything wrong there ... I wonder if something like this would help you? I've never done it myself, but this article might be worth checking out: http://www.lunametrics.com/blog/2013/12/24/cross-domain-tracking-tag-manager/#sr=g&m=o&cp=or&ct=-tmc&st=(opu qspwjefe)&ts=1420936709

Ah, that makes more sense. Is there any way that traffic could be coming from those domains without having gone to your site first? Can you give me an instance of a path a user might take?

Example: User goes to product page on shop.domain.com, checks out, is referred to na.otherdomain.com, and comes back to shop.domain.com.

I am trying to see if there is another issue in the path of the user.

Also, can you share the tag you are using on your site for GA?

In your attachments, the screen grabs referenced two subdomains, one starting with eu and one with na.

Are these subdomains on the same tracking code as the root domain?

I can't find a live instance of pages on these subdomains, can you give us examples of the tracking code on one page of each subdomain and the main domain (the one being tracked)?

Do you want to track the funnel, each variation and which direction people take? Or do you just want to see the leads coming from the landing page?

Not harmful, I just have a theory that they don't count.

Do you only change it depending on the Canadian location? What do you do for US visitors? Googlebot sees what you give to people in the US.

Here is what they see, which is what I see viewing the page from Texas. http://webcache.googleusercontent.com/search?q=cache:nBPI0a8zKqQJ:www.sja.ca/English/Community-Services/Pages/Therapy%2520Dog%2520Services/default.aspx+&cd=1&hl=en&ct=clnk&gl=us

I assume there is content on this page other than what I am seeing. So duplicate content is not your problem, lack of content is. Google operates on a per country basis, but even knowing that I would still suggest different pages for different regions if the content is really different.

Looks like moz isn't taking the canonical into effect, as long as it's there, you're fine. But I'd warn you not to use relative canonical links ( /directory/page/ vs http://www.domain.com/directory/page/), link to the whole thing. I've seen this go wrong in the past. It's not causing issues now but could in the future.

I do not know of major differences, but it might be worth taking the time to research what is ranking in Bing/Yahoo over your client and compare. Back in the day (2 years ago) I heard rumor that some of the old things still applied: H1, H2, H3 tags, keyword density, etc. That and there was a bigger focus on just number of links. But none of this should change what you are doing. There should be a focus on good site structure, on page tagging, and page/domain authority through links.

The only other thing is to remember that Bing has a relationship with Facebook and can use Facebook social data directly. Not to say that it's the major factor here, but it is something Google does not have.

Just a thought.

Yep, given your resource constraints, I'd focus on translations for now. If you ever get to a point that there is something bigger than price differentiating your content, then you can think about geo-targeting. You will need the resources to differentiate the content though.

Right now, my recommendation is to drop the country specific content and just offer English for now. Your content can rank for any English speaking search, regardless of country. However, if the terms people use in the US, UK and Canada differ that much, you can "translate" the content (en-us, en-gb, en-au) and use the HREFLANG tag.

For price changes, that's tricker, but do you offer the price in search results via schema? Does it show up? If not, then you can use cookies to set the prices dependent on the country the person chooses (try not to use IP address, and if you do, make people confirm the setting).

For now, focus your time and efforts getting the flow right for the user. Only worry about HREFLANG if your English content needs to be differentiated for term usage. Then focus your efforts on getting those upcoming translations right. When that is ready, then really use HREFLANG.

Hope that helps!

If the image does change, your alt attribute text should change the "content" of the page. However, I would question if it helps to have these pages indexed. I assume it's your gallery page you want indexed.

If that is true and your site structure allows it, I would disallow all of those individual pages from being crawled using robots.txt. But that depends on the structure of the site. You can also just add a noindex tag on the image pages.

David also has a good point. (Below)

**1. If we start using "" to make Google (and others) aware of alternative language versions of a given site/URL, how big a problem will "duplicate titles" then be across our domains/site versions? **

If you have translations, that is content that is exactly the same, just translated, HREFLANG is highly recommended for Google. Bing uses another tag though. However, your titles should be different give that they are in different languages. Check out my presentation here: http://www.slideshare.net/DistilledSEO/searchlove-boston-2013kate-morrisinternational-seo

**2. Is it a problem that we in our sitemap include (many) URL's to pages that are marked with noindex? **

I wouldn't put pages in the sitemap that have a noindex. It won't hurt you by any means, just seems a waste of time.

**3. Are there any problems with having a sitemap that includes pages that includes canonical URL's to other pages? **

It's not recommended but it's also not a problem. The only issue comes in having pages that redirect or break all together.

Check the ones you want to delete to see if there are any backlinks to any of them. If there are, don't delete them yet.

For those with no external links, first check the traffic for the last year. None? Then make sure there are no references (links) to them on your site. Once there are no links to the post, then delete.

If there are external links to the post, either update it and republish (301 redirect to the new URL from the old one), just keep it, or contact the site linking and ask them to change the link to an updated post. Don't waste that link equity!

Hope that helps!

Start in Google Webmaster Tools or in the Moz Crawl. Identify those pages with the same title tag and work through that list. The title tag is usually a good indication of duplicate content.

If the content is duplicate for sure, determine if it's a useful duplicate. If so, use a canonical from the duplicate to the original. If it's just duplicated with no real reason, find out how to get rid of the duplicate. This can be anything from unnecessary parameters, to tag pages, and so many more.

You'll start to see trends in the data, try to fix the bigger problems as you see them.

The images are the same on each page? What platform are you on?

The best answer is going to depend on the above. It's not a matter of a canonical vs noindex. If they are really duplicate, image and all, there has to be some way to stop that from happening. But if the image does change, then we can figure it out from there.

There are a few tools: SEMRush, SearchMetrics, and SpyFu.

I have always preferred in the sitemap because it keeps potential lines of code off your page. Everything helps when it comes to page speed.

However, if it's easier for you to put the tags on page, that's is completely valid. Do whatever is easiest to maintain and update.

Hi!

This is a tough one because I can't tell if you mean to be geo-targeting or translate. It's not a one or the other thing, but it usually is when you are just targeting english speaking countries. Can you do me a favor and go to http://www.katemorris.com/issg/ and go through the questions there? Let me know what the "answer" is for your situation and I'll help you get to the right solution.

But in short, yes, the duplicate content is a real issue with or without the lang parameter.

Let me know!

GA should naturally track any sub-directories on the same domain without added code. What exactly are you trying to accomplish?

I've heard it both ways, that a sitemap is a way around the digits in the URL. But I can confirm, for sure, that if you are approved by Google News (must submit for approval), that the digits in the URL will work for sure.

Hi!

Your friendly international SEO here. (PS thanks for the call out there Tom)

You cannot point two HREFLANG tags at the same URL because it's impossible to have both languages on the same page. Well, not impossible, just not recommended. I am not sure if you have translations or not, so both possible answers are below.

Translations (FR and EN) Available
If you have a Canadian subsite and it has two translations, you need to use both geo-targeting and HREFLANG. In your case, the /ca would be geotargeted, but then you need to distinguish the two translations somehow. If /ca is how you are geo-targeting, I recommend parameter for translation. So the French translation of the Canadian homepage content would be http://www.domain.com/ca?lang=fr -- for English of the same Canadian homepage content, it would be http://www.domain.com/ca?lang=en.

The canonical set up in that instance is:

Page: http://www.domain.com/ca?lang=fr

Page: http://www.domain.com/ca?lang=en

Note that the HREFLANG tags are the same because you have to reference the current page and all translations of that page.

Translations NOT Available
Now, this answer assumes that you just have the Canadian content in English, or just in French. If that is true, you don't need the HREFLANG. You just need to geo-target the subsite for Canada.

Now I do recommend that you offer translated content for the Canadian audience, but please don't auto-translate content. Just offer it in one language until you can get the resources to have it translated by a real person.

Hope that helps!

This is an interesting problem to have! I think the issue they are running into is that your auth file for http is redirecting to https. They want you to remove the http site from your account and then add the https site. Once you have done that, you can use the Site Move tool.

Is that a little more clear? I would love to hear if that works for you. it would be a great YouMoz post!

This feels like looking for permission to take a short cut and I personally cannot justify that. I would highly recommend to take the time to make the pages correctly and not even worry about duplicate content or Panda. None of use can tell you if it will "work" or if it'll be seen as duplicate content or when it'll be hit by panda, but if it's auto-generated, I can promise it'll be hit at some point.

However, the worst you can do is test it. Take the top 10% of make/model deal pages and create them how you want. Do it like you're talking and see how they perform. I'm not talking a few weeks, I mean a few months. All the while, be developing the content for some of those pages.

This way, if it works and people like the pages, they are relevant produced the way you want to do it now, the short way, then you can produce the other pages that way. At that point however, your top make/model pages will have unique content that you can put up. So a few months later, you'll have 10% of your deals pages with unique content and the rest automated. Then start working on the next top 10%. Keep going until they are all done.

There are a number of things that go into the decision to use ccTLDs or not.

1. Will your content change at all across the different country sites? So if you had .dk and .co.uk, would those two sites have different content at all?
2. What countries do you sell to or are you world wide?
3. Do you users in different countries need to see different content? Meaning are there any substantial differences in buying behavior or needs?

Answer those questions and we can go from there.

Exactly! The mobile content should match the main site.

What are the pros and cons for referencing all page versions in sitemap and for include just general (English/Desktop) version in sitemap?

Let me clarify, you want to know the pros and cons of putting all page versions in sitemaps, or just doing the english/desktop and letting Google figure it out.

List All Content in Sitemaps

• Pros

• If the sitemaps are set up in a logical fashion, this makes for an easy way to see indexation issues.

• You can use hreflang in the sitemaps rather than on the page. This reduces page code and ups page speed, albeit slightly.

• You are guaranteed that search engine will find all of the content.

• Cons

• Lots of sitemaps to make and maintain.

Sitemap just main content (desktop/english)

• Pros

• Easier to maintain.

• Search engines are much better today at finding most versions of content.

• Cons

• Run the risk of content not being indexed correctly.

• Some content might not be found and indexed.

• You could not easily verify indexation.

• If any onsite code was removed that told Google where to go, then the possibility of indexation issues increase.

Hope that helps answer your question!

Did your company explore doing a responsive site rather than an m.domain.com mobile specific site? That would take care of any issues.

For the mobile site you have now, you should have all content on the main site optimized for mobile. That means all pages should have a corresponding mobile page and a rel=canonical from the mobile page to the desktop page.

You also need to fix the redirects and ensure the mobile experience is always top notch.

This is a good resource for you: http://blog.hubspot.com/insiders/how-to-follow-googles-mobile-rules-for-awesome-seo

I think you asked a similar question a few months ago, but the only update I know about is the one mentioned in that question from the other responder. Sorry to not be of more help, but it could be an iteration of that update.

I'm going to endorse Andy's answer as well as adding one here. His link to Matt's video is what I would add, but I wanted to address the redirect affecting ranking. The redirect is basically ensuring that you won't show in results for mobile users. You need a page to rank to even attempt to rank. You are sending the signal now that itunes is the right page for users, so that page will rank. The redirect is most certainly impacting your performance mobile and desktop. iTunes has desktop accessible pages as well and you are pointing your authority to them.

Beyond that, there haven't been studies that I know of proving this just because it's a bad user experience on top of a bad search decision.

PLA = Product Listing Ads

Paid is typically AdWords and AdCenter, paid search things. But stuff like Reddit advertising, Facebook, Twitter, and other display advertising, and maybe PLA based advertising (that might be your Google), is Other Advertising.

When you click into Google, have you added a second metric of something like destination URL to see where the traffic is going? That might give you some clues.

Not sure. All organic search traffic should be going into Organic and Other is really set to CPC type tracking. Can you list what the other section says for you?

Most of what you see in other is from paid sources, even traffic from Google. I would not count the traffic you see in Other as natural search traffic unless you are 100% sure. Everything in my various client's Other categories are paid sources.

From a not local perspective, redirecting based on IP is generally not the best idea. Early on at Distilled in Seattle, our I{ address was in Washington DC! IP Addresses are not reliable in the United States.

There is that problem, plus the fact that Google only crawls from California. Therefore, depending on how the redirect was set up, they might just see the San Jose area content.

Therefore, I am glad you decided against the redirect. I think your idea of letting people define where they are and find a new provider is perfect. The people in your area get the right content and others that happen on that page get to find a preferred vendor.

You have a few choices, none of them include setting a goal like you want. I can't see any way to do it they way you want.

Option 1: Create profile that disallows the phonecall URLs and set the goal in that profile.

Option 2: Create a custom segment that removes the phonecall URLs from your dataset.

I wouldn't freak out too much over the crawl rate immediately. Wait a few weeks and see how things go. It sounds like you did the right thing and should see the benefits over the next few weeks.

Hi Rob,

Great question and I am glad you are looking into how your site responds to mobile users. It sounds like you are having some issues with smartphone users.

To be clear, it's best if you approach this problem from a screen size rather than a specific phone type. Your website works fine on tablets, but it's smart phones you have a problem with. You can do a responsive design that changes based on the user screen size rather than phone type which can get really hard to develop for really quickly.

Here is a guide we have developed for all things mobile design and SEO. We highly recommend making your site responsive (no need for m.domain.com or domain.com/mobile), which will take care of any issues with linking in the future, shares, and all other forms of user confusion as well as search engine confusion.

Also here are mobile recommendations straight from Google.

Hope that helps!

According to Google, Other is actually not organic. It's other advertising channels. See the link below and how they define other.

https://support.google.com/analytics/answer/3297892?hl=en&ref_topic=3125765

That is most likely the issue then. If the site is 2 months old, then there isn't enough trust in the site yet. Google, because the site is so new, is showing the user the most relevant and most trusted pages for the phrase "Series Digital". If the site was older, or had ranked for that term for some time and then dropped, I would be worried, but this is all very natural.

You are going to need to do some basic SEO to the site to help this process out. The homepage doesn't have a meta description. The homepage page title is a little over optimized. Try approaching the titles from a user standpoint and having a unique meta description for every page.

Have you submitted an XML sitemap to Google as well? If the company just launched, are there any plans for press coverage?

Are you seeing drops in natural search traffic for other pages on your site other than the homepage?

And is this term a competitive term for your market? I know it's your name, but I am curious if there is something else at play here.