Welcome to the Q&A Forum

That's the staging URL for GoDaddy-hosted sites, Ryan. It likely means that when the site was being developed under the hosting account's temporary URL, it got indexed by the search engines.

It's also possible there's a domain resolution issue on the hosting server. Are there any other pages showing this problem?

The reason its display is broken is because the CSS and JavaScript on the page will be getting called from the wrong URL, so they can't resolve and format the page content.

Paul

I'm not seeing the video there anymore either, Nick.

P.

Knowing that with a large body of documentation like this, the chances of being able to rewrite it all to combine into a single page are pretty slim (and knowing that might be a very negative user experience) you're really only left with the canonical tag option - assuming the older docs need to be maintained.

You're right to be concerned, as Google has been clear that canonical only applies to pages that have substantially identical content. Unfortunately, they do a really poor job of explaining just how much variation would be allowed.

Is it okay if the canonical is not an exact duplicate of the content?
We allow slight differences, e.g., in the sort order of a table of products. We also recognize that we may crawl the canonical and the duplicate pages at different points in time, so we may occasionally see different versions of your content. All of that is okay with us.
~ https://webmasters.googleblog.com/2009/02/specify-your-canonical.html

My impression is that they would honour canonical in your use case.

Really, the only way to know is to select a couple of products' documentation pages and conduct a test. Canonicalise all old version to the current version and request re-indexing for each page. Then monitor the results (The new index monitoring tools in the new GSC are useful for this). You'll want to choose at least one test case that involves featured snippets - it would be incredibly useful to know if the FS transfers across to the new canonical page!

Do note that you'll need an ongoing process for managing the canonicals s each new iteration of documentation is added - all related pages will need to have their canonicals updated to point to the newest each time new docs are published.

Interesting conundrum. Please let us know the results if you decide to try a test!

Is that useful?

Paul

Please don't hijack someone else's question, zecase. Much better if you start your own question as it's completely unrelated to the current one.

Paul

Absolutely do NOT change from the www just for the sake of saving four characters in the URL. It would mean that every single page on your site would now have to go through a 301-redirect.

You should only change URLs when absolutely necessary, and the reasoning for this change certainly doesn't qualify!

Also worth noting - a www URL has more technical flexibility. Those reasons may not apply to you now but could in the future.

Paul

Your understanding of canonical tags is correct, GhillC.

If Tools are showing errors for those canonical tags you've listed, then the tools are wrong.

As long as the protocol and subdomain prefix (or not) exactly match and the only difference is the exclusion of the parameters (the "?" and the stuff after it) then the canonicals are correct.

Any tool's reports have to be filtered through your own understanding and knowledge. They often get things wrong. That's on eof the key differences between experienced SEOs and less-experienced. They kow when to question what an automated tool is telling them. So good on ya for questioning the results!

Paul

Another +1 for Screaming Frog's Log File Analyzer. (It's a separate tool from their superb Crawler tool.)

Paul

Direct traffic isn't a ranking factor, VT. There's no way it can be, as it would far to easy a signal to fake and abuse.

Paul

A proper canonical tag does a lot more than "just be telling Google not to rank it" When used properly (i.e. pages that truly do contain the same content), the canonicalised page passes its ranking signals back to the canonical source.

I agree with Kristina - while a 301 would be preferable (it's a directive, while canonical tags are taken as suggestions), a canonical tag would be vastly better than not doing anything about the issue. At least until the dev can get the problem with the 301-redirect properly resolved.

Paul

My suspicion would be that those URLs are accessible somewhere without the second variable. (I.e. That second variable isn't always present when the first variable is.)

I'd absolutely agree. If you can get it fixed properly in a couple of months, then leaving the status quo would e better than making interim changes that just trade one set of redirects for another.

P.

Quick thing to check - have a look at your server logs. Those kinds of random load time increases look typical of the load spikes that are typical of bot overloads - where spambots may be hitting your pages in bursts, causing the server to overload and slow (or even reset, as Vijay mentions).

Those bot hits aren't recorded in GA - you'll have to look at the actual server access logs to find them.

Hope that helps?

Paul

Honestly? I'd spend the time to get the Custom CMS fixed to allow trailing slashes in the navigation links. That would eliminate the redirect issue, Instead of just trading it off to another set of links that would have to redirect.

It sounds like a code sanitising issue in the CMS. Worth spending a couple of hundred dollars to fix the root cause of the issue instead of spending that money to apply bandaids that cause other problems elsewhere. (And bonus, maybe you can get proper canonicalisation built at the same time.)

Of course, yea, this does depend on having/finding a competent developer and having a test environment that doesn't endanger the live site.

Any chance you could push for this option?

Paul

Those comment links are almost certainly already no-followed, Nikki. So not much point in worrying about disavow at this point.

Also - the fact that AHREF seems to be rediscovering them just means their own crawler data may have changed. Doesn't likely reflect any change in Google's awareness and understanding of those links.

Hope that helps?

Paul

My answer above applies specifically to your situation too, @Elchanan. You are not being penalised by Google for duplicate content in your example.

As I mentioned, the root of a domain is a special case. The version with the slash at the end is considered the same URL as the one without the slash by both browsers and search engines. So much so that it is impossible to redirect from one to the other because that creates a redirect loop - the page is redirecting to itself.

If that SEO tool has warned you of that issue, it's because the tool isn't properly programmed to handle this unique situation correctly.

Hope that helps.

Paul

You can do this in Google Search Console too, without needing any other tools. It will give you the average ranking position, which has some advantages and disadvantages over the other tools' reports.

Screaming Frog also has a basic, useful site visualisation capability built into it.

If you set up a reverse proxy properly, the search engines will treat the content in www.website.co.uk/blog/ as normal content on that main site.

It's not trivial to set up, but it's designed for specifically this kind of scenario (e.g.  a subdirectory displaying content using a technology that can't be installed on the main-site server.) You'll also want to make certain things like cookie persistence, Analytics etc have been accounted for.

Hope that helps?

Paul

That nofollow link only applies to that one specific link, dk. The site is using a special service to help create a printer-friendly version of the page for those that might want to print out the content. Quite correctly, they've nofollowed that one particular link.

The website's own page URL only appears in the external link to the printfriendly site because it is a parameter that needs to be passed so the print site will know what page to provide the printout of.

So no, that nofollow definitely does NOT apply to the whole article.

Make sense?

Paul

You have Screaming Frog - it has built-in functionality for just this situation. The whole point is you need to be crawling the old URLs, no the new site.

Configure Screaming Frog to operate in List mode by clicking Mode > List in the top nav bar.

Then feed it the csv file of all the old site's URLs. (It can also work off an old xml sitemap) Click the Upload button to specify the list file to upload.

Then tell it to crawl that list of the old URLs. The result will be a report of all those URLs and which URLs they redirect to, along with the status codes. So you just need to look for the ones that still 404 and you'll know which ones still need redirects. You can also easily see unnecessary redirect chains in this report as well.

Make sense?

Paul