Després de detectar spam SEO a WordPress acostumen a aparèixer diverses llistes: una de l’allotjament, una altra de Google i un full amb les URL que algú ha anat trobant. Si no es connecten, és fàcil esborrar una cosa que s’havia de conservar o donar per recuperada una pàgina que només ha desaparegut d’una captura.
Un informe útil converteix aquestes llistes en decisions traçables. Relaciona cada URL amb l’evidència, l’acció aprovada, el responsable i la comprovació posterior. Aquesta guia inclou una estructura original i un exemple fictici emplenat. Pots utilitzar-la per encarregar una neteja o revisar el lliurament amb el proveïdor.
Per investigar el símptoma inicial, la guia de spam que Google mostra sense entrades visibles a WordPress desenvolupa el diagnòstic. El procediment de neteja sense esborrar contingut legítim explica les precaucions tècniques. Aquí organitzem l’informe que permet coordinar i acceptar aquesta feina.
Comença amb un resum que permeti decidir
Obre el document amb domini, propietat de Search Console, data, zona horària, responsables i símptoma comunicat. Resumeix què s’ha confirmat, què encara no se sap i quina decisió necessita el propietari. Una captura d’un resultat japonès no demostra tota sola quantes pàgines estan afectades.
Indica l’abast examinat: instal·lació pública, idiomes, altres aplicacions o compte d’allotjament. Si només es disposa d’accés al WordPress principal, deixa aquest límit visible. Evita convertir «no revisat» en «sense incidència» quan preparis el resum executiu.
Desa un identificador d’informe i una versió. Cada actualització ha d’explicar què ha canviat des de l’anterior. Així poden col·laborar desenvolupament, continguts i SEO sense treballar sobre tres arxius anomenats «definitiu».
Separa URL descobertes, revisades i confirmades
Registra d’on ve cada candidat: exportació de Search Console, registre del servidor, sitemap, alerta de l’allotjament o revisió manual. Una font ajuda a descobrir; no converteix automàticament l’element en una ordre d’esborrament.
Conserva les URL exactes i assenyala les variants relacionades. No eliminis paràmetres, canviïs majúscules o agrupis rutes només perquè semblen iguals. Primer determina si representen el mateix contingut i quin mecanisme les serveix. Una normalització precipitada pot amagar la condició que has d’investigar.
Si hi ha massa candidats per revisar-los un a un, documenta els grups, el criteri de selecció i la mostra comprovada. Declara quants elements es van observar realment i quins hereten una classificació provisional. Un total de files no equival al total d’infeccions demostrades.
La fitxa mínima de cada URL
Utilitza aquests camps com a punt de partida. La plantilla és una proposta editorial original; no és una exportació oficial de Google ni un escàner.
Referència de fila:
URL exacta i origen del descobriment:
Data/hora d'observació i zona horària:
Mètode, estat HTTP i primera redirecció:
Contingut observat i evidència restringida:
Idioma, relacions i contingut legítim afectat:
Classificació: confirmat / legítim / pendent
Acció proposada i motiu:
Aprovació, responsable i data:
Resultat tècnic i prova posterior:
Estat de cerca i data de la seva font:
Revisió següent i pendent concret:L’evidència pot quedar en un repositori restringit, amb una referència a la fila. Evita enganxar càrregues sospitoses, credencials o dades de clients al document que circularà entre equips. L’informe ha de ser utilitzable sense convertir-se en un magatzem públic de l’incident.
Exemple original d’inventari i decisions
Les quatre files següents són fictícies i pertanyen al domini reservat example.invalid. No són resultats de Search Console, URL de clients ni peticions executades. Els estats s’han triat per mostrar decisions diferents.
| Fila i ruta | Observació fictícia | Decisió proposada | Responsable | Criteri de tancament |
|---|---|---|---|---|
SP-01/catalogo/spam-a/ |
200 amb contingut aliè confirmat | Eliminar el generador i retirar la ruta sense substitut legítim | Tècnic i propietari | Resposta prevista verificada; persistència revisada |
SP-02/es/productos/equipo-a/ |
200; producte legítim amb títol alterat | Restaurar el contingut i conservar l’URL vàlida | Continguts i tècnic | Títol, pàgina i idiomes correctes |
SP-03/ofertas/pendiente-b/ |
403; contingut sense revisar | Investigar el bloqueig abans de classificar | Allotjament i tècnic | Resposta explicada i classificació documentada |
SP-04/spam-antiguo-c/ |
404 actual; resultat de cerca anterior conservat | Registrar retirada tècnica i seguir la dada de Google | SEO | Resposta estable i seguiment de l’índex documentat |
SP-01 i SP-02 mostren per què no convé esborrar per una paraula o un prefix. Una ruta és aliena; l’altra pertany al negoci i necessita reparació. SP-03 manté la incertesa a la vista. SP-04 separa l’estat actual de la dada històrica del cercador.
Prioritza per exposició i impacte en el negoci
Afegeix una prioritat i el seu motiu. Una resposta activa que desvia visitants, una pàgina comercial legítima alterada i una URL antiga ja retirada són situacions diferents. El nombre de files no basta per decidir quin equip ha d’actuar primer.
Demana al tècnic que identifiqui l’exposició actual i la contenció necessària, mentre continguts identifica pàgines i operacions essencials. Un grup desconegut necessita investigació, no esborrament automàtic. Conserva qui aprova i el criteri utilitzat per entendre per què es va atendre un grup petit abans que un de més gran.
Separa la intervenció urgent de la feina que pot esperar una revisió documentada. Per a cada partida ajornada, indica condició pendent, responsable i comprovació següent. «Prioritat baixa» no s’ha de convertir en una fila sense amo que hi romangui indefinidament.
I si allotjament i Google semblen contradir-se?
Compara objecte i data. L’allotjament pot descriure un escaneig de fitxers i la informació de cerca una URL rastrejada abans. Conserva les dues fonts a la fila, amb les dates. Pregunta què acredita cadascuna i quina observació resoldria la diferència. Una alerta o un escàner net no han d’esborrar l’altra evidència.
Elimino les files resoltes?
Desa-les en un apartat tancat o una versió conservada, amb referències i dates de tancament. Així distingeixes candidats nous i històrics coneguts. Si reapareix una ruta, tindràs la decisió anterior per comparar-la. Retira material sensible innecessari segons el procés de conservació acordat sense perdre la història útil de decisions.
Relaciona la neteja amb el mecanisme que generava el spam
L’inventari d’URL descriu el resultat visible. Afegeix una secció que relacioni els grups confirmats amb els components, registres o regles que els servien. Si aquesta relació és una hipòtesi, identifica-la i explica quina evidència falta.
Registra els canvis aprovats, la còpia prèvia i les comprovacions posteriors. Quan diverses files depenen del mateix generador, enllaça-les al canvi comú en lloc de repetir una història diferent a cadascuna. Conserva també les excepcions legítimes que s’han protegit.
Si apareixen noves URL després de la feina, anota hora, patró i relació amb l’incident anterior. No tanquis la revisió per haver assolit el nombre d’elements de la primera llista. L’aparició de material nou mereix una decisió tècnica, no una correcció cosmètica del comptador.
Protegeix pàgines comercials, productes i idiomes
Inclou una llista curta de controls legítims: portada, serveis principals, productes representatius, categories, formularis i traduccions rellevants. Identifica el responsable de continguts que pot confirmar que continuen sent els registres correctes.
Per a cada element afectat, distingeix restaurar contingut, corregir metadades, retirar un registre aliè o reparar una ruta. Conserva les relacions d’idiomes i la navegació. Una pàgina que obre pot haver perdut l’equivalent traduït, el producte associat o un enllaç important.
Demana una aprovació basada en les URL i funcions acordades, amb resultats desats. «La web carrega» diu poc del contingut preservat. El tancament ha de permetre veure què es va protegir i com es va comprovar.
Desa per separat resposta actual i informació de Google
A la columna tècnica registra la petició, l’hora i la resposta observada. A la columna de cerca conserva la data de la font i l’estat que mostrava. La documentació d’Inspecció d’URL distingeix la informació indexada d’una prova en directe.
Un 404 recollit avui i un resultat desat abans poden coexistir. No canviïs contínuament la ruta per fer coincidir les dues captures. Documenta la comprovació següent i conserva la seqüència. Una prova aïllada tampoc acredita que la resta del lloc estigui neta.
Si s’han utilitzat variants de visita, indica quines eren capçaleres simulades, què es va provar realment en un navegador i què va quedar sense executar. El lector ha de poder entendre l’abast sense confondre una condició sintètica amb un rastrejador de Google verificat.
Documenta retirades i sitemaps com a accions diferents
L’eina de Retirades serveix per bloquejar temporalment resultats a Google. A l’informe, separa la sol·licitud de la neteja del servidor i registra el prefix o URL enviat, motiu, aprovació i estat. Comprova l’abast abans de tramitar un prefix ampli.
En una altra partida, registra la revisió dels sitemaps i dels enllaços interns. La guia oficial de sitemaps explica la funció d’ajudar al descobriment. Enviar un arxiu no equival a demostrar indexació ni recuperació de posicions.
Si una decisió utilitza noindex, anota com el podrà trobar el rastrejador. Google explica que un bloqueig de rastreig pot impedir que llegeixi aquesta instrucció. Demana que el tècnic justifiqui la configuració triada per a cada grup; evita aplicar restriccions generals sense revisar-ne l’efecte sobre contingut vàlid.
Separa problemes de seguretat, accions i seguiment
Reserva un apartat per als avisos i les sol·licituds tramitades: informe d’origen, exemples, correccions relacionades, data d’enviament i persona responsable de respondre. No barregis una sol·licitud pendent amb una resolució rebuda.
La guia sobre problemes de seguretat que romanen a Search Console després de netejar tracta aquest recorregut. L’informe comú ha de conservar la referència del cas perquè SEO i desenvolupament no presentin explicacions incompatibles del mateix canvi.
Una referència visual per passar del resum al registre
La vista d’auditoria Nodus, de Tanzeel Ul Islam Badar, reuneix resum, període, cerca i files. La fem servir com a referència d’organització visual; no hem provat els filtres ni els resultats de seguretat.
Trasllada aquesta idea a l’informe: cada xifra del resum ha de portar a les files que l’expliquen, amb període i criteri visibles. Si canvia el total, s’ha de poder saber si van entrar candidats nous, es van eliminar duplicats o va canviar una classificació. El color ajuda a llegir; la traçabilitat permet decidir.
Com acceptar l’informe i continuar mesurant
Comprova que les accions aprovades tenen resultat, evidència i responsable. Les files pendents han d’explicar el motiu i el pas següent. Desa l’acceptació tècnica separada del seguiment de cerca: pots verificar un canvi propi mentre un tercer encara processa la seva informació.
Per mesurar trànsit, utilitza períodes comparables i la mateixa propietat i tipus de cerca a GSC. Conserva data del canvi i cobertura de la dada. Un dia de clics no demostra tota sola recuperació; una disminució d’URL de spam tampoc mesura el negoci que torna a les pàgines vàlides.
Acordeu qui revisarà files obertes, canvis de contingut i avisos nous. Fixa la revisió següent segons els pendents concrets. L’informe ha de continuar sent una eina de feina després del lliurament, no una foto bonica que ningú torni a obrir.
Laboratori observat: retirar una URL no tancava la neteja
El 25 d’octubre de 2026 vam executar aquest exercici en una instal·lació aïllada de WordPress 7.1.3, PHP 8.3.36 i MariaDB 11.4.12. Els canvis eren innocus i deliberats: una entrada aliena de demostració, el títol alterat d’una pàgina legítima i un afegit condicional servit per una extensió. No hi va haver infecció real, explotació d’una vulnerabilitat ni dades de clients.
Vam conservar el títol i contingut originals de dues entrades legítimes, els identificadors i les empremtes SHA-256. Després vam introduir els tres canvis i vam relacionar cada observació amb el registre o fitxer que la generava. Aquesta relació permet decidir què cal retirar i què cal restaurar. Una llista d’URL, tota sola, es queda a mitja conversa.
La condició formava part de la prova
Vam demanar la mateixa pàgina de servei de manera ordinària i amb la capçalera inventada X-Lab-Condition: example-variant. Només la segona resposta incloïa l’afegit de demostració i el seu enllaç a un domini reservat .invalid. Aquesta condició sintètica no representa un mòbil, una sessió d’administrador, un CDN ni Googlebot. Serveix per mostrar per què convé conservar les condicions de reproducció al costat de la URL.
Primer vam fer una neteja deliberadament incompleta
Vam enviar a la paperera únicament l’entrada aliena. L’adreça va passar de 200 a 404, tal com s’esperava. Tanmateix, el títol del servei continuava alterat i la variant conservava l’afegit. La URL havia desaparegut; dos canvis seguien tranquil·lament al seu lloc de treball. El registre va mantenir tots dos pendents oberts.
Després vam restaurar el títol legítim des de la versió conservada i vam retirar exclusivament el fitxer de demostració identificat per la seva empremta. Vam repetir les quatre peticions: servei ordinari, servei amb condició, control legítim i entrada retirada. El servei va mantenir el contingut, va recuperar el títol original i va deixar de mostrar l’afegit en totes dues condicions. El control va continuar disponible i l’adreça retirada va mantenir el 404.
| Element | Abans | Retirada parcial | Correcció completa de l’exercici |
|---|---|---|---|
| Entrada aliena | 200, marcador visible | 404 | 404 |
| Títol legítim | Alterat | Continua alterat | Original restaurat |
| Afegit condicional | Visible amb la condició | Continua present | Absent en totes dues condicions |
| Entrada de control | 200, contingut original | 200, conservat | 200, títol i contingut conservats |
Què acredita el registre
La sèrie conservada conté dotze peticions GET, repartides en tres grups de quatre. El tancament inclou també dues visites reals en Chromium 152.0.7977.82, amb la condició i sense: el servei restaurat es veia i l’afegit no apareixia. Les empremtes finals del títol i contingut de les dues entrades legítimes coincidien amb les originals. El fitxer de demostració ja no existia.
En acabar vam retirar els tres contenidors, la xarxa privada i les credencials creades per a l’exercici. Descarrega el registre del laboratori: CSV, inventari i evidència JSON. El paquet conté dades fictícies i observacions executades; no inclou codi executable ni credencials. Les marques de temps identifiquen les observacions i no es presenten com un temps de reparació comercial.
El cas comprova la retirada de canvis coneguts en aquell entorn. No estudia una via real d’entrada, persistència desconeguda, un allotjament complet ni l’estat de Google. Tampoc es va executar cap escàner per declarar el web «net». La guia de WordPress sobre llocs compromesos desenvolupa la documentació i la conservació de còpies abans d’intervenir. Al teu informe, demana vincular cada conclusió amb la seva evidència i deixar visible el que continua pendent.
Què demanar a l’especialista
Demana un abast que inclogui inventari justificat, protecció del contingut legítim, registre de canvis, proves i traspàs. Si has de comparar propostes, utilitza la guia de serveis de neteja de malware WordPress per al 2027 per concretar lliurables i límits abans de contractar.
Per demanar una avaluació de spam SEO a WordPress, envia unes quantes URL exactes, origen dels avisos, dates i abast conegut. Malware Cleanup pot revisar aquest context i proposar el pas següent. Un bon inventari redueix la incertesa perquè conserva què falta saber, a més del que ja s’ha resolt.