Welcome to the Q&A Forum

ASs joe says - set up a separate GSC profile for the mdot subdomain. The use that to submit the mdot sitemap directly if you wish. You'll get vastly better data about the performance of the mdot site by having it split out, instead of mixed into and obfuscated by the desktop data.

Paul

There's no reason to keep the old hosting just for the redirects. And that introduces a real weak point as at some future date, someone who doesn't realise it's still running only an htaccess file will delete what they think is unnecessary hosting.

Instead, use DNS of the old domain to point it to the new domain and then write the redirects in the new domain's htaccess.

Paul

P.S. And yes, you'll need to write redirects for each old URL that changes. If there are patterns of URLs, it's worth using regex to cut down the number of redirects written.

You need to ensure that the HTTP version of the site's URLs are no longer reachable, Ruth. That means adding a 301-redirect to force all URLs to their HTTPS versions. This is the most likely cause of your issue

To test, simply go to a page URL in the browser address bar and remove the s from the HTTPS and hit enter. Watch what happens. If the address bar shows the automatic change back to the HTTPS version of the URL, you're good. If it doesn't, you'll need to add the redirect.

You should also ensure that all the internal links within the site have been rewritten to use the HTTPS version of the URLs - like menus, sidebars, widgets, and in-content links to other pages.

Hope that helps?

Paul

Since this is essentially a duplicate of your earlier question, I've answered it there.

https://moz.com/community/q/text-hidden-in-tabs-on-desktop#reply_381047

You'll need to inspect the site's server logs to begin narrowing this down, Jens.

Causes can range from traffic overload (like from bots, which won't show in your Analytics)  to database problems, plugin conflicts etc.

Nope. The use of page speed as a (minor, and very specific) ranking factor doesn't work that way. Never has.

Page speed only applies to a small percentage of search queries and it's used as a disqualifier for really slow pages (think over 15 or 20 seconds). Meaning if your page is really slow compared to your competitors, their page will likely be preferred over yours. But small incremental improvements in page speed won't result in ranking boosts. (And Google's on record as saying that even slower pages will earn SERP results if they're content is significantly better for the user's query.)

Improve page speed for the usability of your site, not because a small incremental speedup will change rankings.

Hope that helps?

Paul

Yup - you have to use the actual URL of the sitemap for submission. The search engines will handle it fine - as you can confirm by watching in GSC and Bing Webmaster Tools that it's getting processed.

Paul

P.S. There's really no particular benefit to using a compressed sitemap anymore.

This is an incorrect implementation in the BeamUsUp tool. The hostname (the basic root URL) is a special case. Both the version with the ending slash and without the ending slash are considered by browsers and search engines to be exactly the same.

In fact, you cannot redirect one to the other. Because the browser is programmed to consider them the same, you'll create an infinite loop. So not only is there nothing you should do, there's nothing you can do.

This is the only case where this is true though! For all other internal URLs. the version with the slash is considered to be a completely different URL than the one without the slash. So unless you redirect one version to the other for internal pages, you'll have duplicate content issues.

Hope that helps.

Paul

Good Choice. The XML Sitemap spec has specific maximum sizes for individual sitemaps, but they are specified sizes before compression, so compression doesn't get you around the size limitations anyway 

P.

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

Not really correct, unfortunately. As long as the 301 redirect has been written properly (it should be at the system level, not written into individual page code like a JavaScript redirect) then any request to the server for the page will be redirected before the old page can be reached. That's the express purpose of a 301-redirect.

So anyone clicking on an external link to the old URL (or a search crawler following it) will immediately be redirected to the new page as soon as they hit the server, whether the old page still exists or not.

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

Doing redirects in JavaScript is definitely a "better than nothing" solution, rather than anything that should be recommended. It means placing your trust in something in that is supposed to work work, as opposed to something that definitely will.

I'd make sure there really was no way to do the redirects properly first, before falling back to the last-ditch solution.

Here's a test from a year ago that showed ranking authority was passing through JS redirects, but note all the caveats they include (especially that Bing didn't handle this at all at the time).
https://www.branded3.com/blog/seo-javascript-redirects-evidence-pass-pagerank/

Hope that helps?

Paul

Nope, no effect, as you suspect, Eddie. That kind of attempt at copy-blocking doesn't change the way the content is available in the DOM of the page (which is why it's so ineffective) so has no effect on crawling/indexing.

You can prove this for yourself by going to a page and right-clicking to select the browser Inspect mode. This mode shows the actual rendered DOM of the page that the search engines are reading, and you'll see the content is easily accessible. The other option is to do a Fetch and Render request from within the site's Google Search Console and it will also show you what content Google can see.

That what you were looking for?

Paul

Nice catch & very likely the problem.

There is rewrite code to do that in one "hop". But the best practice for this has changed from what the pagespeed tools recommend, Fitz. You should actually leave the redirect as is, and insure you have HSTS properly implemented for the website. For HSTS to work properly/securely, the site must redirect to the HTTPS version of the same hostname before then redirecting to the canonical hostname. Which is exactly what your site is doing.

The only disadvantage to the extra hop is that there's a very small delay for an additional server calll, but the implementation of HSTS eliminates a server call and some certificate negotiation time. So breaks about even or even a little quicker, especially if you submit to the Preload list once you're certain HSTS is working correctly. Note that HSTS should be implemented using a very short TTL initially so you can be sure things are working correctly before switching to a long TTL and the preload list.

Do you already have HSTS configured for the site??

Paul

As Red mentions, you're actually hosted on WordPress.com, not .org (which is the self-hosted version of WP)

To resolve the specific error you're asking about...

It's telling you that to be able to use the custom code features that are available, the settings for your domain name at your registrar should be pointing to the nameservers at WordPress.com, not the nameservers you're currently using (likely the registrar's own nameservers).

Hope that helps?

Paul

This is the kind of question that cause a lot of wasted tail-chasing if we can't inspect the affected URL, Nadav. Can you give us a link to the site in question?

Paul

Yes, Google's been quite clear that once a site is in the mobile-first index, the content that only becomes visible on user interaction will no longer be discounted the way ti is now. But remember, the mobile-first index is slowly being rolled out on a site-by-site basis. So you'll need to do some specific investigation of your own site to know whether it has in fact been moved to the new indexing method.

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