Welcome to the Q&A Forum

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

If your site hasn't been moved to mobile-first index (and the vast majority haven't) then your mobile rankings are being based on your desktop site - which still gets hidden content devalued.

Hope that helps?

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

You have a defective link coded for the FAQ link in your site's footer, Andrew. It's currently coded as

[Which then gets parsed as a relative link. This means the link gets parsed as www.example.com/currentpageurl/URL

Because that link is in the sitewide footer, it means every page is generating that link as a link to itself with the /URL added to the end. Which you're seeing detected as all those 404s.

This is very important to fix not only because the FAQ link is broken in the footer, but you've doubled the number of pages of the site for the search crawlers, meaning they're wasting time following thousands of useless links instead of focusing on real pages.

So fortunately it's a quick fix - find that link in your footer template and correct it.

Make sense?

Paul](URL)

Search engines don't "punish" for duplicate content. But what does happen is you make it very hard and confusing for them to decide which version of the duplicated content is more important and more valuable. As  a result, often neither does very well in rankings as they end up competing against and diluting each other..

What is the thinking around why having exactly the same content on two different sites for two different towns is useful and beneficial for a search visitor?

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.

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

Canonical and noindex are contradictory, Yael. It's either.or, never both. And in the case you describe, I doubt you could no-index the versions with parameters without doing it to the main URL as well (since technically they are all the same page code).

What you are describing is the classic use case for canonical tags - the exact same page referred to by multiple different URLs.

Hope that makes sense?

Paul

First thing to confirm - did you recently migrate to HTTPS?

If the crawler is returning 404 errors, it's because it can't find those pages when following links. Since those pages don't exist, you won't find them in your WP dashboard either, Myflgreen.

The next step is to determine if they should exist (i.e they've been deleted accidentally), in which case you need to rebuild them.

If in fact they don't exist on purpose, you then need to look at the pages that contain the links to the non-existent pages and fix those pages so they don't contain the broken link in their content. (You can find the linking pages by downloading the 404 error report.)

You'll also want to consider adding a redirect from the non-existent pages to another page on the site that provides essentially the same info, if such a page exists. (This is in case other websites might have been linking to those pages at some point)

Final note - sometimes, these links show up as 404s because the link itself is written slightly incorrectly - double check for that too, if the link seems to be pointing to a real page but is 404ing.

Hope that helps?

Paul

Have you seen any further improvement on the indexing front, Cat?

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

^^ Yup - great summary.

Paul

This is another automated tool that is pointing out to you that currently, your website is lacking in the areas that indicate a trustworthy, authoritative website.

The way to "fix this" is to begin improving your website using the tools and suggestions made by the folks in your other question.

Paul

That SF response is from the robots.txt block, not a noindex tag though. SF is also ignoring the incorrectly formatted tag (as it should).

Paul

The example page does have a noindex tag in place, but it's not formatted correctly, so it's being ignored. Very subtle issue, but your tag is using "smart quotes" around the elements instead of the plain quotation marks that are required for code. If you look very carefully at the page source code, you'll see that they are quotation marks like you'd see in a Word document; the ones at the beginning of robots and noindex curl a different way than the ones at the end.) This usually occurs when the content was written in a word processor instead of a plain-text editor.

Because the tag's not formatted correctly, it's ignored by both the crawling tools and the search engines.

In addition, the site also has all pages blocked from crawling by the sitewide robots.txt file. This and noindex are conflicting instructions to search engines.

If a page is blocked in robots.txt, then the search engine will not crawl the page and so is not able to discover the noindex tag, even if it were formatted correctly. Therefore if the search engine becomes aware of the page in any other way than straight crawling (and there are a number of ways this can happen), then the page will still get indexed.

If it's a dev site, the proper way to keep it from being indexed is to either noindex all pages, or to put the site behind a password so the search engines and public visitors can't access it. If using noindex, the site must not be blocked with a robots.txt directive.

Does that all make sense?

Paul

Yup, can do the same approach with SF. You can run it in List Mode which will let you upload the list of URLs to crawl, and you can set up an Extraction to separate out the h3s (Configuration > Custom > Extraction)

Paul

Alexa and DA are completely synthetic attempt by third-parties to try to guess what search engines might think of a website. Alexa, in particular, is a totally unreliable way of measuring the influence of most sites. If these measures have changed significantly, but with no change from your site's own data (e.g. Analytics, Search Console, careful rank testing etc) then it's far more likely that the third-party tools are having problems, not your site.

Put another way - those third-party tools are hints. If they indicate potential problems, you'll need to assess actual website performance to determine if there's a real problem, or if the 3rd party tools are misreporting.

Hope that makes sense?

Paul

Targeting the same keywords with an additional site could certainly affect impact your existing rankings. You'll essentially be competing against yourself. But it won't make any difference whether the second site is on an addon domain in your primary hosting or on a different host/IP address. Google has so many ways of knowing that two sites are related that goes far beyond what IP they use.

There can be instances where a second site for the same topics can be necessary/effective, but you'll want to be really sure that's the best approach as opposed to adjusting your existing site to accommodate whatever it is you're trying to accomplish. You're literally doubling your workload and competing against yourself in the process.

What's the purpose of the second site? To go after a completely different market segment?

Paul

Google's been quite clear that reviews on our sites from 3rd party review sources must not have review markup, SK. It's grounds for a "manipulative markup" penalty.

Review markup should "Only include critic reviews that have been directly produced by your site, not reviews from third-party sites or syndicated reviews."

Paul

Nope - not for submitting for indexing. If there have been considerable page changes though, traffic could fluctuate as search engines take their time figuring out and understanding the changes.

Paul