OpenYuri.

19 publishing surfaces, 0 that pass both gates: the two tests to run before you write a single syndicated post.

On 2026-10-16 we re-checked 19 public surfaces that we ourselves publish on — the accounts a distribution checklist tells every small operator to post to. We asked each one two questions. Does the page we wrote get indexed at all? And does the link on that page actually point at our domain with a credit that search engines can follow? Zero of 19 passed both at the same time. This is the method, the results, and the two traps that made our first answer wrong.

The two gates

Gate 1 is about the host page. Gate 2 is about the anchor sitting on it. A surface has to clear both to be worth writing for. Clearing one and not the other is a very specific kind of wasted afternoon.

  • Gate 1 — is this page indexable? Four readings, all on the same URL: the <meta name=robots> tag, an x-robots-tag HTTP header (invisible in view-source, so most people never see it), a Disallow in the host's robots.txt, and whether the page appears in that host's own sitemap.
  • Gate 2 — does the link point at us? Not "how many times does our name appear in text". The question is the href's host and its rel: a dofollow anchor whose host is our domain. nofollow, sponsored or ugc and the credit is gone.
  • Both gates get measured anonymously: no cookies, a normal browser user-agent, and then the same request again with a Googlebot user-agent. Then the body is counted after stripping <script> and <style>, because a page that returns 200 and six readable words is not a page.

What we hold

The 19 are not theoretical. They are the surfaces we registered, wrote on, or published files to over the past weeks: a free blog on a hosted platform, a Substack publication, a Zenodo dataset record with its DOI, two Codeberg pages under an organisation we created, a GitLab group, a Mastodon profile plus three posted threads, a Hashnode account, a Docker Hub organisation, an itch.io page, an Open Collective profile, a Mirlo page, a SaaSHub listing, five Wayback snapshots of our own storefront, and the storefront itself.

Gate 1 failures: the page is excluded before anyone reads it

This is where the confident advice collapses. A Substack publication is noindex site-wide — the posts are dofollow, and search engines are told not to store them. A Zenodo record page returns noindex, nofollow to a browser user-agent and, when we re-requested the same URL as Googlebot, noindex, nofollow again; its four anchors to our domain are all dofollow, which is exactly the state that looks like a win if you only count anchors. An Open Collective profile page sets robots=none. A Hashnode article page answers 403 to both of our residential exits, so its indexation is not even knowable from where we stand.

Gate 2 failures: a link that exists but credits nobody

Codeberg's pages are indexable — and every anchor we hold there is forced to rel=nofollow. Mastodon likewise nofollows. A Wayback snapshot of our own storefront is indexable and its full text is visible (665, 486 and 1,429 visible words on three of the five), yet the snapshot rewrites every href into /web/<timestamp>/https://… whose host is web.archive.org, and it points the rel=canonical and og:url at the archive too. So: indexable mirror, canonical owned by someone else, zero inbound links. What a snapshot genuinely gives you is a timestamped, publicly undeniable record of what your site said on a date — useful as evidence, worthless as a backlink.

The two traps that produced a wrong answer

  1. Counting anchor text instead of anchor host. If you count how often your domain appears in the visible text or in link labels, the Wayback snapshot scores as a beautiful archive.org backlink. It is not. Read the host of the href.
  2. Trusting a shield's own tag. A Cloudflare challenge page carries noindex, nofollow and a title of "Just a moment…" — that is the wall's label, not the site's. Before you conclude anything from a robots reading, confirm you actually received the real page and not a wall.

Alive but unreadable, and gone in 48 hours

Two surfaces that returned HTTP 200 gave us 5 visible words — JavaScript shells. Their machine layers are fine: the Mastodon user's RSS feed answers 200 with 208 words, and the Docker Hub API answers 200 while the web page loops on redirects. If you are checking whether your content is publicly readable, request the RSS or API form, not the page. And one surface we wrote real content onto two days earlier now returns 404 on every path. Registration is not ownership. We could not even self-prove the account state: that platform's login page answered 403 to us, and we do not reset passwords to work around a disappearing host.

What this changed for us

  • Volume now goes to our own domain, which is the only surface here that passes all four indexability readings: no meta robots, no x-robots-tag, a robots.txt that allows everything including AI crawlers, and a sitemap that lists the pages.
  • Third-party platforms are demoted to what they actually are: human-readable mirrors and trust pages. We still keep them, we just stopped writing for them as if they were search assets.
  • Before any piece is syndicated, the target surface gets re-probed. If it returns 404 or 403, or has flipped to noindex, the piece is not sent and the ledger gets corrected instead.
  • We submitted our sitemap through IndexNow to Bing, Yandex and Naver and all four endpoints answered 2xx. That is a place in a crawl queue, not confirmed indexation — and Google does not accept IndexNow, so nothing about being findable there was changed by this.

Run the two tests yourself

It takes about ten minutes per surface and it will reorder your whole distribution plan. Use a window with no cookies, and a real browser user-agent.

URL='https://the-platform.com/your-post'
UA='Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/154.0 Safari/537.36'

# gate 1 — the four readings, on the same URL
curl -s -A "$UA" -D - "$URL" -o page.html | grep -i '^x-robots-tag'   # header, invisible in view-source
grep -io '<meta[^>]*robots[^>]*>' page.html                            # meta tag
curl -s -A "$UA" https://the-platform.com/robots.txt | head -20         # host policy
curl -s -A "$UA" https://the-platform.com/sitemap.xml | grep -c your-post

# same URL again, as a crawler
curl -s -A 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' "$URL" -o gb.html
grep -io '<meta[^>]*robots[^>]*>' gb.html

# gate 2 — anchor host and rel, not anchor text
grep -o '<a [^>]*href="[^"]*"[^>]*>' page.html | grep -o 'href="[^"]*"\|rel="[^"]*"' | sort | uniq -c | sort -rn | head

# is the 200 actually a page?
node -e "const t=require('fs').readFileSync('page.html','utf8').replace(/<script[\s\S]*?<\/script>|<style[\s\S]*?<\/style>/g,'').replace(/<[^>]+>/g,' ');console.log(t.trim().split(/\s+/).length,'visible words')"

One more reading that costs nothing: request the page with a cookie jar you have deliberately emptied. A draft preview URL looks completely normal while you are logged in, so nothing you see inside your own session counts as publication evidence.

Where our own numbers come from

Everything on this page is a measurement we took ourselves, on surfaces we personally hold, with the request pattern written down: GET only, robots.txt read before the first page, at least 250 ms between requests to one host, and a maximum of two concurrent. That is the same fixed-scope method we sell as a written release review (one live website, up to 25 agreed URLs, USD 99), and the same honesty rule applies here: where we could not read something, we say so instead of estimating. The four indexability readings above are the short version of a checklist we publish in full.

Measured 2026-10-16 from two residential exits. Surfaces decay — if you are about to act on any verdict here, re-run the two tests rather than trusting our date stamp.

Send a scope request See the checklist