The marketplace’s SEO team rewrote its indexing rule after a simple “fewer-than-3-listings = noindex” policy caused category pages to vanish from Google and take weeks to return. By adding a one-way “unlock” record that lets a page move from noindex to index but never back, the site stopped the flicker.

Why the original rule backfired

The classifieds platform generates many category-and-location pages. When a page first appears it often contains only a handful of listings, so the team decided to hide it from search until it reached a minimal threshold of three items. The logic was straightforward:

  • < 3 listings → add a noindex meta tag
  • ≥ 3 listings → remove the tag (allow indexing)

Initially this kept thin, low-value pages out of Google’s results. The problem emerged as listings expired. A page with five listings one day could drop to two the next, instantly flipping back to noindex. Google obeyed, stripped the URL from its index, and the page lost any ranking it had built. When a new listing arrived, the page became indexable again, but the re-entry process took weeks.

The result was a constant “on-off” cycle: pages entered the index, disappeared, re-entered, and so on.

The one-way “unlock” fix

The core flaw was that the rule had no memory; it recomputed the threshold on every request. The team introduced a tiny database table—seo_unlocks—that records when a page first reaches the three-listing mark. The new workflow is:

  1. Check listing count. If the page has three or more active listings, proceed.
  2. Write an unlock row. Insert a record for that page into seo_unlocks.
  3. Treat the page as permanently indexable. Even if later counts fall below three, the presence of an unlock row keeps the page out of the noindex flow.

Because the unlock can only be written once, a page can move from “noindex” to “index” but never back. The team added safeguards so that filtered URLs (e.g., search results with price ranges) cannot create unlocks for their parent categories, and wrapped the database call in a try/catch block to prevent a DB failure from crashing the whole site.

What this means for crawl budget and thin pages

A common misconception is that noindex saves crawl budget. Google still has to fetch the page, read the tag, and then drop it from the index. If the goal is to keep Google from requesting a whole URL pattern, the correct tool is robots.txt. Use noindex only when you want Google to see the page but not display it in search results.

For directories, job boards, and marketplaces that rely on large numbers of auto-generated pages, the lesson is clear: thin-page rules must be coupled with a persistence layer that remembers when a page has earned a spot in the index. Without that memory, a temporary dip in content can cause a page to lose the ranking it had built, and re-entry can take weeks.

Takeaway

A static “if count < 3 then noindex” rule creates SEO volatility for dynamic listings sites. Adding a one-way unlock record gives the rule memory, allowing pages to earn and keep their index status even when listings fluctuate. Pair that with proper use of robots.txt for true crawl-budget savings, and you can protect both rankings and server resources.