Welcome to the Q&A Forum

This is most commonly referred to as a Rich Snippet resulting from structured data markup, in my experience, @hartator.

Sorry - I missed the part about you looking specifically at the Moz crawler. While useful, it's a stand-in for what will actually be used for rankings - namely the actual crawls by the search engine crawlers themselves. I'd be looking right to the source for that info if you're concerned there's an issue, rather than trusting just Mozbot. You can find the SE crawlers data in Google Search Console and Bing Webmaster Tools. Look for trends and patterns there, especially around the sitemap report.

The challenge to a Screaming Frog-rendered sitemap is that it can only find what's linked. If the site has orphaned pages or an ineffective internal linking scheme, a crawl could easily miss pages. It's certainly better than no sitemap, but a map generated by the site's technology itself (usually the database) is safer.

P.

Google has said that when they find the same page under both HTTP and HTTPS, they will try to return the HTTPS page in search (certain circumstances ap[ply). But the fact remains that you are making the search engines "figure it out" instead of giving explicit directives that ensure the correct behaviour.

I suspect the HTTPS split has already done its damage, especially with regards to backlinks now pointing at two destinations and thus splitting the authority. Which is likely the cause for your suspicion of the underperforming backlink profile.

So the process of getting the HTTP dupe resolved to HTTPS with the redirect should start delivering improvement as soon as the new crawling/indexing gets done. I strongly suspect this improvement will offset most if not all of the effect of the new HTTPS redirects.

There's no way to estimate the effect of the addition of the proper HTTPS redirect, but given that you're already in a compromised hybrid state, my strong suspicion is that it will actually improve the situation without much temporary drop at all. In essence, you've already experienced the negative pressure. The changes will serve to start to reduce the negative pressure immediately.

But this is my best assumptions. I haven't done an HTTPS redirect correction on such a large site. On the smaller sites I've fixed though, the uptick happened within a week or two. Though not dramatic improvements still beneficial.

The other thing to be aware of: Google has stated that when they do the reindexing to HTTPS, it's essentially like recrawling a new site. So they apply all the tests and quality checks to all pages. So if you have existing issues to clean up, do that before final implementation of the HTTPS redirect.

I'd be really interested to follow your results on this - sounds like a solid opportunity for a case study!

Hope that helps;

Paul

It was still a good idea to create the redirects for the upper-case versions to help cut down duplicate content issues. Rel-canonical "could" have been used, but I find it's much better to actually redirect.

But that means the lower-case URLs are the canonical URLs, so ONLY they should appear in the sitemap. (Sitemaps aren't supposed to contain any URLs that redirect.) Right now, you're giving the search crawlers contradictory directives, and they don't do well with those

For additional cleanup, it would be good to have rules added to the CMS so that upper-case URL slugs cannot be created in the first place. Also run a check (can probably be done in the database) to ensure that any internal links on the site have been re-written NOT to use the uppercase URLs. there's no sense generating unnecessary redirects for URLs you control. (I suspect this is the majority of the cases that Screaming Frog is picking up.) You need to ensure all navigation and internal links are using the canonical lowercase version.

The more directly the crawlers can access the final URL, the better your indexing will be. So don't have the sitemap sending them through redirects, and don't let your site's internal links do so either.

Hope that helps?

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.

Do you have rel-alternate markup in place for the separate m. URLs?

You're ruining your site's usability for no reason, unfortunately. Google doesn't care about the bounce rate on your site as ranking factor in the example you have given (specifically because it is so trivial to manipulate as you are doing, for one reason). For many users, encountering this kind of behaviour on a site would be a major security.spam signal.

If you want to better understand your visitor behaviour on single-page visits, you'd be far better off to implement event tracking on your external links. You could even set the event to "interactive" so it would no longer register as a bounce visit if that's useful to your Analytics plan, but again, just manipulating the bounce rate does absolutely nothing for ranking purposes.

Hope that helps?

Paul

In general, shoving a press release up onto a press release directory doesn't give you any backlinks of any value. Search Engines are fully aware that these kinds of links are self-generated and don't give them much, if any authority. In addition, most such services no-follow those links. And even if the release does get distributed beyond the PR directory, it will still have those no-follow links, and will clearly be duplicated content so unlikely to have any authority of its own to pass on.

The only way press releases provide real value is if there is something truly newsworthy for you to "release" and you put in the effort to pitch the information to real relevant news sources so that they actually write about it instead of just copying the release and slapping it up on a page.

The fact others are doing it doesn't mean it's a worthwhile thing to pursue. It's an approach from the old-school manipulative SEO days that hasn't worked for a long time, but so many sites are still looking for easy things to checkmark off their to-do list ("get 10 new links") instead of putting in the hard work to do things that will actually have an impact.

Hope that helps?

Paul

Search Engine crawlers don't pay much attention to HTML sitemaps - they're considered thin/worthless pages with no real value, since they're just a huge collection of links with no context.

Build them so they are useful and relevant for a human visitor, or just make sure your site navigation and internal search is well-thought-out and drop the HTML sitemap altogether (which is my strong recommendation).

Paul

No - submitting a sitemap won't reduce the crawl of a site. The search engines will crawl the sitemap and add these pages to the index if they consider them worthy. But they'll still also crawl any other links/pages they can find in other ways and index those as well if they consider them worthy.

Note though - having the number of indexed pages drop is not necessarily a bad thing. If removing a large number of worthless/duplicate/canonicalised/no-indexed pages cleans up the site, that will also be reflected in fewer crawled pages - an indication that quality improvement work was effective.

That help?

Paul

The semantic purpose of a header tag is to mark a collection of words as a header introducing a section of descriptive content. If what you have instead is a series of headers with no content in between, you're defeating the purpose. There's no "reason" to mark those list elements as headers. If you're using

because it's an easy way to create the styling for those terms, you should get out of that habit.

There's no major damage done by having headers follow each other, but there's no real benefit either. And for what tiny value those headers bring for helping search engine crawlers better understand your page content, you've thrown that away.

In other words - don't do it.

Hope that helps?

Paul

This is a classic case where rel-canonical should be applied. The two URLs are identical except one has had a query string added. By including a self-referential canonical tag on the main URL, it will automatically catch the same URLs with query strings added.

This will help avoid a situation where someone gets to the guest house page via the internal search tool and links to it, but the link is wasted because the page is no-indexed.

As far as internal links - they are reported in Google Search Console in the Search Traffic section and are a general way to assess whether your internal link scheme is appropriately linking to the most important pages, but it doesn't measure clicks.

Internal link clicks are not a ranking factor - but should that matter? You should be optimising them to generate more engagement with your site's content regardless, yea?

Wow - sorry this question slipped past, Ruth.

As long as the proper HTTP redirect has been written to HTTPS, there's nothing that needs to be done with canonical tags.

The beauty of 301-redirects is that they are server directives - once in place, its no longer even possible to reach the non-HTTPS URLs. The HTTPS URLs should of course still keep their own self-referential canonical tags, but that's handled automatically in most CMSs (Content Management Systems like WordPress.)

Hope that covers what you were asking?

Paul

Google tries to index the rendered page, not the raw page code. The best way to see that page as Google sees it is to use the Fetch and Render tool in Google Search Console.

Alternately, you can use the developer tools in Chrome or Firefox to show the rendered version of the page code. Right-click in an area of the page you wish to view, and then select Inspect. This will bring up the inspector which will show you the rendered page code close to how Google sees it. (Google uses Chrome V42 for indexing, while the current version of Chrome is 62 - so you're not necessarily seeing exactly what G is seeing, which is why Fetch and Render is more the view G actually sees.)

The screenshot below shows the Inspect method of viewing the rendered page in current Chrome - but as I say, safest is to view within Google Search Console's Fetch tool.

Hope that helps?

Paul

P.S. This is an example of why Wix is not recommended for critical websites - it's using JavaScript methods to render basic page content which Google "says" it can index, but it's depending on a completely non-standard way of presenting page content which depends on search crawlers deviating from their standard methods to try to crawl it. (And there have been incidents in the past where G's crawling capabilti8y for this kind of JavaScript wasn't indexing it properly, causing major issues for a huge number of sites.)

hgWsq

^^ Ayup.

What technology stack is running the websites? Most Cms-based systems have some method of building the xml sitemaps from the database, which is vastly superior to having to build it from a crawl.

P.

George, you also need to confirm that those pages you want no-indexed are not blocked in the robots.txt file at the base of your website. As mentioned above, if they're under a robots.txt block, the crawler won't see your on-page no-index tag and the pages can still end up in the index.

Also, you can right-click on an empty spot on the page and select Inspect to see the rendered version of the code in the Inspector. If that shows your no-index correctly and the page isn't blocked by robots.txt, the issue isn't GTM.

I'd strongly recommend changing that to actually redirect the /index.html version. There's no reason for either bots or human visitors to ever visit that URL. (A redirect is a directive, whereas canonical is only a suggestion and will leave the unwanted page in the search index.)

P

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

You absolutely do not want to use the remove URL tool in Search Console!!

Since those old subdomain pages have been ranking and earning traffic and authority in the SERPs, it would be a huge mistake to just throw that all away.

Instead, you must use 301-redirects to point those old page URLs to the new page you've created on the main site that you now wish to earn that traffic. The authority and ranking power of the old pages will transfer to the new ones. It's like being told you can choose to start the race from the starting line, or you can be given a 25-yard head start with a tailwind.

Take the head start - redirect the old pages. A side effect of the 301 redirects is that after a period of time, the search engines will stop indexing the old pages, so they'll drop out of the SERPs eventually.

Hope that helps?

Paul