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

Canonical tag isn't likely to have the effect you want here. Search engines expect (require) that conicalised pages be essentially identical to each other or they will likely ignore the canonical "suggestion". Identical meaning essentially word for word, except for perhaps word order, like on parameter-sorted product category p[ages.

In my experience, EGOL's solution is vastly superior. Create a permanent page for each, then find all the old related blog posts and redirect them to the permanent page to harness whatever authority those pages have for the new one. That way all further authority to the same page year after year, instead of being diffused amongst many weak separate pages.

Paul

Maybe I'm missing something? You can implement an htaccess rewrite rule (or equivalent for your server stack) using regex/host so that essentially
http://example.com/foo OR https://example.com/foo redirect to https://example.com/bar That's the standard approach and serves in one hop. Is there something I'm missing why you're getting into a load balancer etc to accomplish this?

P.

Referrer data is stripped when the referral is coming from HTTPS to HTTP. That's a security measure that Google has had in place for some time. Because the link is hitting the HTTP first, it is negotiating its initial connection over an unsecure channel, so the referrer is being stripped. (The incoming connection is being initiated over HTTP before it is ever able to detect and process the redirect.)

So yea, expected behavior. One way around the issue that I'm pretty sure would work is if you implement HSTS for the receiving site. That forces the initial connection over HTTPS regardless of the incoming request's protocol.

Hope that helps?

Paul

Definitely use option #2. There's no reason to have to maintain a server presence for the old site if it's been replaced. This is best practice - still fully allows ranking authority transfer to new domain.

Yes, it's a lot of work to do the redirects. Watch for cases where large numbers of URLs are the same, with just the domain name changed. Or that all have similar change required (e.g. removing a /category directory) Those can be handled with a single regex rule instead of having to create an individual redirect for each.

To ensure you catch as many of the old URLs as possible you can use the Screaming Frog crawl as the list of URLs needing redirects. Can help to merge that with with the old site's XML sitemap for completeness. Note - you'll have to redo the redirects from the plugin as well, as those will no longer work after the DNS is pointed to the new domain.  Check the old site's htaccess for an legacy redirects as well. It's usually also beneficial to redirect the images and other important media (pdfs and other downloadable files) if you can.

Then set up a process to monitor Google Search Console and Google Analytics on the new site to immediately detect and correct any new 404 errors that show up. (That's another major advantage of doing the redirect on the new site's htaccess - the 404s will actually be detectable with tools.)

Lastly, ensure you've used the Change of Address tool in Google Search Console to notify Google that the old site has moved to the new domain. Keeping the old site verified in GSC will allow for this, and will let you monitor the drop-off in indexing of the old site as Google recognises and indexes the transition.

Hope that all makes sense?

Paul

The approach you're using is correct and no, you're not really adding an extra step. That's not how canonical works.

A canonical is not a redirect like a 301. It's just an instruction (suggestion actually) to ignore the URL variables when determining the URL of the page. It will have zero effect on the transmission of the ranking authority through the 301-redirect.

The challenge you will have though, is if you create your own UTM tag to generate the source of the visit as being from the old domain1's 301 redirect, it's going to overwrite ALL the other source/medium info from the original site's visit. So domain2's Analytics isn't going to record the source of the original site1 visit as social, organic, referral etc. All redirected visits will get whatever source/medium you designated in your UTM tag.

It may be possible to programmatically catch the original traffic source on domain1 and programmatically write the UTM tags to include it in the 301, but I wouldn't know how to suggest trying to go about it.

Paul

I'm not seeing a problem in my GoogleBot simulators, Becky, but the one within your Google Search Console is still the best judge. Have you tried reloading the Fetch as... a couple of times? And tried it on different pages?

Yup - Google still says content that can only be seen after a user interaction is given less importance. Kinda stupid, given that things like tabs/accordians are a major usability enhancement, but that's still where we are.

P.

Lazy load and infinite scroll are absolutely not the same thing, as far as search crawlers are concerned.

Lazy-loaded content, if it exists in the dom of the page will be indexed but it's importance will likely be reduced (any content that requires user interaction to see is reduced in ranking value).

But because infinite scroll is unmanageable for the crawler (it's not going to stay on one page and keep crawling for hours as every blog post rolls into view) Google's John Mueller has said the crawler will simply stop at the bottom of the initial page load.

This webinar/discussion on crawl and rendering from just last week included G's John Mueller and a Google engineer and will give you exactly the info you're looking for, right from the horse's mouth, Victoria.

To consider though - the blog's index page shouldn't be the primary source for the blog's content anyway - the individual permalinked post URLs are what should be crawled and ranking for the individual post content. And the xml sitemap should be the primary source for google's discovery of those URLs. Though obviously linking from authoritative pages will help the posts, but that's going to change every time the blog index page updates anyway. Also, did you know that you can submit the blog's RSS feed as a sitemap in addition to the xml sitemap? It's the fastest way I've found of getting new blog posts crawled/indexed.

Hope that helps!

Paul

Cindy, this is almost certainly an issue with the way your Google Analytics is configured, not your WP site. (the fact the "index.htm" comes after a "/" is the clue.

If you check the View Settings link under the View in the Admin section of your dashboard, you'll find a field called Default Page. For most correctly configured modern sites (WP sites included), this field must be empty for GA to be configured correctly. I'm betting your config has index.htm entered in that field. [See screenshot below.]

Once you remove that entry, your data will avoid the problem going forward, but it will take some work with custom filters if you want to try to clean up the historical data.

Let me know if that solves the issue?

Paul

rOLe0

While theoretically logical, Google's own John Mueller stated last week that code to text ratio has absolutely no effect on crawling of a site, and in a followup question, he directly told me text/code ratio has no effect as a ranking factor either.

These used to be very minor considerations back when the search engine crawlers weren't as powerful, but no longer.

Fully agree with Pia that the idea of "above the fold" influencing ranking is nonsense as well. Given that the sweet spot for consistently high-ranking pages is ~2200 words, the idea that only the first paragraph or two are more important is unsupportable.

Hope that helps?

Paul

Still have a major problem though! The www and non-www of the https versions of the site are both resolving separately, which means you're badly splitting your link equity. That's also likely why different sites are linking to different URL versions. Need to get the non-canonical version 301-redirected poste-haste. (Make sure you haven't created chained redirects in the process.)

You'll also want to combine all those versions of the site in a Property Set to properly amalgamate their data. Property Sets will treat all URIs from the properties included as a single presence in the Search Analytics feature.

Hope that helps?

Paul