Welcome to the Q&A Forum

I'm assuming you include these tags for Facebook's benefit, because if you want to send localization signals to Google, it's better to use hreflang.

Hreflang allows a comprehensive range of countries and languages: you can combine any two values from the ISO-639-1 list of language codes and the ISO-3166-1 Alpha 2 list of countries.

The locales supported by Facebook are a lot more limited. You can't have en-IT for English speakers in Italy, for example, because Facebook doesn't support that value. Facebook only allows the following English-language locales:

• UK English: en-GB
• US English: en-US
• English (India): en-IN
• English (Pirate): en-PI
• English (Upside Down): en_UD

You can see Facebook's full list of supported locales on this page.

So the answer is that it won't matter where your users are. What will matter to Facebook is the style of English you use. If you write in British English, you should use en-GB, and if you use US spellings then use en-US.

Hi Florin,

It's a bit difficult to say, because this is a big topic, and there are many things you have to do in order to get the links working.

You're doing the right thing on the website – your links are correctly formatted – so you need to focus your attention on the app. There are no independent guides I can recommend you, because the specification changes quite often, so you really need to work through this page and ensure that your app has followed all of the guidelines.

Secondly, if you haven't already got Android Studio you should install it, and then test the links in there. You'll get more detailed error messages on specifically why a link might not be working. Android Studio's link testing tool is described here. Even if you still aren't entirely clear what the problem is, you'll at least have a specific error message from Android Studio. You can then post the error message to a programming Q&A site like Stack Overflow, where you're more likely to get specific advice that'll help you solve that error.

Hi Jon,

The information showing up in the rich snippet has been taken from the very well-structured table that appears on the right-hand side of many Wikipedia pages. This data is very easy for Googlebot to read (because it's in a table), and regarded as trustworthy (because it's on Wikipedia). Depending on how Google interprets your intent, it may or may not borrow from this well-structured data in the rich snippet.

For example, on the Wikipedia page for Optical Express, there is again a table that lists key data about the company: the year it was founded, who the founder was, and which products it sells, among other things. When I search for "optical express contact lenses", the Wikipedia entry doesn't have a rich snippet, even though contact lenses are listed in the product field in the table. If I search for a less commercially-minded term, like "optical express founder", I do get a rich snippet with information about the company and founder (see the two images I've attached here).

So the point really is that there are no guarantees, and no direct control over the rich snippet, but you and your clients should definitely expect to see a lot more of this kind of thing in future, whenever Google is confident that a rich snippet provides a good answer.

As for what you can do: your client won't have Wikipedia's authority, but you can use structured data, such as JSON-LD or Microformats, to make the meaning of your words more transparent to Google. This will increase the chance, at least, of meaningful rich snippets with information about your client's company or products. Tymen has linked to a couple of useful resources, which you should use to ensure that you're implementing the structured data correctly.

46K6eW5 FcNv710

Hi Jerome,

1. If your SaaS vendor allows it, you should use subfolders for the countries instead of subdomains. So www.example.com/uk instead of uk.example.com, for example. The reason for this is that the subdomains won't share link equity as effectively.
2. You should implement hreflang -- Moz has a great introduction to the topic here -- on all equivalent pages (I'll explain what I mean by that in a second).
3. By all means choose sensible default currency options (for example GBP should be the default currency in the /uk directory), but preferably do allow users to change that default value if they wish. If they do change it, do not direct them to a different URL. Use a cookie to store their currency preference.

Now, more on 'equivalence'. The point of hreflang is so that you can have identical or very similar pages targeting different country/language combinations, and have Google discard these pages as duplicate content. The pages don't have to be completely identical. For example, Americans and Brits use different spellings for common words. If my product was online math(s) lessons, my two equivalent URLs may look like this:

• www.mystore.com/us/online-math-lessons
• www.mystore.com/uk/online-maths-lessons

The language, tone, and general marketing pitch of each page may be different, and tailored to their respective audiences, but they're each fundamentally selling the same product. So I would add the following hreflang tags to these pages (both tags on both pages):

Be careful to use the correct country codes: en-UK is not valid, for instance, but en-GB is. Read Google's guidelines on the topic.

Hi Justin,

Sorry for the late reply here. Yes, I likely would do that. As long as the site categories are set up properly, you shouldn't require any product attribute pages to make a product discoverable for Googlebot. And the pa_ attribute pages tend to make for a poor landing page experience. If a product/attribute combination is especially important or profitable, I'd usually set up a custom landing page for that, rather than rely on the product attribute archive pages.

You should 302 redirect non-authenticated users to http://twiends.com/login.

This is a better user experience, and you avoid the potential authentication issues with the 301. It's also not really correct or useful to make it a 301 redirect: users aren't being 'permanently' redirected to the login page, and there's not much utility in forcing link juice to be passed from /settings to /login either.

So requests to /settings should either show that user's settings or 302 redirect to /login. Don't duplicate the home page content and rely on a canonical tag. Your domain (and domain authority) are still going to benefit, and I just don't think there's enough of a case to sculpt the flow of link juice in this way. As Andreas has pointed out, the link juice isn't the most important consideration here; it's better to focus on user experience. Your homepage's ability to rank for any given term is unlikely to be affected by the decision to 'rel=canonical' all private pages to the home page.

Hi Neil,

Don't host the video in two separate locations. You don't want to publish it to Youtube and also store it on your own server, for example. In light of your latest comment, I'd suggest you publish the videos to Youtube, embed those videos on your site, and encourage the hotels to do the same. You should associate the Youtube channel with your own site, and provide links back to your site from the videos (as Andy suggested). Follow the steps outlined in Youtube's guide.

In an ideal world -- a world where all 90 hotels were happy to link to your website -- this advice might be different. Ideally, you'd have links to your site. But if you self-host, it seems likely that you'll have hardly any views: your hotel partners won't link to the videos, and the videos won't be easily discoverable. By hosting on Youtube and encouraging video embeds among your hotel partners, you can at least, as you said, generate a lot of interest around the content. Google does favour Youtube videos in SERPs, so this strategy should help your Youtube channel perform well for queries related to your partner hotels. You can use cards or annotations in the Youtube videos to direct visitors to your site, as well as providing a link in the description.

It depends how much time and money you have to devote to this, but here are a few suggestions:

• Create two subfolders for your site content: /en-gb/ and /en-US/. All your UK-focused content can go in the en-gb folder, and US content in the en-US folder. Use the country-appropriate spellings, and ideally tailor the actual page copy: your two audiences probably use quite different turns of phrase; one marketing message may be more resonant with a US audience than a UK one, etc.

• Ensure that every page that has both a UK and a US version has hreflang properly implemented. That means that, if we have URLs "www.example.com/en-gb/product-1.html" and "www.example.com/en-US/product-1.html", both talking about the same product, the following two hreflang tags must go on both of those pages:

• If the majority of your customers are based in the US, or speak US English, you may wish to make that the default language in your hreflang tags. To do so, just change my example above to the following format:

All that's changed is that the en-US pages are now hreflang="x-default", which signals to Google that, unless a user has a preference for British English, they should be served the US English content.

• Do not redirect users from one version of the site to another based on their IP addresses, as this will mean Google cannot crawl the UK version of your site. You might want to do something like Amazon does, where if a UK-based user visits the US version of Amazon, a banner appears at the top of the page to suggest they visit the UK site, and provides a link to amazon.co.uk. That's a good example of suggesting something useful to your users without forcing a redirect.

Hi Maurice,

Yes, that's right: the Hotel Nicolaas site is behaving correctly. When I visit the homepage there, everything is consistent and in English, and the language cookie is set to en-GB. Even when I manually change that cookie value to nl-NL, the content is still in English, because I'm on an English-language URL. To get Dutch content I have to visit the /nl/ directory. That's a much better setup, because there's no way to end up with duplicate English-language content: the URLs are consistent.

Best Regards,

Stephan

Yes, you can use the following two rules, in this exact order, in your .htaccess file. I'm assuming you've got mod_rewrite on.

RewriteRule ^([^]*)([^]*.) $1-$2 [N]
RewriteRule ^([^_])([^]*)$ /$1-$2 [L,R=301]

The first bracketed group in each rule -- ([^_]*) -- matches every group of characters that isn't an underscore. The first rule rewrites every underscore in the URL to a hyphen, until there's only one underscore left. At this point, control passes to the second rule, which replaces that final underscore with a hyphen, and 301 redirects to that page.

Hi Maurice,

Sorry for the delay in getting back to you. To address points 2 and 3 that you've raised there:

2. I'm still seeing this behaviour on the site, and it persists across different browsers. I've attached some images to show what I'm seeing. However, if I then click on the English flag (to visit /en/), and then click the Netherlands flag, a cookie is set: jfcookie[lang]="nl". After this cookie is set, the homepage appears in Dutch for me. So it seems as though visitors to the homepage of your website are served English-language content based on the absense of a jfcookie[lang] cookie, or based on their IP address -- you would have to check with your developers which is the case -- and it's only after visiting one of the other languages and then switching back to Dutch that the homepage will appear in Dutch.

3. I don't believe you would see a rankings boost from doing this. I think that, provided x-default is correctly set (to English, in your case), and this issue with the language cookies/IP address is corrected, you can expect Google to figure out the correct page to show in the results for each country/language combination. I do hear what you're saying about most of your customers speaking English, but I also think that, given you use a ccTLD, it could create a strange user experience to have English content on the homepage and Dutch in a subfolder. And x-default largely solves the problem of most of your users speaking English. I don't think there's enough upside to justify the effort.

NgA7duW oG21GhC yV7Qtre 8flDbPz

There's a good, detailed article on this very issue from PMG. Does this answer your question? If you don't think it does, can you provide more detail about your app, as this will help you get better answers.

When was your app last updated?

Are you referring to having 4 stars overall (i.e. over all versions of your app)? Or is that the star rating for the most recent version?

How many reviews does your app have, for the latest version and over all versions?

Hi Justin,

Yes, you're correct in your response on Nov 26: XML sitemap exclusion won't guarantee that the pages aren't indexed, as they can still be discovered by Googlebot. Instead, you'll need to edit your Wordpress theme. I'll give some instructions for the 'Storefront' theme here, which should work in the majority of cases, but you may need to amend them if your theme is heavily customized.

When the page loads, it'll call the get_header(); Wordpress function, and pass the argument 'shop' to it, like so: get_header('shop');

That will prompt Wordpress to go looking for a file in the theme root called 'header-shop.php'. If that file doesn't exist, it'll load the default header.php file instead. If you do have a header-shop.php file, edit it to add the meta noindex tag on category pages. If you don't have a header-shop.php file, make a copy of header.php and rename the copy header-shop.php, saving it to the root folder of the theme.

Now in the header-shop.php file that you're amending or have just created, add something like the following before the closing tag:

if ( is_product_category() or is_product_tag() ) {

echo "";

}

You should take care to ensure that the conditional statement there is working: you don't want to inadvertently noindex all of your shop pages! So test carefully on a local version of the site, and make sure that you aren't seeing noindex tags in the source code of the non-taxonomy pages.

I'm afraid I don't know the answer to your second question. If I had to hazard a guess, I'd say it's because the developers would receive more criticism for enforcing noindex tags on certain categories of page than for not providing a noindex feature. If they put noindex on taxonomy pages by default, for example, and didn't provide an easy plugin for removing it, they'd probably get complaints about that. Or it just isn't an important enough issue in terms of the overall WooCommerce development roadmap.

Hi Maurice,

Both of these pages are on the same root domain, because you've (sensibly) used subfolders for languages, instead of subdomains. The arrangement you're thinking of switching to does sound as though it better describes target market: it'd be nice to see x-default set to english, if that's the language spoken by the majority of your visitors/target market.

When I visit the homepage as Googlebot, the hreflang is "nl", but the html lang is "en". Also, the page content appears to be in English. When I then navigate to hotelcitadel.nl/en, I get exactly the same English-language content, with html lang equal to "en" again, and hreflang "en".

The other languages work OK, and are crawlable, but you should correct the duplicate content issue between the homepage and the /en/ subfolder, and also the discrepancy between "html lang" and "hreflang" on the homepage. It should either be definitively in English, for all users, or definitively in Dutch. Perhaps you're using an IP redirect to determine language on the homepage? If so, I'd suggest not doing that. Your other languages seem to be set up OK.

If you want to prevent member-only pages from showing up in Google's index (and I assume that is what you're after), then what you want is "noindex", or ideally just to block the pages in robots.txt. A quick look at your site indicates that there's members-only content in the 'resources' and 'presentations' folders (though of course there may be others you also want to hide). Then, in your robots.txt file, you'd put these lines:

User-agent: *

Disallow: /resources/

Disallow: /presentations/

Now even if Googlebot discovers these pages somehow, it won't crawl or index them, and you won't see these pages showing up in a Google search.

Hi Chad,

First off, you're right to be thinking about adding product attributes for the size, colour, etc. You should definitely do this.

I wouldn't recommend tags unless there's a strong reason to use them. Tags can be of genuine use on a blog, by providing users a way to navigate a group of related posts, without the blog author having to devote a whole category to it. But eCommerce sites, depending on their size, can already have a pretty difficult time with duplicate content, and it's hard to see how tags would improve the user experience more than tightly-focused subcategories.

If you have a category called "beds", for example, it makes more sense for "double beds" to be a subcategory within that, than to be its own tag. WooCommerce does support nested subcategories, which should allow you to get pretty granular if needs be. You can make use of breadcrumb navigation this way as well.

Finally, on the subject of product attributes again, note that WooCommerce adds attribute filters to the URL as a parameter. So if searched for double beds on your site, the URL would resemble the following:

yoursite.com/beds/double-beds/?min_price=250&max_price=600

You should make sure you've got rel=canonical in place. Also, given that your client is a search engine, I imagine they'll have quite a lot of product pages. To help Google use their crawl budget efficiently, you might add some lines like the following to the robots.txt file, so Googlebot doesn't try to crawl any commonly-used parameters:

Disallow: ?min_price=

Disallow: ?max_price=