Why Google may see your technical blog as low value content even when the articles are good

A few months ago I applied for AdSense on oshy.tech. The response was a rejection with the label “low value content.” My first reaction was to think they were wrong. The articles were written from experience, with real code, no filler. They weren’t five-paragraph articles generated by an AI with no judgment. They were pieces that had required hours of writing, revision, and testing of the code snippets.

After analyzing the site with more distance, I understood that Google wasn’t evaluating just the quality of each individual article. It was evaluating the site as a whole. And viewed as a whole, oshy.tech had real problems I hadn’t wanted to see.

This article is the honest analysis of what can make a technical blog look “low value” to Google, even when the article content is genuinely good. It’s not a guide on how to trick the algorithm. It’s a reflection from someone who got rejected, investigated why, and discovered the problem wasn’t where he thought.

What “low value content” means to Google

When Google flags a site as low value content, it doesn’t always mean the content is bad. It means the site, evaluated as a whole, doesn’t meet the criteria Google considers sufficient for showing ads or ranking favorably.

It’s an important distinction. Google doesn’t read your article about Spring Boot and Kotlin and say “this isn’t worth it.” What it does is evaluate the site as a system: how many pages it has, what percentage of those pages are substantial content, what quality signals it detects, how users behave, and what informational structure it presents.

The signals Google evaluates go beyond the text of each article:

• Volume of indexed content. A site with 5 articles and 30 indexed pages has a very unfavorable ratio. Google wonders: if there are only 5 articles, why do the other 25 pages exist?
• Proportion of valuable pages vs low-value pages. If out of 40 indexed URLs, 25 are empty categories, tags with one article, and pagination pages, the percentage of real content is low.
• Engagement signals. Time on page, bounce rate, pages per session. A new site has little traffic and few positive signals, which doesn’t help demonstrate usefulness.
• E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness). For technical content, Google wants to see who writes, what experience they have, and why they should be credible.
• Duplicate or very similar content. This includes direct translations that Google may interpret as cross-language duplicate content if hreflang isn’t properly implemented.
• Publication frequency and pattern. A site that publishes 5 articles at once and then nothing for months may look less committed than one with regular publication.

Google’s Helpful Content Update (now integrated into the general ranking system) evaluates whether a site produces content “primarily for people” or “primarily for search engines.” It’s not enough for each article to be useful; the site as a whole has to demonstrate it.

The signals oshy.tech was probably sending

I’m going to be transparent about the problems I identified on my own site. Not because I want to expose myself, but because these are mistakes that almost any developer who sets up a technical blog makes, and they’re hard to see when you’re inside the project.

Few real content pages vs many structural pages

When I applied for AdSense, oshy.tech had about 10-12 published articles. But the site was generating many more URLs. This is what a crawler saw:

• Homepage (1)
• Blog pages per language (3: es, en, ca)
• Each article in 3 languages (30-36 URLs)
• Categories in each language (probably 20-25 category URLs)
• Tag pages (maybe another 15-20)
• Listing pagination
• Static pages (about, legal, contact)

Suddenly, a site with 12 articles had more than 80 potentially indexable URLs. And out of those 80, most were listing pages with 1-2 articles. Google sees that and thinks: this site has more structure than content. More packaging than product.

To visualize it with concrete numbers:

A 40% rate of pages with real content isn’t terrible, but when the high-value pages are translations of each other (12 original articles, not 36), the real ratio drops much further. Google is seeing maybe 12 pieces of original content on a site with 89 URLs. That’s 13%.

Categories with a single article

This was probably the most serious problem and the easiest to avoid. I created categories thinking about the future editorial plan. “Kotlin,” “Java,” “Linux,” “OSINT,” “Data Analysis,” “Automation”… The problem is that several of those categories had a single article. Some didn’t even have one in every language.

A category page with one article is, functionally, a page that has a title, a couple lines of description, and a link. For Google, that’s thin content. It adds nothing that the article by itself doesn’t already provide. And each of those pages dilutes the perceived quality of the site.

I thought having prepared categories would show the site had a serious editorial structure. In reality, it showed the opposite: an ambitious structure without the content to justify it. It’s like opening a restaurant with 30 tables and serving food at 3. The empty structure doesn’t impress; it breeds distrust.

Multilingual as a problem multiplier

Having the blog in three languages (Spanish, English, Catalan) triples all the problems above. One article becomes three URLs. One category becomes three category pages. One tag becomes three tag pages.

If the Spanish article is good but the English version is a direct translation with little traffic, and the Catalan version has even less, Google may see two of those three versions as low-value content. Not because the text is bad, but because it has no utility signals: nobody reads it, nobody links to it, nobody interacts with it.

Furthermore, if the hreflang implementation isn’t perfect, Google may interpret the versions as duplicate content instead of legitimate translations. A technical detail that has major consequences for the overall perception of the site.

Multilingual also affects engagement metrics. If Google sees that the Catalan version of an article has 0 visits in three months, that’s a negative signal. It’s not that Google penalizes for low traffic, but the absence of positive signals across many pages adds up in the overall evaluation.

Lack of authorship and experience signals

The first articles on oshy.tech didn’t have a clear author page, didn’t link to a verifiable professional profile, and the “About” page was minimal. For the Helpful Content Update, E-E-A-T signals matter especially for technical content.

Google wants to know: does this person writing about Spring Boot and Kotlin actually work with those technologies? Where’s the evidence? An anonymous blog without real authorship signals competes at a disadvantage against blogs with identifiable authors who have linked professional profiles.

It’s not about putting a full CV on the About page. It’s about verifiable signals existing: a real name, a LinkedIn profile, contributions to projects, mentions on other sites, demonstrable experience. Without those signals, Google treats the content as anonymous, and anonymous technical content has less algorithmic credibility than content signed by someone with a verifiable track record.

Cross-language duplicate content: an underestimated problem

When you translate an article from Spanish to English, the content is structurally the same. The same headings, the same structure, the same code examples, the same arguments. Google is quite good at detecting translations. With correctly implemented hreflang, it understands they’re versions of the same content and doesn’t penalize them as duplicates.

But there are nuances that matter.

The first nuance is that hreflang has to be perfect. If there are errors (mismatched URLs, non-reciprocal hreflang, URLs with redirects), Google may ignore the hreflang signals and treat the versions as independent pages with very similar content. In that case, it may decide to index only one version and discard the rest, or it may treat everything as low-originality content.

The second nuance is that even with correct hreflang, Google evaluates each version independently for ranking. If the Spanish version gets 50 visits per month and the Catalan version gets 0, Google may decide the Catalan version doesn’t deserve to be indexed. And if it has many versions that “don’t deserve to be indexed,” that contributes to the overall perception of low value.

The third nuance specifically affects code snippets. In a technical article, a large portion of the content (the code) is identical across all languages. If you have a 300-line article where 100 lines are code and 200 are text, 33% of the content is literally identical across all three versions. Google may interpret that as a high percentage of shared content.

I’m not saying multilingual is bad. I’m saying that multiplying languages without having the right technical foundation also multiplies the problems. And for a small site, each additional language has to justify its existence with real traffic and engagement.

What the Helpful Content System is and how it affects small blogs

Google’s Helpful Content System (originally the “Helpful Content Update,” now integrated into general ranking) evaluates whether a site produces content primarily to help people or primarily to attract search engine traffic.

This sounds abstract, but it has concrete implications. The signals Google uses include:

• Proportion of original content vs derivative content. If most of your pages are automatically generated listings (categories, tags, archives) and few are original content (articles), the proportion is unfavorable.
• Content depth. Shallow articles that cover a topic without depth are classified as thin content. A 300-word article explaining what Kotlin is can’t compete with a 2,000-word one analyzing the real frictions of using Kotlin with JPA.
• Demonstrable experience. Content that shows real experience (tested code, justified decisions, mistakes made and resolved) is rated better than generic theoretical content.
• Thematic consistency. A site that talks about everything without going deep into anything has less topical authority than one focused on 2-3 topics with depth.
• First-party content vs generic content. Google distinguishes between content that contributes a unique perspective and content that aggregates information available elsewhere.

For a small technical blog, the third and fourth points are especially relevant. If you write about Kotlin, SEO, Python, Linux, OSINT, and data analysis in 12 articles, you’re not demonstrating expertise in any of those topics. You’re demonstrating that you know a little about a lot of things. Google prefers depth over breadth, especially on sites with low domain authority.

This doesn’t mean you can’t have varied topics. It means you need critical mass in each topic. Three articles about Kotlin with real depth demonstrate more experience than one article on each of ten different topics.

The AdSense rejection: what it says and what it doesn’t

The AdSense rejection for “low value content” is a binary evaluation: the site either passes or doesn’t pass a quality threshold. Google doesn’t give specific details about what failed. That’s frustrating, but it also forces you to do a thorough review.

What the rejection says:

• The site, evaluated as a whole, doesn’t meet Google’s minimum standards for showing ads.
• There are enough low-value signals to not approve it.

What the rejection doesn’t say:

• It doesn’t mean the content is bad. It could be that the content is good but the structure is poor.
• It’s not permanent. You can reapply after making changes.
• It doesn’t directly affect organic ranking. AdSense and the search algorithm are separate systems, although they share some quality criteria.

The most common mistake after a rejection is to quickly publish more articles thinking the problem is volume. If the problem is structural, more articles on the same broken structure won’t fix it. In fact, they can make it worse if each new article generates more low-value categories and tags.

The plan: what I’d do before reapplying to AdSense

After analyzing all of this, I built a concrete plan. This isn’t theory; it’s what I’m implementing on oshy.tech before trying again.

1. Consolidate categories

Reduce the number of categories to those that have at least 3-4 articles. Categories with 1-2 articles get merged into broader categories or eliminated. Fewer categories with more content each is better than many empty categories.

In practice, this meant going from having categories like “Kotlin,” “Java,” “Linux,” “OSINT,” “Sherlock,” “Data Analysis” to something more consolidated: “Backend” (grouping Kotlin, Java, Spring Boot), “Data” (grouping analysis, pipelines, ETL), “Tools” (grouping automation, scraping, OSINT). Fewer categories, but each with enough content to justify its existence as an indexable page.

2. Aggressive noindex on low-value pages

All listing pages (categories, tags) with fewer than 3 articles get noindex. Pagination pages get noindex. Tag pages are removed entirely if they don’t have sufficient volume.

The goal is for indexed pages to be predominantly full articles, not wrappers with a link. If Google sees 50 URLs and 45 are in-depth articles, the perception is completely different from 50 URLs where 20 are empty listings.

3. Improve the content-to-structure ratio

Publish more articles before reapplying. But not quick filler articles—substantial content that demonstrates real experience. The goal is that when Google visits the site, the majority of indexed URLs are in-depth articles, not structural pages.

The concrete target is to reach 20-25 substantial articles before reapplying. That, with consolidated categories and noindex on low-value pages, should yield a much more favorable real-content ratio.

4. Fix multilingual correctly

Verify that all hreflang tags are correct, reciprocal, and point to final URLs with no redirects. Make sure each version’s canonical points to itself. Consider whether all versions in all languages actually add value, or if it’s better to be more selective about which articles get translated.

Not every article needs to exist in three languages. An article about the Spanish national lottery makes sense in Spanish but not necessarily in English. Being selective with translations is better than automatically translating everything to “fill” the other languages.

5. Strengthen E-E-A-T

Improve the About page with verifiable information. Link to a professional profile. Include an author bio in every article with relevant context (“backend engineer with experience in Spring Boot and Kotlin”). Add Schema Person/Author with real data.

Also include signals of experience within articles: mention real projects, explain decisions that were made and why, document mistakes that were made. That’s not bragging; it’s demonstrating that the content comes from someone who has actually worked with what they write about.

6. Schema Article on all articles

Correct structured data on every article: TechArticle, author, dates, description, language. It’s not a direct ranking factor, but it helps Google understand the content and can improve presentation in search results.

7. Review Search Console weekly

Google Search Console is the most important tool for understanding what Google sees. Pages with indexing errors, URLs “discovered but not indexed,” coverage issues, queries generating impressions. All of that tells you where the real problems are, without guessing.

One thing I discovered in Search Console: several category pages were marked as “crawled - currently not indexed.” Google crawled them, evaluated them, and decided not to index them. That’s a direct signal that Google considered those pages insufficient for its index.

What this process has taught me

The most important lesson isn’t technical. It’s about perspective. As developers, we tend to think of content quality as the quality of the text we write. We ask ourselves: is it correct? Is it useful? Is it well explained? And those are valid questions, but incomplete ones.

Google doesn’t evaluate isolated articles. It evaluates the site as a system. The information architecture, the proportion of real content to total pages, authorship signals, multilingual technical coherence, thematic consistency. All of that counts as much as or more than the individual quality of each article.

An excellent article on a site with poor technical structure yields less than it should. Not because Google “doesn’t understand it,” but because the signals from the entire site lower the credibility of the individual article. It’s like serving a great dish in a dirty restaurant: the dish may be good, but the context taints the perception.

The other lesson is about honesty with yourself. It’s easy to see an AdSense rejection and think “Google is wrong, my content is good.” Your content may be good. But if your site has empty categories, tags without volume, poorly implemented multilingual, and weak authorship signals, you’re sabotaging your own content with structural decisions you made without thinking about how a crawler would see them.

The third lesson is that technical SEO isn’t a topic separate from content. They’re the same thing. An article without a correct canonical, without functional hreflang, in a category with thin content, is an article that starts the race at a disadvantage. And on a small site without domain authority, that disadvantage can be the difference between ranking and not existing.

Good content is a necessary but not sufficient condition. The structure surrounding it determines whether Google sees it as valuable content within a valuable site, or as isolated content within a site that hasn’t yet proven its worth.

What I wouldn’t do: reactions that make things worse

After a rejection, there are instinctive reactions that seem logical but can actually make things worse. I mention them because I almost fell into several.

Publishing quick articles to “fill” the site. If the problem is the content-to-structure ratio, adding shallow articles doesn’t improve the ratio. In fact, it adds more pages that Google may consider thin content. Every new article should be substantial, not filler to hit a number.

Creating more categories for new articles. Exactly the same mistake that caused the original problem. If you publish a Docker article and create the “DevOps” category with a single article, you’ve made the structure worse. Better to put it in an existing category that already has enough content.

Translating everything into more languages. If multilingual is already a problem, adding a fourth language doesn’t fix it. Each additional language multiplies low-value pages if there’s no real audience for that version.

Buying backlinks or doing aggressive outreach. Backlinks help organic ranking, but they’re not what AdSense evaluates. The problem with “low value content” is internal to the site, not about external authority. Spending effort on backlinks when the structure is broken is putting a nice facade on a building with bad foundations.

Ignoring the rejection and carrying on as if nothing happened. The temptation to think “it’ll rank on its own eventually” is strong. But low-value signals don’t correct themselves over time. They get corrected through deliberate structural changes.

The right reaction is to stop, analyze, fix the structure, and then keep publishing on a solid foundation. It’s not the quick answer you want to hear, but it’s the one that works.

Who this is useful for

If you have a small technical blog and want to understand why it’s not ranking or why Google doesn’t value it as you expected, check the structure before blaming the content. If you have few pages but many indexed URLs, if you have categories with one article, or if you have multilingual without correct hreflang, the problem is likely there.

It’s not a problem of writing more. It’s a problem of organizing what you have before growing. A small site with clean structure has better chances than a small site with inflated structure. And that’s something you can fix this week, without writing a single new article.

Open Google Search Console, look at which URLs are indexed, which are marked as “not indexed,” and which have errors. That information will tell you more about your problem than any generic SEO checklist. And if you discover that half your indexed URLs are empty category pages, you already know where to start.