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

Depending on how many pages you have, you may eventually hit a limit to the number of links Google will crawl from one page. The usual recommendation is to have no more than 150 links, if you want all of them to be followed. That also includes links in your site navigation, header, footer, etc. (even if those are the same on every page). So, at that point, you might want to make that main index page into an index of indices, where it links to a few sub-pages, perhaps by topic or by date range.

In Moz, within your campaign you can go to Links > Top Pages, and then choose the filter "4xx".

To my understanding, GSC is reporting based on "field data" (meaning the aggregate score of visitors to a specific page over a 28 day period). When you run Page Speed Insights, you can see both Field Data and "lab data". The lab data is your specific run. There are quite a few reasons why field data and lab data may not match. One reason is that changes have been made to the page, which are reflected in the lab data, but will not be reflected in the field data until the next month's set is available. Another reason is that the lab device doesn't run at the exact same specs as the real users in the field data.

The way I look at it is that I use the lab data (and I screen print my results over time, or use other Lighthouse-based tools like GTMetrix, with an account) to assess incremental changes. But the goal is to eventually get the field data (representative of the actual visitors) improved, especially since that's what appears to be what will be used in the ranking signals, as best I can tell.

A few bits of feedback:

• I wouldn't be so quick to dismiss Yoast. For Wordpress sites, it's really a pretty good plugin and takes care of a lot of SEO basics.
• Google used to have a specific solution for paginated series, the REL=PREV/NEXT, but that was deprecated about two years ago. Their official advice (albeit through Twitter) was to either treat each page as "standalone" (i.e. self-referencing canonical) or else to include a "view all" type of page with all content accessible without pagination.
• Ideally, when possible, a great solution is to make sure you have enough separate blog "categories" (can be by topic, for example) that each page has all its articles accessible without pagination and then concentrate on getting each blog category page indexed for its appropriate keywords.
• Otherwise, self-referencing canonicals are OK. The main thing is you want each blog article to be discovered, crawled and indexed. So, you don't want to do anything to prevent the discovery of each article. Even if that means that several blog article listing pages end up getting indexed. With this approach, you might even still want to keep (or implement) the rel=prev/next, so that other search engines can use it., and/or for accessibility. Yoast might still be useful for this, as would be some other options like WP-PageNavi

I would recommend to canonicalize these to a version of the page without query strings, IF you are not trying to optimize different version of the page for different keyword searches, and/or if the content doesn't change in a way which is significant for purpose of SERP targeting. From what you described, I think those are the case, and so I would canonicalize to a version without the query strings.

An example where you would NOT want to do that would be on an ecommerce site where you have a URL like www.example.com/product-detail.jsp?pid=1234. Here, the query string is highly relevant and each variation should be indexed uniquely for different keywords, assuming the values of "pid" each represent unique products. Another example would be a site of state-by-state info pages like www.example.com/locations?state=WA. Once again, this is an example where the query strings are relevant, and should be part of the canonical.

But, in any case a canonical should still be used, to remove extraneous query strings, even in the cases above. For example, in addition to the "pid" or "state" query strings, you might also find links which add tracking data like "utm_source", etc. And you want to make sure to canonicalize just to the level of the page which you want in the search engine's index.

You wrote that the query strings and page content vary based on years and quarters. If we assume that you aren't trying to target search terms with the year and quarter in them, then I would canonicalize to the URL without those strings (or to a default set). But if you are trying to target searches for different years and quarters in the user's search phrase, then not only would you include those in the canonical URL, but you would also need to vary enough page content (meta data, title, and on-page content) to avoid being flagged as duplicates.

Yes. As I understand it, hreflang is a page-specific directive. Each page can have different hreflang tags, and this is a very common approach. You could also just tag those single language pages with a self-referencing hreflang tag (EN) and x-default. Those two tags could be on all your US pages, and then add additional tags to the pages whcih have siblings in other languages/countries.

Zack,

My comments were specifically regarding meta descriptions, and the original poster's efforts to make sure their meta description would be used in the SERP snippets shown for various searches. Since a page might rank for many different keywords, not all of those can be in the meta description, and so for some searches, Google is going to instead show page content rather than the meta description. And I don't think this is necessarily a bad thing. For example, if you have a 10% CTR with your own meta description, and a 12% CTR with the one Google is showing, why would you want to try to influence Google to show something else?

So, that's why from a prioritization standpoint, I advised to focus meta description work (and only meta description work) on SERP listings with underperforming CTR. And then, within those, to focus first on listings with more impressions, just because those will have the most amplification of the efforts.

But for other SEO efforts, especially those where ranking factors are concerned (as opposed to meta descriptions which are not ranking factors, at least not directly), then a CTR and impression-based prioritization wouldn't necessarily make sense.

The approach you described seems very thorough and legit for keyword research. But then, as far as what to do with those keywords (i.e. whether to update meta descriptions), that's what I was focusing on with the OP's questions.

You can't 100% control the snippet. Google owns the SERP experience, and in some cases their algorithm determines that content from your page will be a better snippet to show than your meta description. But in general, if your meta description contains the keyword being searched, and an appropriate length of content surrounding that, the chance that the meta description is used for the snippet is higher. Whether that will translate to a higher CTR though is not always the case, and since you can't include every possible search term in your meta descriptions, most of us prefer to focus on ones where we are getting a good number of impressions but not a great CTR. It's a prioritization thing.

Yes, you generally should handle your version 1 URLs and your version 2 URLs to redirect to your version 3. That's assuming that there are still some backlinks out there pointing to your version 1 URLs.

But, a best way to do this is to eliminate the hops. So, instead of having a redirect from version 1 to version 2 to version 3, you would update all the oldest ones so they go from version 1 directly to version 3. And also version 2 would go directly to version 3. That way you reduce your "redirect chains".

It doesn't look like, to me, you have placed your title tag before your CSS includes. This below is from the page source of your first link, as of today. Please notice how there is a stylesheet include, a very large one, before your title tag. I don't know for sure that this is the problem, but I would try placing your title tag before that stylesheet reference.

<html<br>lang=en-US><meta<br>charset="UTF-8"><meta<br>name="viewport" content="width=device-width, initial-scale=1"><link<br>media=all href=https://drliminghaan.com/wp-content/cache/autoptimize/css/autoptimize_de91ffe89d4bc56be7552d25cabc178f.css rel=stylesheet><title>Heart Specialist Clinic Singapore | Cardiology Clinic | Dr. Lim Ing Haan</title></link<br></meta<br></meta<br></html<br>