Welcome to the Q&A Forum

I wouldn't necessarily target the keywords for which you are already getting traffic. The purpose of your snippet is to help your listing stand out from the others around it, so it gets clicks. I would look in GSC for queries where you are getting impressions, and then check how your snippet looks for those, especially as compared with the other listings around yours. As well, I would also look for queries where you have a significant number of impressions, but not a good click through rate. That's another indication that your meta descriptions (or page content being pulled into the snippet) aren't compelling enough. You don't necessarily need for your meta description to be used as the snippet, but you do want your snippet to be compelling so it gets as high of a CTR as possible.

Zack,

All is good with this now. Here's how it actually went:

On January 6, I used GSC to request the cache be removed

On January 7, the page still showed for keyword searches, with the page title, but without any snippet.

On January 7 I requested a re-index.

From January 7-10, the page still showed in search results with only a title

On January 11, the redirected page finally shows in the keyword search results, instead of the original page (desired end result).

So, in summary, it was fairly quick (4-5 days), and in the end the redirected page took the place of the original page, and in the interim the original page showed up with its title but with no snippet.

Thanks Zack. That option is a bit hidden, and I hadn't noticed it. I'm trying now to see what happens with just clearing cached URL until the next recrawl might do. I'm kind of curious what it will do with the page title, which also currently has details about the offer.

We have a promotion landing page which earned some valuable inbound links. Now that the promotion is over, we have redirected this page to a current "evergreen" page. But in the search results page on Google, the original promotion landing page is still showing as a top result. When clicked, it properly redirects to the newer evergreen page. But, it's a bit problematic for the original promo page to show in the search results because the snippet mentions specifics of the promo which is no longer active. So, I'm wondering what would be the net impact of using the "removal request " tool for the original page in GSC.

If we don't use that tool, what kind of timing might we expect before the original page drops out of the results in favor of the new redirected page?

And if we do use the removal tool on the original page, will that negate what we are attempting to do by redirecting to the new page, with regard to preserving inbound link equity?

I'm not sure why the search engine is morphing the page title. One think I would recommend to try would be to move the title tag up to a position in the page source at the very beginning of the head section. It is currently after the CSS source link, and perhaps specifying it earlier might possibly have an impact. Worth a try, I think. But I'm not certain that is the issue.

From my experience, there is not an issue with too many redirects in parallel. However, too many redirects in sequence, or a "redirect chain" definitely is problematic. If a page redirects too many times, the search engine might not follow until the very end.

With regard to redirects in general. On occasion, Google has stated that some small amount rank equity is lost with each redirect. So, we do tend to assume that a direct link is preferred over a redirected link. When we restructure our URLs, we generally clean up all the internal linking to point directly at the new links, rather than rely on redirects. With internal links, that's feasible. With external links, while you can reach out and request link updates, you do also need to rely on redirects.

The meta description is not always used for snippets, depending on what keywords/phrases are searched. When the search term is not in the snippet, but is on the page (and "page" does include elements such as breadcrumbs, top navigation menus, etc.). The search engines will often show the verbiage on the "page" surrounding the search terms. But also, your meta description is pretty lengthy. So you might have better luck with a description in the 100-150 character range.

It does usually take some more time for meta data changes to reflect in SERP listings after a reindex request. If you've manually submitted the page (now that the request reindex tool is back online), and the page is referenced in your sitemap, and that sitemap is referenced in your robots.txt file, and also the page is lined internally from other indexed pages, that's probably all you can do internally. Externally, if you have the ability to link to the page from other domains on pages which are frequently indexed, that might help.

That said, I think there might be some structural issues presenting challenges to effectively crawling your pages. It appears that all of your html of your page is on a single line. I've not seen that before. It might not be problematic, just unusual. As well, the title tag is placed after a lot of other code (like css styling). Generally, the recommendation is to place seo elements like title as high up in the sequence of the head section as possible, so they don't come after any character or time cutoffs. Again, may not be a problem, but the structure seems very unusual. At least worth looking into and maybe experiementing.

This is what they say, explicitly: https://developers.google.com/search/docs/guides/sd-policies. Specifically, see the "Quality Guidelines > Content" section.

In terms of actual penalties, ranking influence, or marking pages as spam , I can't say from experience as I've never knowingly used markup inconsistent with the information visible on the page.

To my understanding, no. Duplicate content generally occurs when two or more pages have very similar content, and the search engine decides that only one of those should be indexed (after crawling each). The concept of "duplicate content" as a "penalty" I think is much misunderstood. There's not actually a penalty, like one would see for a manual action due to spam or hacked content. But rather, if those multiple pages really needed to be separately indexed, then the "penalty" is that only one will be indexed. And, if you don't make smart use of techniques like canonicalization, then the one the search engine chooses to index may not be the one you want indexed. But anyway, none of that really applies in the case you're put forward. As best I can tell from very quickly looking at your site, the pages are unique, and yes, multiple pages might include the same thumbnail(s). But as long as they also include enough unique content besides the thumbnails (and/or don't include exactly the same set of thumbnails as another page), they are likely to be treated as unique pages by the search engine and each indexed. But, you don't need to guess. Just look to see whcih of your site's pages are being indexed. If all the pages you want indexed are being indexed, and none that you don't want indexed, then you don't have a duplicate content issue to worry about.

I would actually address this not as a title tag issue, but as an indexation/canonical issue. Sometimes, the issues which show up in a Moz crawl are actually helpful to identify unrelated issues, and to me, this seems like one of those. Ideally, we typically only want page 1 of our category pages to be indexed, BUT we want all the category page depth crawled (followed). There are several ways to do this. The traditional way has historically been to use rel = prev/next tagging. But there has been some discussion (and acknowledgement from Google) that this is no longer supported. And so another way is with canonical tagging to a view all page (it is not very recommended to canonical to your page 1, but rather to a "all" results page). And another option is to do nothing and hopefully search engines will serve the right page to the right queries. I would research GSC looking at queiries, impressions, and clicks and see if the indexation issue is something needing attention, and if so would probably go with some kind of canonicalization approach.

If I understand the OP's intent, it is to target countries, not languages. Hreflang can specify alternates for a language, or a language-country combination, but unfortunately not just for a country. So, as the OP has proposed, yes you do need to specify the language and the country. And that does bring up a dilema faced by many of us in terms of what language to use. If your content is in all English, then yes you should use like "en-FR". BUT, you might also want to include an "fr-FR" as well, pointing to the same alternate URL. Because there are going to be a lot more France-based visitors on Google whose browser settings are for French language than English. For sure, both do exist (there are native English speakers in France too), but you don't have to choose one. You can include both. Google may not completely respect your directives since the content is in English (assuming that's the case), but it's what I would recommend. So, for each country (assuming the content is in English), include both an English and a language-specific hreflang tag (pointing to the same destination) for that country.

Since your last example uses "es-ES", I assume maybe that you're planning to also publish some content in Spanish language. But if not, again, realize you can include multiple hreflang tags for a single country, and pointing to the same page.

I also don't know where you are based. But if the business is US-based, I wouldn't duplicate US also as a localization. Rather, I would make that the default. Or, if you are based somewhere else, same thing, but with that country.

On question 2, you can set up a GSC property for folder paths (www.example.com/fr/), and target those. I would not target the root level (www.example.com) in your case, because that would also apply to all the subfolders. That's one of the advantages of using subdomains instead of subfolders, is that you can target each independently. But with subfolders, you can target all except the root (because it would cascade downward).

On question 3, you should do the same as you do in number 1, as long as you are duplicating those pages in each subfolder. Otherwise, if you don't give a directive of which page to index, since they are duplicates, Google is going to choose for you. And might not choose the one you prefer.

There are definitely pros and cons of both approaches. I will say that as someone who currently manages 5 different regional variations of a site, no matter how well we implement our hreflang tags and canonical tags, etc. the search engines still don't index us exactly the way we want them to. That has been my experience elsewhere too. In theory, you should be able to maintain two very similar, or even identical sites, and as long as you properly implement hreflang and canonicals, you should be able to target one site to US and the other to UK. But in practice, I've found that even with these things well implemented, you end up with some pages from each site being served as results in the wrong country.

So, I think it depends on how significant that impact is to you. In the case of the sites I currently manage, it is very significant as our product assortment, inventory levels, fulfillment options, etc. are different in each region. So, when a customer clicks through to the wrong region's page, and doesn't follow the suggested geo-ip-based guidance we provide when we detect that, they have a bad experience and we lose customers.

In the case of the sites I manage, it is not an option to consolidate into a single site/page across these regions, because we operate independently in each country with different products, inventory, prices, etc.

If that's the case for you as well, then I would recommend to do your best at properly implementing hreflang and canonicals, and just recognize that the search engines won't perfectly respect your directives for indexation. But if, on the other hand, your business could serve the same content to both regions, you would avoid those indexation pitfalls by consolidating on one domain.

In your case, there is also another factor, which is the perception (in both markets) of the .co.uk domain as being local for UK. So, that helps you in the UK, and hurts you in the US. The .com domain will be better in the US, and not necessarily problematic in the UK, but also would lose some of the local credibility that your .co.uk domain has there. So, that's another consideration.

The SKU property doesn't need to be an official/registered identifier. It can be anything the merchant chooses. It should ideally be unique in your product catalog, but doesn't need to be unique across merchants. So, you can map to it whatever product ID your catalog has assigned. Can even be a simple database row number if needed.

Hi Eric. I took a look at your two pages. When I look at the page source (not with "inspect", but with "view page source"), I see that all of the content on your page is injected via javascript. There is almost no html for the page. To me, this looks like for whatever reason, Google isn't able to execute and parse the content being injected by javascript, and so when it crawls just the html, it is seeing the two pages as duplicate because the body of the content (in html page source) is mostly identical.

That does raise a question of why Google isn't able to parse the content of the scripts. Historically, Google just didn't execute the scripts. Now it does, but they acknowledge that content injected by scripts may not always ben indexed. As well, if scripts take too long to execute for the bot, then again, the content may not be indexed.

My recommendation would be to find some ways to have some unique html per page (not just the script content).

One consideration is how you plan to acquire links and gain relevance. In many cases, one page is a better strategy because you will have twice as many links to the one page, in contrast to splitting half to one and half to the other. For example, you might find better results ranking #1 for at least one of the terms than #5 for both terms. Also, you should be able to rank one page for multiple terms. For example, if you can include both terms in the URL itself, and in the title tag, and within context on the page. There's not a definitive answer to your question, but I would say in general I would prefer one very strongly ranked page than 2 weaker ones (and splitting your product into 2 will usually result in two weaker ones, from an inbound links standpoint).

I'm not sure how the search engines look at 302 redirects which are in place for a prolonged time. I'll be interested to see if anyone else on this thread has additional insights about that. What I can say is that I've used 302 redirects in some cases for prolonged period of time (although not as long as 12-18 months, perhaps more like 4-6 months) and have not experienced issues from that approach. But others on this forum may have more experience with 302 redirects over that period of time.

The other thing I'll mention is that some tools like Moz Pro will report 302 Redirects as "issues". My perspective is to look through these because some might be unintentional, and then to ignore when they are inentional/strategic.

Unless I'm missing something in the thread here, it seems to me this would be better served by 302. My rationale is that you will be eventually going back to the www URL and you want that to retain the full equity of all its links. So, during the interim period, you would have 302 redirects, and then when you switch back to www, you would simply remove all the redirects.

The only downside I see to that is that during the interim period, one thing you won't be able to measure as the site is gradually updated, is the incremental impact of the new page designs on SEO. You will still be able to measure the new page design in terms of conversion rate and other UX factors, but measuring impact on SEO wouldn't really be feasible.

This is because Moz hasn't updated their crawling tool to consider hreflang in the equation of reporting "duplicates". They've acknowledged that. They might update it in the future. But for now, you just have to ignore pages being reported  as duplicate if you know that they are properly linked by hreflang to distinguish countries or languages.

Self-referencing canonical tags are a best practice, and will give an important correct signal to the search engines, which is more important than cleaning up reported warnings in the Moz crawl.

You should stick with two different canonicals. Self-referencing in each case. And use hreflang tags to link the country-specific variations together.

Pointing both pages to one single canonical is telling the search engine to only index one of those pages.

The self-referencing canonical in this case is simply to deal with variations of the base URL, like in case it has query strings, or http vs. https, or www vs not, etc.

Where you would want to point two different pages to one canonical is when you only want one of those pages to be indexed. If the content is duplicate, the search engine would likely make that choice for you. So, including a canonical lets you give a directive to the search engine, instead of deferring to it on the choice of which.