The devlog records what got fixed and when, in date order. This is the part that log doesn't capture — a retrospective on what I actually got wrong across three straight AdSense rejections, and how I finally diagnosed it correctly.
1. First rejection: "low value content"
Anime Semantle started as just the game — an input box and a results table, nothing else. When the first AdSense review came back with "low value content," I took the phrase at face value: not enough content meant not enough pages.
2. Second rejection: turning one mistake into 34
So I built a full anime/character list page. When that still got rejected, I went further and added 36 genre pages at once (17 genres × Korean/English) in a single push. The result was a third rejection, with the exact same reason: "low value content."
In hindsight, that was inevitable. Every one of those pages was MyAnimeList data repackaged into a different layout. Multiplying the page count by 34 doesn't multiply the content's value by 34 — it just multiplies the signal "this site is overwhelmingly made of low-value pages" by 34 instead.
That's when I changed direction. I set every genre page to
noindex and pulled them out of search entirely, and built
something the site itself actually produces — a daily-updated
past answers archive. On the about
page, I published the raw data behind how the similarity weighting was
actually chosen, instead of just asserting it.
3. Third rejection: what I see isn't what Google sees
Even after changing course, the third review was rejected too. This time I approached it differently — instead of judging the site by how I saw it, I opened Google Search Console and checked what was actually indexed.
12 pages were indexed. 5 of them were the contact and privacy policy pages. I hadn't built many content pages, but even the few I had were outnumbered by boilerplate pages in the list Google was actually reading. No matter how much effort I put into the about page, from the index corpus's point of view it was still 1 of 12, with half the list made of standard legal pages.
The lesson is simple — "is there enough content" isn't a question you answer by looking at your own site. You answer it by opening the search engine's actual index list.
4. What looked like a policy violation was actually a bug
The same investigation turned up a completely unrelated problem. Internal
links and canonical tags pointed at .html-suffixed URLs, but the
host was serving those as temporary (307) redirects. Because 307 is
"temporary," Google kept holding onto the original URL — resulting in
duplicate indexing, like contact and contact.html
both getting indexed separately.
The sitemap also hadn't been recrawled in nearly three weeks. The cause was
a value left over from a version several weeks old:
<changefreq>quarterly</changefreq> — not a valid value
in the sitemap protocol. Google was still holding onto that stale version even
though it had long since been removed.
Neither issue had anything to do with "content value." But it's plausible both contributed to why the index corpus looked thin and messy — duplicate indexing means the same content occupies two slots, and a sitemap stuck on recrawl means new content never even reaches Google's view in the first place.
5. Where things stand now
I unified internal URLs across all 50 files on the site to drop the extension, and resubmitted the sitemap. I filled the past answers archive with a human-written comment for every date, trying to shed the impression of "auto-generated daily, never touched by a person." The stats page and the participation tracking feature were added during this same push.
Two things remain: the time it takes Google to recrawl and reindex these changes (usually 1-2 weeks), and real traffic plus organic backlinks — with the domain still brand new, that part accumulates the slowest.
6. For other builders
- Don't respond to a "not enough content" rejection with page count. Repackaging the same data into more pages doesn't add value, no matter how many you add.
- Open the actual index corpus yourself. Not the content you built — the list of pages the search engine actually indexed. That's where the real problem shows up.
- What looks like a "policy violation" might be a bug. Check redirect chains and sitemap protocol errors too — places that have nothing to do with content quality.
- Build data that only your site produces. One record that accumulates daily on its own beats another page repackaging an external API.