Welcome to the Q&A Forum
Browse the forum for helpful insights and fresh discussions about all things SEO.
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.
One alternative to the "noindex" directives described below is to instead implement a canonical link tag to an alternative page you would prefer to be indexed for the same content. This would only be relevant if there was another very similar page. And, it would not be as strong of a directive as the "noindex", so I would not use canonical if it's extremely important that it not be indexed, like perhaps some sensitive info.
If you do go the NOINDEX route, then I would suggest, after you verify it has been properly implemented, to use the removal tool in Google Search Console. It technically isn't needed, if you have the NOINDEX directive, but it is usually recognized more quickly, and won't conflict. And then, once the page is out of Google's index, the next step (and only after it is removed and has the noindex tag), is to disallow crawling of that page in your robots.txt file.
This is commonly done intentionally, when launching a site on a new domain. Once the disallow is removed, the general practice is to request reindexing of the root domain page (and possibly some key pages with paths not likely to be found through navigation) in GSC, and also submitting (or re-submitting) your sitemaps directly in GSC (even though they also may/should be in your robots.txt file).
I'm not sure how long you can expect the search engines to take, since your situation is a bit unique where the site was indexed, and then disallowed temporarily. Just guessing based on launching brand new domains, the process should be quick to be indexed (perhaps a few days) but might be slower on regaining previous ranking positions (unsure on timing of this).
Thank you Dave. Yes, please do submit as a feature request. Operators of global sites often have "duplicates" of every single page on their sites, which hreflang (when properly implemented) is intended to distinguish as non-duplicates (but rather country/language variations). So, this would be very useful, in that it would allow us to focus on real duplicate content issues, instead of false positives. But your answer was the confirmation I was seeking, so thank you for clarifying.
We have 5 websites, each targeted at a different geography. They are all in English, but targeted per country (e.g. US, Canada, UK, Australia). And we've properly implemented hreflang tags on each page, with the US site being the x-default, and with each country-specific page having a self-referencing hreflang tag as well as individual hreflang tags pointing to the other country-specific versions.
All seems to be working properly with the search engines.
But, each week in our Moz Pro campaigns, Moz reports the pages as "duplicate content". It seems that Moz does not regard the hreflang tags when deciding if content is duplicate or not. I'm not 100% sure that's what's causing Moz to report them as duplicate, but it's my best guess.
To date, I've been marking these as "ignore". But, that creates two problems. First, we have new pages all the time, and so this gets to be laborious. Second, it makes it somewhat likely we might miss a real duplicate content issue.
Can someone confirm whether Moz should be looking at hreflang tags before considering pages as dupliacte? And possibly offer any suggestions to us if Moz doesn't do that?
If I understand your question properly, the majority of the content on each page is unique, and the page titles and descriptions are unique, but just one section of each page contains some common content which is the same sitewide. So, if this is a correct interpretation of what you wrote, then I don't think the search engines are going to consider the pages as duplicate. This scenario is no different than a common footer or a header navigation section, which are generally the same across all pages of a site.
Also, my perspective is that duplicate content is not a penalty as some people may think it is. Rather, it is a chance that the search engine will choose to not index some of your pages if it thinks that other pages have the same content and that those pages should be indexed instead. In cases where the pages are really just versions of the same thing, this can actually be a good thing. If you had 10 extremely similar pages, all targeted at the same exact visitor queries and intent, you would likely want only one of those indexed. And then, to make sure your preference of "which one" is followed, you would implement a canonical link on all 10, pointing to the preferred one. But, if you did nothing, the search engine might just pick one, and that might also be okay for you (not as good, but okay).
In any case, the situation you described, where there is a sitewide element visible on each page, I don't think is likely to cause the search engines to consider your pages as duplicates, unless there is very little or no other unique content differing on each of those pages.
As you wrote in your question, it is best to only link when the product exists in those other countries/languages. Both of the options about which you inquired are problematic, for different reasons. I would say that if you can't adjust the application code to only include hreflang when the pages really exist, then I think you should remove the hreflang tags from the pages, and instead manually create your sitemap with hreflang implemented there. That means your sitemap would not be perpetually up-to-date. But a slightly out-of-date sitemap with correct hreflang tagging would beat either of the options you listed above.
Yes, this is potentially a serious issue, especially if you rely on the canonical to point multiple versions of a page to a single page for indexing purposes. The canonical URL should have a full protocol, domain, and path. If you're using Wordpress, take a look at the Yoast plugin, for injecting canonical links.
I am currently wrestling with this same question, just slightly different keywords and context. This was a very interesting debate in this thread, so I am hoping I can encourage some fresh perspectives and also perhaps just to check back in after a couple of years now to see if opinions about this have evolved.
In my current situation, I am trying to decide between:
From keyword research, I do understand that nobody is searching for "shop" in their queries. However, the search results when searching for [furniture category] include a lot of different types of results for different intent. For example, when simply searching for the category name, page 1 results include retailers, manufacturers, professional review sites, informational articles, how-to articles, etc. The specific product category is a niche with a lot of information, news, comparative reviews and is a bit of a longer purchase cycle with research.
We've noticed that after performing a few searches in a row, the page 1 results change a bit, seeming to adjust a little to intent (buy vs research vs news)
With regard to prefixing the title tags with "shop", the arguments in favor of that right now are:
On the other side of the argument:
Opinions? Any data?
The Screaming Frog SEO Spider Tool will work great for this. I am not a representative of that company, just a customer. In their paid version, you can include custom searches of any strings in yoru page source code. But even in the standard crawl, you will get reports of links and anchor text, which you can export to Excel and analyze.
While I can't read the language in your screenshots, I can recommend that if those resources are on your own domain, make sure they are not disallowed by the robots.txt file. If they are on external domains, ones which you don't control, then there's really not anything for you to do, and you may as well ignore.
Even though Google does have an international targeting function in GSC, I've had more success with hreflang tags on pages. Technically, hreflang tags can be implemented on each page or in the sitemap, but having experimented with both, I've seen better results from the on-page implementation.
So, I would recommend that you try to implement hreflang tags, in which case you can specify both the country and the language (Ireland would be "en-ie").
Make sure to check the following, when you do:
We used this same approach (except we are not using TLD, but instead are using directory paths for the regions). We have storefronts in US, Canada, Australia, United Kingdom, and EU. The hreflang tags are working very well for all the storefronts except EU.
In these other regions, for all of our key tracked search terms, our ranking page is one within the right region for, when checked by the Moz Rank Tracker using the corresponding Google search engine. And, none of the pages from these other regions are ranking in a Google US search. So far so good.
But, for Europe, only our US pages are ranking when I check with any of the EU country Google engines. And, The EU home page is ranking for some searches in the US, including right now it is showing as one of our organic sitelinks for our brand name search.
We also geo-targeted all of our properties except for two, on Google Search Console. Originally. That would be EU (because Google doesn't allow to target for EU, only for specific countries) and our US site (because we use our www domain in US with no directory path, and in Google Search Console if we geo-target that, it applies to all of our regional directory paths).
So, we changed our geo targeting recently, and targeted our EU property to Germany. We chose that because Germany is our largest market in EU. But this hasn't helped either.
Basically, all the available tools we know of (hreflang tags, GSC geo-targeting) seem to fail at targeting EU. It is a shame, because many brands have an EU site (rather than individual sites for each country). But we have not yet found an approach which works well.
One of the advantages of migrating a blog into a site's structure is outside of the realm of SEO, but can be helpful in making a case to do this. I have migrated several blogs into sections of existing e-commerce sites, as "resource centers". These were not pure migrations, but rather restructuring of the content into pages whcih co-exist with merchandising on the e-commerce site. Here, the advantage is that once a visitor is attracted to a content page on the site, they are more effectively converted into an e-commerce prospect. This is especially true if the blog articles are restructured to include merchandising elements. But even if not, if the only difference is that the visitor is now on a site whose navigation structure includes all of the e-commerce merchandising, they are more likely to convert on such a site. So, the benefit is more about converting customers than attracting visitors.
One way I've tested this is to pick a relatively valuable single page, and migrate just that to an on-site page, with a one-to-one redirect. You will have to wait past an initial period where both of your pages may co-exist in the SERPs. But once the old blog page drops out and the new page comes in, then you can test the longer-term impact. Again, the number of visitors may actually be smaller, but you might more than compensate for that by converting more of those visitors.
If all of the pages you are interested in are linked internally from somewhere in your site which can be reached through navigation or page links, you can run a simulated crawl with a tool like ScreamingFrog, whcih will discover all the "discoverable" pages.
The site you referenced is built with a platform called "Good Gallery", whcih generates a sitemap. This is at www.laskeimages.com/sitemap.xml. I'm not sure what criteria it might use to include/exclude pages, but that would likely be a good list. You will need to view the page source of that page to see the data in a structured way to extract it.
Another method is to use Google Analytics. Assuming that each page of your site has been viewed at least once in its history, you could extract the list from Google Analytics. Especially from an unfiltered view which includes visits by bots.
One helpful strategy with H1 tags is to leave them unstyled in your site's CSS. That way, you can apply an h1 tag to any text element on the page, without altering the visual style.
As far as placement, assuming your H1 contains your targeted keywords for the page, it is to your benefit to use those higher up on the page. Again, if you don't apply any styling to the H1, then it does not need to stand out visually as the heading of your entire site. It is common to have a hero banner at the top of the page, followed by a section underneth the hero, and that is where I usually look to place the H1 text.
In terms of whether or not to include an H1 on your home page, I would say you should. For most sites, the home page is the strongest ranking page, and your best chance to rank for your top desired keyword. I would use everything at your disposal to do so.
In order for your NOINDEX tag to work, the page has to be crawled. So, I would first look and make sure that you do not have it blocked from crawling in your robots.txt. file. I know that sounds counter-intuitive, but you have to allow a page to be crawled in order for the search engines to read and process the NOINDEX tags on that page.
If you are already sure that these pages are allowed to be crawled in your robots.txt file, then the next step would be to encourage them to be crawled, or to temporarily purge them from the index until they are next crawled. The old Search Console UI still has the "Remove URLs" function (and it is hyperlinked form the new search console as well). Use that to temporarily remove the pages, until the next time they are crawled when the search engine can discover the NOINDEX tag.
This may be a little bit outside the scope of the original question, but another use for hreflang tags is when you only have a single language, but localized content in different countries.
So, for example let's say you have web sites/pages in the US and Australia. Both are in English. But you differ the content for each market. In that case, you would use hreflang tags to relate a similar page/site between the two countries. "en-us" and "en-au".
I realize that's not exactly what the original post asked. But adding this info to what has already been answered.
From my perspective, this may be a very good strategy, and not a problem. It depends why you have 4 landing pages though.
I see you linked your site, but I'm instead going to answer more generically, at least in part since I don't read or speak the language of your site.
Let's hypothetically say you sell a type of day planner. And you've optimized your product page for the query "day planner". But you know that your day planner is highly relevant to teachers, personal trainers, doctors, and lawyers. You might want 4 very specific landing pages, targeting phrases like "day planners for teachers", with content on those pages which resonates with and helps teachers to understand how your one day planner would be great for their needs. And a separate page for the personal trainers, and for the doctors, and for the lawyers.
Your product page might rank best for "day planner", but one of your landing pages might rank best for "day planners for teachers".
And I think that's a valid strategy. As opposed to trying to get one page to rank well for all 4 of those audiences, which may also be a valid strategy. I've seen each of those strategies work, in different situations. It very much depends on the competition around your listings, and how they are targeting the audiences (or not), in terms of which is a better strategy (one page with multiple targeted queries, vs 4 pages with individual targeted queries).
So, regarding NOINDEX vs. DISALLOW, there is a significant difference there.
If you disallow in robots, you are asking the search engine to not even crawl that page. Whereas if you NOINDEX in the page head, then the search engine may still crawl the page but should not index it.
There are a few impacts of this difference. For one, if you use NOINDEX but still allow the search engine to FOLLOW, then it may discover pages which otherwise might not have been discovered (if that page has unique links, for example). So in this case, you might prefer to use (NOINDEX, FOLLOW) if you want that discovery to happen. On the other hand, if you have many pages and you are trying to wisely use the search engine's crawl "budget", then you might in some cases prefer to disallow some paths in the robots.txt file.
It's also common to use robots.txt to disallow some files where you do not have control over the response. Non-html files, where you might not be able to easily administer noindex directives. Or dynamic pages your web application may serve but not allow you to administer head tags for.
All of that said, robots.txt files have been shrinking ever since the search engines began to render javascript, since now they need access to a lot of resource files which they previously did not. Much of the old advice of disallowing scripts and admin folder paths may be obsolete now, if those files are needed to properly render pages.
For one, the GSC functionality is much easier to use for dealing with URLs having multiple query string parameters. robots.txt processes the statements in order, so you often have to set up a broad disallow, followed by more specific allows, to achieve the same result which can be more easily managed in GSC.
Also, GSC is useful for the "representative URL" setting, if your pages don't necessarily get crawled without the parameter present at all, but you only want one version of the page indexed if the crawler encounters multiple versions. So, this is a little like a dynamic canonical, except you are not specifying which version.
This is not a definitive response, but my approach has been to canonically relate each paginated review page to the product detail page. My rationale is that I get enough keyword relevance in the first 5 or 10 reviews which show up prior to pagination, to contribute effectively to the ranking of the product page.
Some product review solutions add semantic markup for the reviews, and even though the reviews themselves are paginated, the whole set of reviews is included in the JSON table of reviews on the product page. So, in this case, if yours does this, it might already be getting all the content when it crawls the product page.
I have not been a proponent of separately indexing the review pages themselves. I know there are proponents, and they might have solid arguments why to do that. I have preferred for my product page to get all the page relevance, inbound links, and visits.
You will want to use hreflang, either in the pages or in the sitemaps of the two sites. I'm assuming that you want the pages from the first site to rank for searches in Australia, and the second site's pages to rank in US. And hreflang tags are how you will communicate that desire to the search engines.
The AU site should have a self-referencing hreflang tag for "en-AU" and another hreflang tag for "en-US" pointing to the equivalent page on the sister site. You may also want to include an x-default tag as well.
The US site should have a self-referencing hreflang tag for "en-US" and another hreflang tag for "en-AU" pointing to the equivalent page on the sister site. You may also want to include an x-default tag as well.
And, you also probably want to geographically target the two sites (or at least one of them) in Search Console settings.
Lastly, in case a visitor lands on the wrong site (the search engines don't always obey our directives), you will want some way to inform the visitor that there is a "more appropriate" site. This can be a modal dialog based on geo-ip, or it can be just part of the site design, or however makes sense for your business.
My company currently uses an EU subdomain (similar approach to what you're describing, except varying the subdomain rather than the TLD). But one of the issues we have found is that the search engines have no geo-targeting options for Europe as a whole. They allow to target a single country. Or a single language. Or a country-language combination. But there are no options to target "Europe". So, with hreflang tags, and also with GSC settings, you will experience some challenges because of this. We haven't resolved all our issues, whcih is why I'm not providing a solution to you, but we are far enough in to know it is problematic.
Screaming Frog does have a custom search, which allows you to search for specific text strings in the page source code. You might be able to leverage that function for finding images. They might not be as cleanly inventoried as you want, but at least it would find them and you could use Excel to parse into a neater list. The function is within Configuration > Custom >Search. And in there you use a "contains" filter. Please note that I haven't tried it out for your specific purpose, but I have used this quite often to search the page source for other strings.
You are missing the namespace for xhtml. There are multiple ways to format a sitemap, but you are using xhtml format for your hreflang tags. You can do it differently without using xhtml. But if you do it the way you are doing it, you need to declare the namespace up in the URLSET tag.
So, where you have:
<urlset <span="" class="crayon-h">xmlns</urlset>="http://www.sitemaps.org/schemas/sitemap/0.9">
It would instead need to be like
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns:xhtml="http://www.w3.org/1999/xhtml">
If your current pages can be accessed by http and by https, and if you don't have canonicals or redirects pointing everything to one version or the other, then one very significant "con" for that approach is that you are splitting your link equity. So, if the http page has 50 inbound links, and the https has another 50, you would do better to have one page with 100 inbound links.
Another difference is how browsers show/warn about non-secure pages. As well as any ranking factor they may associate with secure. Again, in favor of redirecting http to https. The visual handling can also impact conversion rates and bounce rates, which can in turn impact ranking.
As far as cons to redirecting, one would be that you might expect a temporary disruption to rankings. There will likely be a bit of a dip, short term. Another is that you will need to remove and then be careful about accidentally adding any non-secure resources (like images) on the https pages, which will then issue a warning to visitors as well as possibly impacting ranks. There is some consensus that redirects (and canonical links) do leak a very small amount of link equity for each hop they take. So, that's another "con". But my recent experiences doing this with two sites have been that after the temporary "dip" of a couple of months, if done properly, the "pros" outweigh the "cons".
In your original post, you wrote that you are a "UK-centric business". I would think you would want to be as specific as possible to make sure the search engines know to serve the most relevant pages to the UK audience. So, yes, I would definitely include a self-referencing hreflang tag. It also simplifies your process because you can just copy-and-paste the hreflang tags between the versions of the page, with no editing (you put the same exact set of tags on the British page as you do on the American).
However, I'm really only responding to your "how" question. There is also an implicit question of whether you should be doing this. I have to say that from recent experience, no matter how thorough we are with hreflang tags, the search engines inevitably serve up pages across the desired locales. For my brand, I have Australian links showing up in US searches, and US links showing up in British searches, etc. This is even with correct hreflang implementation. In our case, it is a necessity to have multiple localized sites, because we carry different inventory, at different prices, and with different policies in each region. But if that wasn't the case, I would not localize my site between US, British, and Australian English just for language variances. That is a subjective decision, but I have so many problems coming from the wrong pages being served in the wrong geographies, despite thorough hreflang tagging, that I would be very hesitant to create more localizations than absolutely necessary. This wasn't your question, I realize, and also this is purely subjective, but passing along for consideration.
You would want the exact same hreflang tags on both versions of each page. So, that means each has a self-referencing tag, plus an alternate tag pointing to the sister page in another locale, plus an x-default tag. The hreflang tags basically tell the search engines whcih version of the page is appropriate for which locales, and when they are on a page in one locale, it tells the search engine where it can find the equivalent pages for other locales, as well as which one is the "x-default" for any locales you haven't specified.
If "ALL" of your pages on example.com are migrating to somewhere on newsite.com, the one approach you could take would be to use the change of address at the domain level, and then set up redirects specifically on newsite.com for each of the old file paths. This would not be relevant if example.com is still going to be around. But if it is going away, then this approach would do what you want.
Yes, that looks correct. However, I would suggest adding two more hreflang tags to each page. One for "en-gb" (pointing to your UK desired version) and one for "x-default" (pointing to whichever version you would prefer for any other nonspecified locales. You will want all 4 of these on each of the two pages (so each page would include a self-referencing tag. These 2 additional ones are optional, but I think would provide a bit more clear direction to the search engines about which page to present for which locales.
Alan,
Spot checking, I looked at a few of your redirected old domain pages which are still showing up in the index. Here are my thoughts: