Per què Google pot veure el teu blog tècnic com a contingut de poc valor encara que els articles siguin bons
Anàlisi honest de per què Google pot marcar un blog tècnic com a low value content, fins i tot amb articles de qualitat.

Fa uns mesos vaig sol·licitar AdSense per a oshy.tech. La resposta va ser un rebuig amb l’etiqueta “low value content”. La meva primera reacció va ser pensar que estaven equivocats. Els articles estaven escrits des de l’experiència, amb codi real, sense farciment. No eren articles de cinc paràgrafs generats per una IA sense criteri. Eren peces que havien requerit hores d’escriptura, revisió i prova dels snippets de codi.
Després d’analitzar el lloc amb més distància, vaig entendre que Google no estava avaluant només la qualitat de cada article individual. Estava avaluant el lloc com un tot. I vist com un tot, oshy.tech tenia problemes reals que no havia volgut veure.
Aquest article és l’anàlisi honest de què pot fer que un blog tècnic sembli “low value” per a Google, fins i tot quan el contingut dels articles és genuïnament bo. No és una guia de com enganyar l’algorisme. És una reflexió des de l’experiència d’algú que va ser rebutjat, va investigar per què, i va descobrir que el problema no era on pensava.
Què significa “low value content” per a Google
Quan Google marca un lloc com a contingut de poc valor, no sempre vol dir que el contingut sigui dolent. Vol dir que el lloc, avaluat en conjunt, no compleix els criteris que Google considera suficients per mostrar anuncis o per posicionar de manera favorable.
És una distinció important. Google no llegeix el teu article sobre Spring Boot i Kotlin i diu “això no val”. El que fa és avaluar el lloc com un sistema: quantes pàgines té, quin percentatge d’aquestes pàgines són contingut substancial, quines senyals de qualitat detecta, com es comporten els usuaris i quina estructura informativa presenta.
Les senyals que Google avalua van més enllà del text de cada article:
- Volum de contingut indexat. Un lloc amb 5 articles i 30 pàgines indexades té un ràtio molt desfavorable. Google es pregunta: si només hi ha 5 articles, per a què existeixen les altres 25 pàgines?
- Proporció de pàgines amb valor vs pàgines sense valor. Si de 40 URLs indexades, 25 són categories buides, tags amb un article i pàgines de paginació, el percentatge de contingut real és baix.
- Senyals d’engagement. Temps a la pàgina, taxa de rebot, pàgines per sessió. Un lloc nou té poc tràfic i poques senyals positives, cosa que no ajuda a demostrar utilitat.
- E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness). Per a contingut tècnic, Google vol veure qui escriu, quina experiència té i per què hauria de ser creïble.
- Contingut duplicat o molt similar. Això inclou traduccions directes que Google pot interpretar com a contingut duplicat cross-language si l’hreflang no està ben implementat.
- Freqüència i patró de publicació. Un lloc que publica 5 articles de cop i després res durant mesos pot semblar menys compromès que un amb publicació regular.
El Helpful Content Update de Google (ara integrat al sistema de ranking general) avalua si un lloc produeix contingut “primàriament per a persones” o “primàriament per a cercadors”. No n’hi ha prou que cada article sigui útil; el lloc com a conjunt ho ha de demostrar.
Les senyals que probablement estava enviant oshy.tech
Seré transparent amb els problemes que vaig identificar al meu propi lloc. No perquè vulgui exposar-me, sinó perquè aquests són errors que comet gairebé qualsevol desenvolupador que munta un blog tècnic i que són difícils de veure quan ets dins del projecte.
Poques pàgines de contingut real vs moltes pàgines d’estructura
Quan vaig sol·licitar AdSense, oshy.tech tenia uns 10-12 articles publicats. Però el lloc generava moltes més URLs. Això és el que un crawler veia:
- Pàgina principal (1)
- Pàgines de blog per idioma (3: es, en, ca)
- Cada article en 3 idiomes (30-36 URLs)
- Categories en cada idioma (probablement 20-25 URLs de categories)
- Pàgines de tags (potser unes 15-20)
- Paginació de llistats
- Pàgines estàtiques (about, legal, contacte)
De sobte, un lloc amb 12 articles tenia més de 80 URLs potencialment indexables. I d’aquestes 80, la majoria eren pàgines de llistat amb 1-2 articles. Google veu això i pensa: aquest lloc té més estructura que contingut. Més embolcall que producte.
Per visualitzar-ho amb nombres concrets:
| Tipus de pàgina | Quantitat estimada | Contingut real |
|---|---|---|
| Articles (3 idiomes) | ~36 | Alt |
| Categories (3 idiomes) | ~24 | Baix (llistats amb 1-2 ítems) |
| Tags (3 idiomes) | ~18 | Molt baix (llistats amb 1 ítem) |
| Paginació | ~6 | Nul (només enllaços) |
| Estàtiques | ~5 | Variable |
| Total | ~89 | ~36 amb valor (40%) |
Un 40% de pàgines amb contingut real no és terrible, però quan les pàgines d’alt valor són traduccions entre si (12 articles originals, no 36), el ràtio real baixa molt més. Google està veient potser 12 peces de contingut original en un lloc amb 89 URLs. Això és un 13%.
Categories amb un sol article
Aquest va ser probablement el problema més greu i el més fàcil d’evitar. Vaig crear categories pensant en el futur editorial. “Kotlin”, “Java”, “Linux”, “OSINT”, “Data Analysis”, “Automatització”… El problema és que diverses d’aquestes categories tenien un sol article. Algunes ni tan sols en tenien un a tots els idiomes.
Una pàgina de categoria amb un article és, funcionalment, una pàgina que té un títol, un parell de línies de descripció i un enllaç. Per a Google, això és thin content. No aporta res que l’article per si sol no aporti ja. I cadascuna d’aquestes pàgines dilueix la qualitat percebuda del lloc.
Vaig pensar que tenir categories preparades mostraria que el lloc tenia una estructura editorial sèria. En realitat, mostrava el contrari: una estructura ambiciosa sense el contingut que la justifiqués. És com obrir un restaurant amb 30 taules i servir menjar a 3. L’estructura buida no impressiona; genera desconfiança.
Multidioma com a multiplicador del problema
Tenir el blog en tres idiomes (castellà, anglès, català) triplica tots els problemes anteriors. Un article són tres URLs. Una categoria són tres pàgines de categoria. Un tag són tres pàgines de tag.
Si l’article en castellà és bo però la versió en anglès és una traducció directa amb poc tràfic i la versió en català té encara menys, Google pot veure dues d’aquestes tres versions com a contingut de baix valor. No perquè el text sigui dolent, sinó perquè no té senyals d’utilitat: ningú no el llegeix, ningú no l’enllaça, ningú no hi interactua.
A més, si la implementació d’hreflang no és perfecta, Google pot interpretar les versions com a contingut duplicat en lloc de traduccions legítimes. Un detall tècnic que té conseqüències grans en la percepció global del lloc.
El multidioma també afecta les mètriques d’engagement. Si Google veu que la versió en català d’un article té 0 visites en tres mesos, aquesta és una senyal negativa. No és que Google penalitzi per tenir poc tràfic, però l’absència de senyals positives en moltes pàgines suma per a l’avaluació general.
Falta de senyals d’autoria i experiència
Els primers articles d’oshy.tech no tenien una pàgina d’autor clara, no enllaçaven a un perfil professional verificable, i la pàgina “About” era mínima. Per al Helpful Content Update, les senyals d’E-E-A-T importen especialment en contingut tècnic.
Google vol saber: aquesta persona que escriu sobre Spring Boot i Kotlin, realment treballa amb això? On és l’evidència? Un blog anònim sense senyals d’autoria real competeix en desavantatge amb blogs que tenen autors identificables amb perfils professionals enllaçats.
No es tracta de posar un CV sencer a la pàgina About. Es tracta que existeixin senyals verificables: un nom real, un perfil de LinkedIn, contribucions a projectes, mencions a altres llocs, experiència demostrable. Sense aquestes senyals, Google tracta el contingut com a anònim, i el contingut tècnic anònim té menys credibilitat algorítmica que el signat per algú amb trajectòria verificable.
Contingut duplicat cross-language: un problema que es subestima
Quan tradueixes un article del castellà a l’anglès, el contingut és estructuralment el mateix. Els mateixos títols, la mateixa estructura, els mateixos exemples de codi, la mateixa argumentació. Google és bastant bo detectant traduccions. Amb hreflang correctament implementat, entén que són versions del mateix contingut i no les penalitza com a duplicat.
Però hi ha matisos que importen.
El primer matís és que l’hreflang ha de ser perfecte. Si hi ha errors (URLs que no coincideixen, hreflang no recíproc, URLs amb redireccions), Google pot ignorar les senyals d’hreflang i tractar les versions com a pàgines independents amb contingut molt similar. En aquest cas, pot decidir indexar només una versió i descartar les altres, o pot tractar-ho tot com a contingut de baixa originalitat.
El segon matís és que fins i tot amb hreflang correcte, Google avalua cada versió de manera independent per al ranking. Si la versió en castellà té 50 visites al mes i la versió en català en té 0, Google pot decidir que la versió en català no mereix estar indexada. I si té moltes versions que “no mereixen estar indexades”, això contribueix a la percepció general de baix valor.
El tercer matís afecta específicament els snippets de codi. En un article tècnic, gran part del contingut (el codi) és idèntic en tots els idiomes. Si tens un article de 300 línies on 100 són codi i 200 són text, el 33% del contingut és literalment idèntic a les tres versions. Google pot interpretar això com un percentatge alt de contingut compartit.
No estic dient que el multidioma sigui dolent. Estic dient que multiplicar idiomes sense tenir la base tècnica correcta multiplica també els problemes. I que per a un lloc petit, cada idioma addicional ha de justificar la seva existència amb tràfic i engagement reals.
Què és el Helpful Content System i com afecta els blogs petits
El sistema de contingut útil de Google (originalment “Helpful Content Update”, ara integrat al ranking general) avalua si un lloc produeix contingut primàriament per ajudar persones o primàriament per atraure tràfic de cercadors.
Això sona abstracte, però té implicacions concretes. Les senyals que Google fa servir inclouen:
- Proporció de contingut original vs contingut derivatiu. Si la majoria de les teves pàgines són llistats generats automàticament (categories, tags, arxius) i poques són contingut original (articles), la proporció és desfavorable.
- Profunditat del contingut. Articles superficials que cobreixen un tema sense profunditat es classifiquen com a thin content. Un article de 300 paraules que explica què és Kotlin no competeix amb un de 2000 que analitza les friccions reals de fer servir Kotlin amb JPA.
- Experiència demostrable. Contingut que mostra experiència real (codi provat, decisions justificades, errors comesos i resolts) s’avalua millor que contingut teòric genèric.
- Consistència temàtica. Un lloc que parla de tot sense aprofundir en res té menys autoritat temàtica que un enfocat en 2-3 temes amb profunditat.
- Contingut first-party vs contingut genèric. Google distingeix entre contingut que aporta perspectiva pròpia i contingut que recopila informació disponible a altres llocs.
Per a un blog tècnic petit, el tercer i quart punt són especialment rellevants. Si escrius sobre Kotlin, SEO, Python, Linux, OSINT i anàlisi de dades en 12 articles, no estàs demostrant expertise en cap d’aquests temes. Estàs demostrant que saps una mica de moltes coses. Google prefereix la profunditat a l’amplitud, especialment en llocs amb poca autoritat de domini.
Això no vol dir que no puguis tenir temes variats. Vol dir que necessites massa crítica en cada tema. Tres articles sobre Kotlin amb profunditat real demostren més experiència que un article sobre cadascun de deu temes diferents.
El rebuig d’AdSense: què diu i què no diu
El rebuig d’AdSense per “low value content” és una avaluació binària: el lloc passa o no passa un llindar de qualitat. Google no dóna detalls específics sobre què va fallar. Això genera frustració, però també obliga a fer una revisió completa.
El que el rebuig diu:
- El lloc, avaluat com un tot, no compleix els estàndards mínims de Google per mostrar anuncis.
- Hi ha prou senyals de baix valor com per no aprovar-lo.
El que el rebuig no diu:
- No vol dir que el contingut sigui dolent. Pot ser que el contingut sigui bo però l’estructura sigui pobre.
- No és permanent. Es pot tornar a sol·licitar després de fer canvis.
- No afecta directament el ranking orgànic. AdSense i l’algorisme de cerca són sistemes separats, encara que comparteixen alguns criteris de qualitat.
L’error més comú després d’un rebuig és publicar més articles ràpid pensant que el problema és de volum. Si el problema és estructural, més articles sobre la mateixa estructura trencada no ho resolen. De fet, poden empitjorar-ho si cada article nou genera més categories i tags de baix valor.
El pla: què faria abans de tornar a sol·licitar AdSense
Després d’analitzar tot això, vaig construir un pla concret. No és teoria; és el que estic implementant a oshy.tech abans de tornar a intentar-ho.
1. Consolidar categories
Reduir el nombre de categories a les que tenen almenys 3-4 articles. Les categories amb 1-2 articles es fusionen en categories més àmplies o s’eliminen. Menys categories amb més contingut cadascuna és millor que moltes categories buides.
A la pràctica, això va significar passar de tenir categories com “Kotlin”, “Java”, “Linux”, “OSINT”, “Sherlock”, “Data Analysis” a alguna cosa més consolidada: “Backend” (que agrupa Kotlin, Java, Spring Boot), “Data” (que agrupa anàlisi, pipelines, ETL), “Eines” (que agrupa automatització, scraping, OSINT). Menys categories, però cadascuna amb prou contingut per justificar la seva existència com a pàgina indexable.
2. Noindex agressiu en pàgines de baix valor
Totes les pàgines de llistat (categories, tags) que tinguin menys de 3 articles porten noindex. Les pàgines de paginació porten noindex. Les pàgines de tags s’eliminen directament si no tenen prou volum.
L’objectiu és que les pàgines indexades siguin majoritàriament articles complets, no embolcalls amb un enllaç. Si Google veu 50 URLs i 45 són articles amb profunditat, la percepció és completament diferent de 50 URLs de les quals 20 són llistats buits.
3. Millorar el ràtio contingut/estructura
Publicar més articles abans de tornar a sol·licitar. Però no articles ràpids o de farciment, sinó contingut substancial que demostri experiència real. L’objectiu és que quan Google visiti el lloc, la majoria d’URLs indexades siguin articles amb profunditat, no pàgines d’estructura.
La meta concreta és arribar a 20-25 articles substancials abans de tornar a sol·licitar. Això, amb categories consolidades i noindex a pàgines de baix valor, hauria de donar un ràtio de contingut real molt més favorable.
4. Resoldre el multidioma correctament
Revisar que tots els hreflang siguin correctes, recíprocs i apuntin a URLs finals sense redireccions. Assegurar-me que els canonical de cada versió apuntin a si mateixos. Considerar si totes les versions en tots els idiomes realment aporten valor o si és millor ser més selectiu amb quins articles es tradueixen.
No tots els articles necessiten existir en tres idiomes. Un article sobre la loteria nacional espanyola té sentit en castellà però no necessàriament en anglès. Ser selectiu amb les traduccions és millor que traduir-ho tot automàticament per “omplir” els altres idiomes.
5. Reforçar E-E-A-T
Millorar la pàgina About amb informació verificable. Enllaçar al perfil professional. Incloure una bio de l’autor a cada article amb context rellevant (“backend engineer amb experiència en Spring Boot i Kotlin”). Afegir Schema Person/Author amb dades reals.
També incloure als articles senyals d’experiència: esmentar projectes reals, explicar decisions que es van prendre i per què, documentar errors que es van cometre. Això no és presumir; és demostrar que el contingut ve d’algú que ha treballat amb el que escriu.
6. Schema Article a tots els articles
Dades estructurades correctes a cada article: TechArticle, autor, dates, descripció, idioma. No és un factor de ranking directe, però ajuda Google a entendre el contingut i pot millorar la presentació als resultats de cerca.
7. Revisar Search Console setmanalment
Google Search Console és l’eina més important per entendre què veu Google. Les pàgines amb errors d’indexació, les URLs “descobertes però no indexades”, els problemes de cobertura, les queries que generen impressions. Tot això indica on són els problemes reals, sense endevinar.
Una dada que vaig descobrir a Search Console: diverses pàgines de categories estaven marcades com a “crawled - currently not indexed”. Google les va rastrejar, les va avaluar i va decidir no indexar-les. Aquesta és una senyal directa que Google va considerar aquelles pàgines insuficients per al seu índex.
El que aquest procés m’ha ensenyat
La lliçó més important no és tècnica. És de perspectiva. Com a desenvolupadors, tendim a pensar en qualitat de contingut com la qualitat del text que escrivim. Ens preguntem: és correcte? és útil? està ben explicat? I aquestes són preguntes vàlides, però incompletes.
Google no avalua articles aïllats. Avalua el lloc com un sistema. L’arquitectura de la informació, la proporció de contingut real sobre el total de pàgines, les senyals d’autoria, la coherència tècnica del multidioma, la consistència temàtica. Tot això compta tant o més que la qualitat individual de cada article.
Un article excel·lent en un lloc amb mala estructura tècnica rendeix menys del que hauria. No perquè Google “no l’entengui”, sinó perquè les senyals del lloc complet baixen la credibilitat de l’article individual. És com presentar un bon plat en un restaurant brut: el plat pot ser bo, però el context contamina la percepció.
L’altra lliçó és sobre l’honestedat amb un mateix. És fàcil veure un rebuig d’AdSense i pensar “Google està equivocat, el meu contingut és bo”. Pot ser que el teu contingut sigui bo. Però si el teu lloc té categories buides, tags sense volum, multidioma mal implementat i poca senyal d’autoria, estàs sabotejant el teu propi contingut amb decisions d’estructura que vas prendre sense pensar en com les veuria un crawler.
La tercera lliçó és que el SEO tècnic no és un tema a part del contingut. Són el mateix. Un article sense canonical correcte, sense hreflang funcional, en una categoria amb thin content, és un article que comença la cursa amb desavantatge. I en un lloc petit sense autoritat de domini, aquest desavantatge pot ser la diferència entre posicionar i no existir.
El contingut bo és condició necessària però no suficient. L’estructura que l’envolta determina si Google el veu com a contingut valuós dins d’un lloc valuós, o com a contingut aïllat dins d’un lloc que encara no ha demostrat el seu valor.
El que no faria: reaccions que empitjoren la situació
Després d’un rebuig, hi ha reaccions instintives que semblen lògiques però que poden empitjorar les coses. Les esmento perquè vaig estar a punt de caure en diverses.
Publicar articles ràpids per “omplir” el lloc. Si el problema és de proporció contingut/estructura, afegir articles superficials no millora el ràtio. De fet, afegeix més pàgines que Google pot considerar thin content. Cada article nou hauria de ser substancial, no farciment per arribar a un nombre.
Crear més categories per als articles nous. Exactament el mateix error que va causar el problema original. Si publiques un article sobre Docker i crees la categoria “DevOps” amb un sol article, has empitjorat l’estructura. Millor posar-lo en una categoria existent que ja tingui prou contingut.
Traduir-ho tot a més idiomes. Si el multidioma ja és un problema, afegir un quart idioma no ho resol. Cada idioma addicional multiplica les pàgines de baix valor si no hi ha audiència real per a aquella versió.
Comprar backlinks o fer outreach agressiu. Els backlinks ajuden al posicionament orgànic, però no són el que avalua AdSense. El problema amb “low value content” és intern del lloc, no d’autoritat externa. Gastar esforç en backlinks quan l’estructura està trencada és posar una façana bonica a un edifici amb els fonaments malament.
Ignorar el rebuig i seguir com si res. La temptació de pensar “ja posicionarà sol” és forta. Però les senyals de baix valor no es corregeixen soles amb el temps. Es corregeixen amb canvis estructurals deliberats.
La reacció correcta és aturar-se, analitzar, corregir l’estructura i després continuar publicant sobre una base sòlida. No és la resposta ràpida que un vol escoltar, però és la que funciona.
Per a qui és útil això
Si tens un blog tècnic petit i vols entendre per què no posiciona o per què Google no el valora com esperaves, revisa l’estructura abans de culpar el contingut. Si tens poques pàgines però moltes URLs indexades, si tens categories amb un article o si tens multidioma sense hreflang correcte, és probable que el problema sigui allà.
No és un problema d’escriure més. És un problema d’ordenar el que tens abans de créixer. Un lloc petit amb estructura neta té més possibilitats que un lloc petit amb estructura inflada. I això és una cosa que pots arreglar aquesta setmana, sense escriure ni un article nou.
Obre Google Search Console, mira quines URLs estan indexades, quines estan marcades com a “not indexed” i quines tenen errors. Aquesta informació et dirà més sobre el teu problema que qualsevol checklist genèric de SEO. I si descobreixes que la meitat de les teves URLs indexades són pàgines de categories buides, ja saps per on començar.

