Welcome to the Q&A Forum

Although the impact of keyword match in domain names isn't as high as it once was, my current experience is that it still is a very significant ranking factor. I've recently (last year, and also about 4 years ago) completed two domain name changes, and the impact on searches where the query term is/was matched in the domain name definitely has an impact. That said, after an initial "honeymoon" period, you're likely going to see some negative ranking impact of a domain name change, regardless of the specific domain names. My recent experience has been that things get crazy for a week or so, then look really good for 1-3 months, then the negative impact hits, and then it takes quite a while (sometimes more than a year) to get everything back to where it was. So, if you do change domain names, it needs to be seen as a long-term strategy, not a "this year" one.

Yes, I meant 301, server-side redirects.

Regarding performance, I currently have a little over 50,000 entries in my redirects file with no discernable performance impact. But, different platforms handle differently, and also we have a CDN which caches redirects too, so that could make a difference. I guess the safest approach would be to insert a hundred thousand or more dummy redirect entries into your redirect file, temporarily, and stress test it.

Th approach of redirecting with an informative message is potentially a good one. I have not implemented nor seen this done. If you go this route, make sure it is a true server redirect, with a 301 response code. But I could see how the redirect could include a query param in the destination URL which could then be used to display a fairly generic message.

As far as better vs. worse, from my perspective that differs depending on the nature of the products. One good use case for keeping the old product page around would be like a consumer electronics product page which contained technical info or resources which would be hard to find otherwise (but an alternative could be to have a support library for that). Another example, when I was on the agency-side, I worked with an apparel brand which each season introduced and retired thematic prints. And they kept a library of retired prints, which visitors could upvote to try to get them returned into service.

You wrote in your OP that these pages are zero/low traffic, with few backlinks. So, I'm inferring that the actual user experience isn't going to be really experienced very much.

But the reason to redirect to the category page, is to preserve any link equity the product page might have built up over time. Again, even if each product has very few backlinks, if you add them all up redirected to a parent category page, that could make a difference in how that category page ranks. If you can accomplish this without confusing real visitors (if any).

To your last point, yes it's possible that the search engine might consider some of these redirects to be "soft 404s". In which case, the link equity wouldn't be preserved because it would be treated like a 404. But, that's exactly what you're proposing to do anyway. So, if even just some of them get treated as 301s, you're ahead of the game, as I see it.

If you are keeping them, rather than redirecting them, I assume that means you have a reason for people to be able to find those pages so that they can get some information abot the discontinued product, or at least understand that it was discontinued. If that's the case, then I don't think you would want to noindex or 404 them. On the other hand, if there is no reason for those pages to still exist, from a visitor standpoint, then usually I would redirect them to a category page (generally the parent category the product belonged to), to preserve any link equity, even if the number of links are low. Especially if you have a lot of discontinued products from a category, even if each product had let's say on average 0.1 links, then if you have 1,000 of those pages you would end up with 10 backlinks to your category page, which could be valuable. Again, this is assuming that you don't want/need to preserve the pages for your users to be able to find the info.

I don't believe there is any reason to wait for an algo update. Especially if your new site has improvements which could help your CWV scores. Google states that they will be using "field data" (from real users, not bots) over a 28-day period to assess CWV. So, if your new site is going to score better, you would want to build up those scores now. That said, if your new site is going to score worse than your current one, you might do well to fix it prior to launching it. There are plenty of tools (both lab data-based and field data-based) to assess your old and new pages. Page Speed Insights is helpful for public-facing pages. Whereas for not-yet-public pages, you might need to resort to using the Audits tab of Chrome Dev Tools, or other tools which allow for authentication, etc.

Here are a few resources you might find helpful:

To request removal: https://support.google.com/legal/troubleshooter/1114905

After content is removed: https://search.google.com/search-console/remove-outdated-content

To my understanding, a redirect and a canonical are treated very similarly from an SEO standpoint. With either of these, only the end URL (either the one to which you are redirecting, or the one linked in the canonical reference) is the one which, if all directives are honored, gets indexed. So, unless I'm missing something, there is no benefit at all of having the category paths in the URLs if you are either redirecting from those to the flat one, or if you are pointing a canonical to the flat one. The benefit would be there if those keywords were in the final URL (redirected or canonical). But if the final URL is flat, then I don't think you get any benefits from the non-canonical URLs having keywords in their paths. So, if the flat URL is the final one, from either method, I would ensure that the "product name" is fully descriptive with the desired keywords.

The benefit of the directory paths approach is the additional keywords, if your product name (or ID) is not in itself descriptive enough. For example, if you have a sofa style named "Diana", you wouldn't want your URL to be domainname.com/diana.html. Something like domainname.com/furniture/sofas/diana.html would be better.

But, you can accomplish that with more descriptive product IDs. So, in the example above, if you could make your product name "furniture-sofas-diana", then your URL would be domainname.com/furniture-sofas-diana.html, which accomplishes the same keyword targeting.

And then that solves the issue of when products are in multiple categories, since it's a flat URL regardless of how the visitor arrived to the page.

But if your products are really almost entirely in a single category each (keeping in mind temporary categories like "sale", "new", etc.), and they will be that way forever, then there is an argument to be made for the paths. Because it does help the search engine to parse up your site, and to provide nice breadcrumbs on your listings.

This is really a perennial debate. And there's no one answer. For most of us, we do have to live with products being in multiple categories, as the norm (especially when considering categories like sale, new, best sellers, etc.). Canonical reference links help this issue, but aren't necessarily ideal.

But, what really struck me in your question was that you said the URL changes when you click on the product. Ideally, you don't want all your internal links to be redirects. That's something I would try to avoid.

Nick,

I went to that wiki page, and clicked through the link. While the page does redirect to a page which contains content stating "404 Page Not Found", in actuality that page is giving a 200 response, not a 404. In order for any broken link reports to work, the page would have to actually return a 4xx response code (404, 410, etc.).

Here is the redirect path log from the Ayima plugin:

Status Code URL IP Page Type Redirect Type Redirect URL
301 http://www.africatravelresource.com/africa/tanzania/c/zanzibar/nungwi/ 104.26.7.235 server_redirect permanent https://africatravelresource.com/africa/tanzania/c/zanzibar/nungwi/
200 https://africatravelresource.com/africa/tanzania/c/zanzibar/nungwi/ 104.26.6.235 normal none none

In preparation for Core Web Vitals becoming a ranking factor in May 2021, we are making efforts to reduce our Cumulative Layout Shift (CLS) on pages where the shift is being caused by images loading. The general recommendation is to specify both height and width attributes in the html, in addition to the CSS formatting which is applied when the images load. However, this is problematic in situations where responsive images are being used with different aspect ratios for mobile vs desktop. And where a CMS is being used to manage the pages with images, where width and height may change each time new images are used, as well as aspect ratios for the mobile and desktop versions of those.

So, I'm posting this inquiry here to see what kinds of approaches others are taking to reduce CLS in these situations (where responsive images are used, with differing aspect ratios for desktop and mobile, and where a CMS allows the business users to utilize any dimension of images they desire).

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".

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">

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.

In preparation for Core Web Vitals becoming a ranking factor in May 2021, we are making efforts to reduce our Cumulative Layout Shift (CLS) on pages where the shift is being caused by images loading. The general recommendation is to specify both height and width attributes in the html, in addition to the CSS formatting which is applied when the images load. However, this is problematic in situations where responsive images are being used with different aspect ratios for mobile vs desktop. And where a CMS is being used to manage the pages with images, where width and height may change each time new images are used, as well as aspect ratios for the mobile and desktop versions of those.

So, I'm posting this inquiry here to see what kinds of approaches others are taking to reduce CLS in these situations (where responsive images are used, with differing aspect ratios for desktop and mobile, and where a CMS allows the business users to utilize any dimension of images they desire).

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.

Yes, your understanding of x-default is correct. The purpose of including it everywhere you have alternate HREFLANG links, is to handle any locales you don't explicitly include (to tell the search engine which is the default version of the page for other non-specified locales). And it should be included on each version of the page, along with the other specified alternate links for each locale. Alternatively, you could collect all of these centrally into the sitemap file, rather than inserting into each page. Both types of implementation are valid (but anecdotally I've had better luck with on-page tags instead of sitemap implementation).

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 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.

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.

I currently manage a site which is localized per region, as opposed to country. For some regions, like US and Australia, it is 1:1 with country, so we do not have issues there. But for Europe, that is where we do have some issues currently. We took the following approach (below), but I have to first say that it is quite problematic and has not performed very well so far (implemented about 1 year ago).

The approach we took was to implement HREFLANG within our sitemap, and for Europe, we generate specific alternate locations for each of the countries where we do business in that region, all with the same URL. Here (below) is a redacted version of one page's LOC node in our sitemap (I've only included a partial list, and only showing English, as the full list of alternate URLs for this one LOC has 150 alternate links to cover every EU country x 5 languages we support). But, the general approach is that for Europe, we create one alternate link for each EU country, in each of our supported languages (we support 5 languages). So, we don't assume, for example, that German speakers are only in Germany, or that English speakers are only in the UK. We cover every country/language combination and point many of these to the exact same alternate link.

Again, as I mentioned, this hasn't achieved all we had hoped. But sharing the approach for a reference point here, as an option, and open to any other ideas from the community. We also struggle with EU in terms of Google Search Console geographic targeting. Unfortunately, Google does not allow a property to be targeted to "Europe". And they only allow one single country per property. In our case, we really need to target a single domain to "Europe", not to a specific country. But we can't, and that is a problem currently.

Here is the example from our Sitemap (partial cut-and-past of the first few entries from one URL node):

<loc>https://www.example.com/example-page-path</loc>

<priority>1</priority>

... remainder of alternate links removed to shorten list here

|   |