Welcome to the Q&A Forum

Yes, that looks correct now. And in your specific case, x-default might indeed handle the rest since Europe is your default, and that's where the unspecified combinations are most likely to be for you.

I wouldn't be too concerned about site speed. These are just links. They don't load any resources or execute any scripts. For most intents, it's similar to text. The main difference is that they will be links that may be followed by the bots. But really, even though you'll have many lines, you only really have two actual links among them. So, I wouldn't be too concerned about this part.

Good luck.

Moon boots. It looks like you decided to target by language, rather than by country-language combinations. And that is acceptible. It has a few issues, for example if you target by FR you are going to send both France and Candaian French speakers to your Europe site (and I don't think you are wanting to do this). On the other hand, if you were instead thinking that you were specifying the country code, no, the code you pasted here does not do that. Per the spec on hreflang, you can specify a language code without a country code, but you cannot specify a country code without a language code. All of the hreflang values you used will be interpreted as language, not country. So, for example, CA will be interpreted as Catalan, not Canada.

Again, I know it's a giant pain to handle all the EU countries. All of us wish Google made it feasible to target Europe as an entity, or at least target y country even. But it's just not the case. Yet. So, the way we do this is generally with application code. Ideally, in your case, I would suggest for that code to generate, for each country, one entry for English in that country (like "en-DE"), and another entry for the most common language in the country (like "de-DE"). That will generate many entries. But it's the only way I know of to effectively target Europe with an English language site.

moon-boots. Pretty close now. You should add the x-default to each site too, and they should be identical (whichever one of your sites you want to present for any locales you've omitted).

But also, realize that "en-it" is a pretty fringe locale. Google woudl only propose this to a search visitor from Italy who happened to have preferences set for English in their browser. While there are plenty of people in ITaly who do speak English, there are far fewer who set their browser to "en".

I have the same issue in Europe. Germany is one of our largest markets. I initially targeted, like you've done, just English in each country. We previously (a year ago) had a German-language site, and that one we targeted to "de-de". When we stopped maintaining the German-language site, we changed our hreflang tag to "en-de". We quickly found that all of our rankings dropped off a cliff in Germany. I would recommend, at least for your largest addressable markets, to also include hreflang tags for the primary languages. Thsi is another thing whcih Google hasn't yet made easy. They allow to target by language without country, but not by country without language. At least in hreflang (which was really developed for language targeting). GSC (the legacy version) had country-level targeting there.

Lastly, you included URLs for your home page here. But I'm assuming you realize you need to make the tags page-specific, on every page. If you put these tags as-is on every page, then you would be sending a signal to google equivalent to pointing every one of your site pages to a canonical of your home page (and effectively de-indexing the remainder of your site's pages). I'm assuming you're just using home page as an example in your posts. But if not, then yes, you will need to do page-specific tags for each page (and the self-referencing ones need to match your canonical tag for the page).

So, that's exactly why I wrote that you should include all the EU countries as specified locales, pointing to the EU site. Only everything "unspecified" goes to x-default. Alternatively, you could point AU, CA, NZ to the US site, and make x-default point to your EU site. I don't think that is as good of an approach though. Like I said, everyone who has a EU site has this issue. It's a pain that EU isn't a valid "locale" for hreflang. Maybe something will eventually be in place to handle better. In the interim, we can add hreflang for all the EU countries (or just prioritize the markets you really serve).

No, that's not a correct x-default implementation. It should point to the same URL on both sites. Wherever the non-specified locales should go (pick one).

As far as reciprocal, Google checks that they are "reciprocal" in that each locale which is pointed to has hreflang tags which point back to the other site for its locale. There is no point in having hreflang tags only on one site.

And, you definitely shouldn't specify just "EN" because that would include the US too.

So, a few things in here to respond to:

On x-default, ideally you want this on both "sites", but it would be the same value. Meaning, you are telling Google that if a search visitor is in the US, serve the US page as a result, if the visitor is in the UK, serve the UK page as a result, and if that visitor is in any other location (one you don't have tags for) then serve the page linked in the x-default tag. So, on both sites, it would have the same value. Wherever you want to send the traffic from any country/language not specified in your hreflang tags.

On the EU tags, there's not a "penalty". There's just no "Europe" locale. Since you need to specify valid locales, the only way I know of to scope "Europe" is to include all the locales (or at least the most popular ones. I generally add the primary language for each country, a few languages for countries such as Belgium, and sometime I add en-[country] for all of them if my EU site is in English only.

Also on the EU tags, you should not remove the EU tags and only tag the US site. Tags will all be ignored unless they are reciprocal.

Lastly, on the redirect. There are several approaches. But if the Google bot tries to index your UK site from a server in the US, and gets auto-redirected, that's not a good thing. One approach is to make the auto-redirect "soft", meaning instead of automatically redirecting, present a dialog asking the visitor whether they want to visit the page they requested, or to instead be redirected to the one suggested for their geographic location. This is also a better user experience for several scenarios like when employees may be using a corporate VPN which is located in another country (like their international headquarters for example), or for when people live near country borders. Yes, you want to treat Google the same way as a person, which is why the "soft" redirect approach has become somewhat of a standard. There are other approaches, like having an international "splash" page, and also yet more approaches. I tend to favor the dialog approach.

While your tags above looks correct, I would also recommend to add "x-default" hreflang tags. This lets the search engines know which version of the page to include in results for search traffic outside of the ones specifically listed.

Related to this, I notice you referred to one of the sites as "Europe", but you only included an en-GB tag. Unfortunately, the specification for hreflang doesn't accommodate "Europe" (I wish it did). So, most of the time I generate hreflang tags for all the most common language/country combinations in Europe, all pointing to the one "Europe" page, when I'm dealing with sites which have a single site for all of Europe. This approach isn't pretty, but I haven't yet found a better one. Perhaps this might explain some of your drop, if now you are only targeting UK and US, whereas before you might have reached other parts of Europe and the world in general.

I would try adding x-default and the other European country/language combinations before just dropping the idea of hreflang tags.

Also, you may want to make sure both of these sites are accessible without redirection from all locations. Search engine bots may arrive from servers anywhere, so you want to make sure you don't auto-redirect them based on geo-ip.

This is very interesting, and I see from the threads you linked that multiple businesses are having the same problem and the same difficulty navigating both the Google or Facebook support communities. Out of curiosity, are you able to inspect one of your Facebook pages whcih still has the video, and see if any schema for the type "VideoObject" is included in the page, and if so, paste the markup here (redacted as necessary)? I don't think I'll probably be able to help much on this, but perhaps something in the schema data might give some clues to the community here to work with.

Primarily, the requirement is to be in the section. However, I have seen cases where a long-load-time resource in the above meta tags can cause meta tags to be ignored. These were fairly extreme cases, where the resource took multiple seconds to load, synchronously. But moving the meta tags (and Title) above those resources fixed the issue. Also, in another case, we had a snippet from a CDN provider which included an iframe, and in that iframe there was a section and a closing . It turned out that Google was ignoring all of our tags after the which was injected in that iframe, even though it was only supposedly closing the section opened within the iframe. Once we moved that iframe to the end of our own section, below all our meta data, the issues resolved. So, with all that, I do recommend putting meta data at the top of the section, but depending on what else is in there, it might not be an issue for you.

I also suggest to double check that the actual title tag (the first one you included in your post) is in the section of the page, and not the . And preferably high up in the section before any scripts or other elements which could take significant time to load. Check this in "view page source" and not just using the "inspect" function of the browser's dev tools, to ensure that some scripts on the page aren't altering the title tag after the document is loaded, since the search engines may instead use whatever is initially set in the actual of the document before scripts execute.

I think that might be a successful approach under some circumstances. For example, if the company is a brand, and their storefront is only one aspect of that brand but you think that they might otherwise rank for searches of non-transactional intent. An example might be a museum which also runs a gift shop. Or a manufacturer who also manages a direct-to-consumer storefront but where that is not the focus of their business. In these and similar cases, having a separate set of pages (whether on a subdomain or preferably just in a subfolder if feasible) for the commerce isn't necessarily a bad idea. I'm assuming when you wrote "proving to be highly restrictive", you meant more than just for example not being able to set the exact H1 tags you might want on a page or not being able to insert schema markup for certain types of objects. There are going to be those kinds of tactical challenges for on-page SEO in every platform, just varying degrees between the platforms, and I wouldn't take a drastic approach like separating the storefront just because of those kinds of issues. But, if the SEO challenges with the current platform are really of the highest severity and can't be addressed within that platform, then the approach of a separate storefront might make sense in the kinds of scenarios like the museum or the manufacturer mentioned above.

Glad to hear. Hopefully mine will too, but it's been 6 months already and still showing the old brand name as a suffix.

Ross, we completed the rebrand and domain migration in February (so, about 6 months ago). All of the pages to which I'm referring have been re-indexed and the cached version is in the past 60 days. The page title shown in the SERPs is our new page title, on all of these, just suffixed with our old brand name. So, Google has had time to update all our titles and descriptions. But for whatever reason is appending an old brand name, and I don't know where it is getting that from, nor the dash and spaces that it is including with those (interesting that in your case it is appending a colon).

At the end of some of our listings in Google search results pages, our old brand name is being suffixed even though it is not in our title tags.

For context, we re-branded several months ago, and at that time also migrated to a new domain name. Our title tags have our current brand name suffixed, like "Shop Example Category | Example".

In the Google search results, but not in Bing nor Yahoo, about half of our pages have titles whcih instead look like this: "Shop Example Category | Example - oldBrandName".

The "dash" and the old brand name are not in our title tags, but they are being appended, even when our title tags are fairly long. For example, even with titles at 54 characters (421 pixels), the suffix is being appended. BUT, not with our longer title tags.

We are actually OK with the brand name being appended if our title tags are on the shorter side, but would prefer that our current brand name be appended instead of the older one.

I realize we could increase the length of all our title tags, and perhaps we may go that route. But, does anyone know where Google would be getting the old brand name to append onto the URLs? We've checked and it is not in our page source (the old brand name is used in our page source in some areas of text and some url paths, but not in any kind of meta tag).

Per Google's guidance (https://www.searchenginejournal.com/google-do-not-put-organization-schema-markup-on-every-page/289981/) we only have schema for the "Organization" on our home page, and not on every page. So, assuming this advice is correct to not add schema to every page, how can we inform Google of our current brand name so that it stops appending our old brand name on pages?

An interesting dilemma. Often, UGC like forums or reviews is considered as a boost for SEO. But it seems you have concluded that in your case, it is a detriment.

I'm not completely certain of what would be the best strategy in your case, but I suggest you might start with exploring the main reasons why the forum is hurting your rankings (assuming it is). One possibility is that the forum content might contain links to spammy sites. To combat that, you might nofollow those links which are inserted into your user generated content. Perhaps even use the new-ish rel=ugc tag whcih Google introduced (https://webmasters.googleblog.com/2019/09/evolving-nofollow-new-ways-to-identify.html)

Another strategy might be to leave the UGC in place, but to make it not crawlable. For example, reading it into the page using a script from another URL which is disallowed in your robots.txt file. If I were to explore this method, I woudl probably start with some experiements on just a few pages, to measure the impact (out of caution in case the assumption that UGC is the culprit might be incorrect).

Lastly, the forum does not need to be on the same root domain as the website. Again, I'm not sure this would be a positive move or not, but you could register an entirely different domain, and even disallow crawling. Or, it could be another subdomain on your root domain, but again with disallowed crawling. If you want people to be able to find the forum, but are worried about the content being indexed, you could only allow crawling of a few key pages on it whcih are non-UGC.

But mainly, I think your challenge seems to be a very good candidate for running some experiments, rather than relying on opinions from those of us (myself included) who haven't been in your exact scenario before.

Typically, a "vanity URL" is an address you use in advertisements which is redirected to your actual page, sometimes along with some tracking parameters in the query strings portion of the URL. This is usually for the purpose of shortening the URL, or making it easy to remember, for use on radio, television, print, billboards, etc. So, in this context, yes a redirect (usually 301) takes care of sending the traffic (and the search engines if any happen to discover one of the vanity URLs) to the real page.

But the phrasing of your question makes me think you are not using "vanity URLs" in this context. If they are being indexed, I assume this mean you are creating actual copies of the pages, or possibly forwarding the page request without changing the URL. If this is the case, then using canonicals (one from the secondary to the primary page, and a self-referencing one on the primary page itself) can be of help to you here. But, I would first question why you are ending up with multiple URLs for one page in the first place.

So, if both versions of each English pages are identical, and both for the US market, then I think you may need to utilize two different approaches together. First, you can use cross-domain canonicalization on the English pages on the secondary domain to point them to the primary domain (along with a self-referencing canonical on the primary domain). And second, you can use hreflang tags on the English pages on the primary domain and the other languages on the secondary domain, to specify which versions of each page are for which locales (along with x-default and self-referencing hreflang tags).

On the other hand, if the English pages on the secondary domain are for another English language market (non-US), then you could use just a full-blown hreflang solution.

The common solution is to overlay the text on the image, rather than producing the image with text in it. The overlay text can then be given an H1 element.

Canonical reference links are the preferred technique for this.

If you do nothing, very likely the search engines will decide for you which variations of your pages to index, and the selection may not be ideal. If an index page can be filtered many different ways, the unfiltered version should be referenced as the canonical on each, and a self-referencing canonical link should also be specified on the unfiltered version.

You don't really yet want to disallow the crawling of the refinement paths, because without canonicals implemented, you might very well do more harm than good, finding important pages getting de-indexed. If at some point in the future you find that all the URLs from the refinement paths have been disappeared from the index, and your desired pages are all indexed properly, then at that future date you might want to disallow crawling of the refinement paths (in your robots.txt file). But, not yet, IMO.

My feedback here is that if none of the content differs, and is all in the same language, then it makes most sense to point all those other domains to the one global site. But, if you have different products or information in the different countries, or if you are maintaining your site in multiple languages then the decision becomes whether to use separate domains, subdomains, or folder paths. All of those 3 approaches are valid, and each has pros and cons. But your question seems to be about whether or not to have a global site versus separate sites, and so my answer is that you should have one global site if you only maintain one language and the content/products are the same in all geographies.