In September, when the Google AdSense review replied citing low-value content, I went through this blog page by page looking for what needed to change. The easiest problem to see was not in the articles. It was in the topic archives: addresses such as /tags/privacidade/ listed two posts and repeated the title and description of each one, without adding anything to what the reader had already seen on the home page.

The page itself is necessary. It is this site’s navigation by subject, and it appears in the topic index and in the chips at the end of each post. What does not hold up is asking Google to show it in search results. An archive with one or two items answers no question; it repeats content that already exists at another address. The decision was to keep the page for the reader and ask the search engine not to index it.

What Google says, and what it does not say

There is no published rule of the form “an archive with fewer than three posts cannot be indexed.” What exists are documents that, read together, support the decision.

The first is the guide to helpful content for people. Among the questions it poses to publishers is whether the page offers a substantial, complete description of the subject. A list of two items does not.

The second is the Google Search spam policy, in the section on scaled content abuse. It deals with pages generated to manipulate results “that provide little or no value” and gives explicit guidance: whoever hosts that kind of content should exclude it from search. The official mechanism for that is the noindex rule, documented separately: a meta in the page’s <head> that removes the page entirely from the results, regardless of other sites pointing to it.

The third is the AdSense inventory policy: displaying ads is not allowed on screens “without publisher content or with low-value content.” The review this blog received cited exactly that. No ads are live here, and this post will not turn them on; the point is that the same assessment Google makes for advertising shows up in search.

The rule this blog adopted

Fluxonar’s topic archive declares noindex when it has fewer than three posts. In Astro, that is one line in the dynamic tag route:

<BaseLayout
  title={`Tópico: ${tag} · Fluxonar`}
  description={`Todos os posts do Fluxonar sobre ${tag}...`}
  noindex={count < 3}
>

The SEO component, when it receives noindex, emits it in the page’s <head>:

<meta name="robots" content="noindex, follow">

Update note (29/10/2026): until 28/10/2026 the meta was noindex, nofollow. It became noindex, follow: the page stays out of the index, but its links still count so the search engine can reach the posts. The evidence extract from 18/09 records the state on that date.

On the date of this text (18/09/2026), three of the eleven topics in use were in that range, all with two posts: smartphones, typescript, and privacy. On 23/10/2026, the collection has 12 topics: smartphones (6), typescript (5), and privacy (5) have already passed three and are indexable again; the only one with two posts is prompt-engineering. Any reader can open the page source and see the meta; the others do not have it.

Three is my choice, not a Google rule. It is the point at which a page stops being only a repetition and starts to offer a slice. If I change my mind, the number changes in one line. When a topic gains its third post, it becomes indexable again on its own, with no list to maintain.

The topic index stays indexable and links to every page, including the ones with noindex. The reader does not lose the path; the search engine simply does not receive those pages as an answer.

The detail that almost slipped past: the sitemap

After the change went live, I checked the published page. The meta was there. The other side still needed a check: the file that tells Google what the site wants to show. sitemap-0.xml was still listing the three addresses.

The contradiction is direct. The sitemap is the list of URLs the site wants to see in the results — the Google documentation says, in these words, to include the URLs “that you want to see in search results.” Keeping a page there that asks not to be indexed is saying one thing and the opposite. Search Console has its own statuses for this conflict: the page shows up as “URL marked as noindex” in the indexing report, and the sitemap can flag the submitted URL that carries noindex.

The fix was to make the sitemap read the rendered HTML, the same HTML Google receives. Astro’s sitemap integration gained a filter:

// astro.config.mjs
filter: (page) => !page.endsWith('/404') && !paginaComNoindex(page),

paginaComNoindex opens the generated file in dist/ and looks for the robots meta. I did not create a second count of posts per topic: if the noindex rule changes, the sitemap follows without anyone having to remember. And parity became a test, in both directions: the project’s test suite now fails if a page with noindex appears in the sitemap or if an indexable page is left out of it. A rule declared in two places without proof is a rule that diverges in silence.

What noindex does not do

Four limits that apply to anyone who will use this on their own site:

  1. It is not immediate removal. Google has to crawl the page again to read the meta; depending on the page, that can take months. If you are in a hurry, the path is URL inspection in Search Console, and the indexing report shows what is excluded and why.
  2. It does not work if robots.txt blocks the page. An indexing rule is read only where the crawler can enter; blocking access also hides the request not to index. Here robots.txt allows everything.
  3. noindex does not have to cut the links. With follow, the search engine keeps following the page’s links through to the posts. With nofollow, as it was here until 28/10/2026, they would stop counting from that page, although the pages would remain linked from the topic index and from the categories. The sitemap stops listing them, as described above.
  4. The number three is a heuristic, not a guarantee. I did not measure traffic or ranking before and after: the blog is new, and these pages are too small for an honest number. What can be stated is the declared state, which can be checked in the source of any of them.

How to apply it on your site

  1. Open the topic or category archive and count what the page offers. If it only repeats items that exist somewhere else, it is a candidate.
  2. Confirm that robots.txt does not block the path — a blocked noindex is not read.
  3. Apply the rule on the route, conditional on the count (in Astro, noindex={count < 3}).
  4. Open the source and check the meta. Expected result: content="noindex, follow" present on the right page and absent from the others.
  5. Find the address in the sitemap and remove it there, preferably by automating the exclusion from the same source that generates the noindex.
  6. Check in Search Console: URL inspection shows the HTML Google received; the indexing report shows what is excluded and why.

What remains

An archive page is useful for someone who is browsing and dispensable for someone who is searching. noindex separates the two. The sitemap needs to say the same thing the page says — and, when the two agree, the decision stops depending on someone remembering it.

Sources