Block certain namespace webpages for anonymous users (non registered users)

Question

For each general audience webpage (i.e. any main-namespace page such as an article page or Category: page), the MediaWiki content management system creates about 10 or 100 or 1,000 if not more webpages (link pages, revision pages, revision-diff pages, etc.) and for me that's a serious SEO problem.

MediaWiki doesn't have any core or even noncore fast way to lock all these peripheral webpages (for lack of a better term) to registered users, so naturally anyone, including the Google crawler, will crawl them. This can easily finish the crawling budget allocated for that website.

Blocking these pages with some brutal robots.txt directive such as the following is nice, but robots.txt blocking is by nature only "advisory". Directives may go outdated; directives won't necessarily affect all search engines; and the following directives aren't accessible for users don't know enough regex.

User-agent: *
Sitemap: https://example.com/sitemap/sitemap.xml
disallow: /index.php?
disallow: /index.php/*:
allow: /index.php/Category:
allow: /index.php/קטגוריה:

As of the time of publishing this post, MediaWiki doesn't have any command to block anything which isn't main-namespace from anonymous users (so that it won't even initially be discovered by search engines) and for me that's a serious SEO problem because it makes thousands if not tens or hundreds of thousands possibly irrelevant webpages to be discovered and most likely also periodically crawled (if or if not indexed) and it just "eats" any plausible crawling budget.

---

Blocking these webpages at the server level via Apache directives and regex isn't good because I do want to serve them, just not to anonymous users (which includes crawlers).

But, maybe some Web Application Firewall could help.

I host my website on a shared server plan in Namecheap with Cpanel and Apache ModSecurity WAF (or other WAF).

Can this be of use to solve my problem and if so how?

Answer 1

Thinking out loud.... would something like this work?

Recreate your general audience pages by turning them into specific landing pages that interlink between each other (limiting overflow). Then block your subscriber content by programming a token requirement. Subscriber logs in, user ID verified, password matches, token authenticated. Subscriber moves about the subscriber portal using the random token it was assigned. Web crawlers cannot imitate the token process, so they gain no access to the subscriber portal. Tokens expire after xx minutes of inactivity.

Answer 2

There is no SEO issue with the setup you have described.

All pages blocked by robots.txt are invisible to search engine crawlers, will not affect your crawl budget, and thus will not affect the rest of your site's SEO through the exhaustion of your crawl budget.

directives won't necessarily affect all search engines

It looks like you are already using a wildcard user-agent in your robots.txt, so your robots.txt file will affect all search engines that respect the robots.txt standard. This includes effectively every public search engine in existence, and certainly every search engine that it would be meaningful to care about SEO in respect to.

the following directives aren't accessible for users don't know enough regex.

What is your motivation behind making your robots.txt file readable to end users of your website? Typically there is no reason to do so.

Can this be of use to solve my problem and if so how?

Pardon me for saying this, but I don't understand the problem. The way you've described your site setup should cause none of the SEO issues you are worried about.