Zero linkow zewnetrznych do docs.msgwing.com - i to nasza wlasna regula je odciela

[msgwing]

Measured 2026-09-07 from Search Console exports (crawl stats, search performance, and both link reports).

The number

Google knows of two pages on the internet that link to docs.msgwing.com:

https://github.com/msgwing/ZeroSMTP
https://github.com/msgwing/ZeroSMTP/blob/main/SECURITY.md

Both are ours. Zero external backlinks. That is the entire "Latest links" and "More sample links" export - two rows, no truncation.

Why this explains every other number measured today

measurement	value
Googlebot requests / 36 days	217 (6 per day)
last 14 days vs the 14 before	21 vs 57 - down 63%
days with zero crawl visits	11 of 36
content fetches per sitemap URL	1.12 in 36 days
search impressions	~730
clicks	5 in 28 days, none attributable to any single query
best position with real volume	PRINTERS.html, 335 impressions, position 36.6

Crawl budget follows authority; authority follows links. With zero external links, none of these numbers can move by anything done on the site itself.

The technical side is already complete and was verified, not assumed: sitemap has 90 URLs all carrying lastmod with the freshest stamped the same day; robots.txt points at it; average response 55 ms; 98.6% 200; pages carry no unnecessary assets (TROUBLESHOOTING.html has zero <img>, one stylesheet, no external scripts). There is no on-site defect to fix.

The HTTPS report says it most bluntly

Google's HTTPS report - a separate export from the crawl and performance ones - lists the indexed HTTPS URLs it knows on this host:

pages in the HTTPS report	3
pages in the sitemap	90
peak, 2026-08-13	12
the last twelve days	3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3
those three last crawled	2026-08-09

The three are AFFECTED-SYSTEMS.html, TROUBLESHOOTING.html and FAQ.html. The count did not stall at 12 - it fell to 3 and has been flat for twelve days.

Ninety pages published, three known to Google, last looked at a month ago.

(The sitemap figure is 90, counted with grep -o. grep -c returns 1 because the file is a single line - the same trap this repository already documents; it was walked into again while writing this and corrected.)

The mechanism, and it is our own rule

CLAUDE.md records: "msgwing.com returns 403 to non-browser clients, so entries point at the GitHub repo." That rule is correct about msgwing.com and it exists because directory link-checkers would reject the entry otherwise. Verified again today:

msgwing.com        bare curl -> 403      browser UA -> 403
docs.msgwing.com   bare curl -> 200      browser UA -> 200

So every directory placement this project has ever made sends its link to github.com - a domain with unlimited authority that gains nothing - and nothing to the site that has to rank in Google.

docs.msgwing.com returns 200 to a bare curl. It would pass the same link-checkers that msgwing.com fails.

What follows

Not a proposal to change existing submissions - a merged entry is not ours to edit, and editing one to insert a different link is how a project gets remembered badly.

For submissions from here on, where the target list's format allows a second link or where the primary link is a matter of choice, docs.msgwing.com is the one that compounds. The repository link costs us the benefit; the docs link builds it.

Also worth naming: HP-PRINTER-SMTP.html receives zero impressions, while the general PRINTERS.html absorbs 335 at position 36.6 - and the strongest query cluster in the whole export is HP-printer-shaped (smtp server requires authentication hp printer, 18 impressions, position 20.3, plus three more HP variants at 25-29). The dedicated page exists, carries the exact error string, and is linked from three pages. Whether it is losing to its own general page or simply has not been crawled cannot be separated from this data. A URL inspection in Search Console would settle it.

Acceptance condition

Read 2026-10-07: does the "Links" report in Search Console name any host other than github.com? One is enough to falsify "zero external links". If it still names none, this diagnosis stands and the directory-link target is the lever, not anything on the site.

---

Correction, same day: Yandex falsifies half of this

Yandex Webmaster, 2026-09-06: 78 pages in search, 24 added, 0 removed. Among the newly indexed: HP-PRINTER-SMTP.html — the exact page named above as receiving zero Google impressions.

	Google	Yandex
pages indexed	3	78
direction	fell from 12	+24, none removed

Same site, same content, the same zero external links. So "zero backlinks" does not explain the indexing gap — Yandex reached 78 pages without a single one.

What survives: links plausibly explain position (36-60) and click-through. What does not survive: using them to explain why Google knows three pages. That was too broad and is retracted here rather than left standing.

Re-verified today, so the site is not the cause:

• no X-Robots-Tag header and no <meta name="robots"> on HP-PRINTER-SMTP, SELF-HOSTED or PRINTERS
• <link rel="canonical"> correct and self-referential on every page checked
• robots.txt carries no Googlebot-specific rule; Allow: / applies to everyone
• sitemap: 90 URLs, every one with lastmod, freshest stamped the same day

The hypothesis this replaces it with, and how to settle it

The remaining difference between the two engines that this repository can act on is whether the sitemap is actually submitted and being read in Google Search Console. Yandex found 78 pages while its own notification still suggests adding the sitemap — meaning it crawled its way there. Google has not.

Read: Search Console → Sitemaps. Is sitemap.xml listed, what is its status, and how many URLs does Google report as discovered? One screen settles it:

• submitted and healthy, 90 URLs discovered → the hypothesis is wrong and the gap is crawl budget after all
• not submitted, or erroring → that is the cause, and it is one click to fix

Until that is read, neither answer should be written down as fact.

---

Hypotheses closed, so nobody re-checks them in a month

Yandex, 2026-09-07: 78 pages, 0 added, 0 removed — a plateau, not a spike. 78 of the 90 in the sitemap, so twelve are missing there too.

Checked whether those twelve could be orphans that only a sitemap would reach: they are not. Of 91 .md files under docs/, exactly one is linked from no other page — security-txt, which is the source for /.well-known/security.txt and is not meant to be a linked page. The other 90 are all reachable by following links.

So internal linking is not the cause either. Everything on this side is now measured and clean:

checked	result
canonical	correct and self-referential on every page sampled
X-Robots-Tag / <meta name="robots">	absent — nothing blocks any crawler
robots.txt	Allow: /, no Googlebot-specific rule, points at the sitemap
sitemap	90 URLs, every one with lastmod, freshest same-day
internal linking	90 of 91 reachable; the one orphan is deliberate
response time	55 ms
status codes	98.6% 200

There is no on-site defect left to find. Further measurement here adds confirmations, not information.

The two remaining variables are both in webmaster panels and neither can be read from the repository:

1. Yandex: the sitemap is not submitted — every one of its notifications asks for it. It reached 78 pages by crawling alone.
2. Google Search Console → Sitemaps: unknown. This is the only difference between the two engines that has not been ruled out, and it is the one that would explain 3 versus 78.

---

Why the two link counts disagree, and what it means for the directory queue

Measured 2026-09-07. This explains why Search Console reports two linking pages while a directory entry that demonstrably sends real people is not among them.

Every link this project controls or has earned is either nofollow or rendered by JavaScript.

GitHub marks every outbound link rel="nofollow" — the repository's homepage field included:

<a href="https://msgwing.com" rel="nofollow">
<a href="https://docs.msgwing.com/" rel="nofollow">

That covers our own README, SECURITY.md, and every awesome-list entry we have ever placed, because those live in READMEs on github.com.

free-for.dev — the entry measured at 23 unique visitors per 14 days, the best-performing channel this project has — serves 3,556 bytes of HTML and renders its content with docsify, client-side. Our entry is not in the markup a crawler receives; it appears only after JavaScript runs. The page contains zero rel="nofollow" attributes for the simple reason that it contains almost no links at all in its raw form.

What follows, and it separates two things this project had merged

• Directories work for traffic. 23 real people, measured, from one line. That is not in question and nothing here argues against submitting to more of them.
• Directories do not work for search authority, because of how they are built. More entries will not move Google's index.

So the queue in #340 and the MCP submissions should be judged on whether that list sends humans, and never on what they might do for ranking. And the Google indexing gap — 3 pages against Yandex's 78 — cannot be closed by link building at all, which leaves the untested Search Console sitemap hypothesis above as the only remaining candidate.

Checked before writing this rather than after: changing the repository's homepage field from msgwing.com to docs.msgwing.com was considered and dropped — the link is nofollow either way, so it would have bought nothing.