Índice del artículo
Una tienda on-line, con miles de productos y el foco del propietario puesto en vender, vender y vender.
La web, como muchas otras, en un servidor compartido, un poco antiguo, sin medidas de seguridad y con una versión de php deprecada.
Resultado, web hackeada.
La mayoría de webs hackeadas que me he encontrado son pequeñas instalaciones de WordPress, con pocas medidas de seguridad o nulas, que han sido infectadas y mediante el hackeo del tipo SEO spam donde han creado miles y miles de páginas que se han indexado, muchas veces sin que el propietario sea consciente de ello hasta que su web sufre un bajón de visitas.
¿Te suena esta historia?
Así es como entran en coma multitud de proyectos que he visto durante mi trayectoria.
DISCLAIMER (empezamos temprano hoy): En este post, no voy a hablar de cómo limpiar una web de un hackeo, porque no es mi campo y me puedo colar en muchos ámbitos. Se deben hacer comprobaciones mediante SSH, que te las sabría enumerar, pero no ejecutar, pero sí que me he encontrado con muchas instalaciones que sufrían estos hackeos y veremos cómo revisar si ya están limpios.
Lo que sí veremos en este post es cómo revisar que la web se ha limpiado correctamente y cómo podemos arreglar el desastre que ha causado el hackeo.
El mayor problema después de un hackeo a nivel SEO es encontrar que tu web ha sido utilizada como una granja de enlaces mediante miles y miles de páginas.
Las páginas creadas por el hackeo tratan de diferentes temáticas que acostumbran a ser sensibles, y que enlazan a otras páginas con el fin de posicionar unas URL que a los atacantes les dan beneficios, llámalo SEO spam o llámalo como quieras.
¿Cómo afecta un hackeo al SEO?
Pues muy mal. No te voy a mentir. Puede suponer el descenso de hasta el 70% del tráfico, incluso causar la inviabilidad y cierre de la web.
Si al acceder a tu web, después de una búsqueda en Google te sale este aviso, será muy difícil recuperar el tráfico inicial:
Muchas veces los hackeos como el de SEO spam, al principio no afectan a las páginas principales, sino que crean nuevas URLs, y al ser más difícil de detectar pasan desapercibidas durante más tiempo, durante este tiempo aprovechan para indexar todo este contenido que van creando en tu web, contenido que trataremos de desindexar en este post.
Si por suerte has podido aplacar el hackeo antes que Google se de cuenta y antes que te lo notifique en Google Search Console, tendrás más opciones para evitar que el tráfico caiga en picado, en muchos de los casos que me encuentro.
Es por esto que vamos a dividir el trabajo en tres pasos:
PASO 1 – Comprobación que la web post-hackeo está limpia y bunkerización
En este paso, como SEO no nos corresponde limpiar una instalación, pero no está de más verificar que está completamente limpia. Uno de los mayores errores que he cometido es intentar desindexar todo lo que los hackers han indexado sin verificar que la instalación está completamente limpia.
En el próximo listado os indico qué procedimientos hago (en WordPress) para verificar que está todo limpio:
- Revisar que no haya scripts sospechosos en archivos: wp-config.php, index.php, functions.php de la plantilla activa, archivo .htaccess, archivo wp-login.php, si ves algo raro allí, frena, envía pantallazo al programador responsable de limpiar la web.
- Revisar que, después de una actualización del CORE en la carpeta raíz, y que en principio está todo limpio no haya archivos con extensión php con diferente fecha de modificación, esto normalmente lo podemos verificar con el scan de Wordfence, hacerlo a mano es una pérdida de tiempo.
- Pedir al programador o al administrador de sistemas que te ayude con limpiar la web que revise la web mediante SSH con las siguientes herramientas: clamav, maldet, ispprotect, wpscan y wp-vulnerability check. Con esta combinación seguro que encuentran el origen del ataque, y pedir reporte de ello.
- Pedir al servidor si puede bloquear accesos de países sospechosos, mediante firewalls cómo Imunify360 y de IP’s sospechosas si hay muchas. Muchos servidores con cierta calidad ya ofrecen Imunify360, incluso en servicio de hosting. Si aplicar el firewall implica cambiar de servidor tendremos un pequeño factor añadido: el cambio de la frecuencia de rastreo en el nuevo servidor, lo veremos más adelante.
- Revisar en Google Search Console si Google ha emprendido alguna acción manual, dentro del apartado Seguridad y acciones manuales → Problemas de seguridad, si nos hemos librado, bien, podemos continuar, si no, lee hasta el final donde especifico en el Plan B lo que debes hacer.
Referente al tipo de hackeo ya puede ser contenido SPAM dentro de tu web, URL que crean redirecciones engañosas, suplantan la identidad, distribuyen malware o muchas otras malas intenciones, el fin casi siempre es obtener ingresos en temáticas sensibles, utilizando dominios de terceros.
Lo que nos ocupa a nosotros como SEO es el rastro que esto deja este hackeo en Google, una vez limpia la instalación.
En cuanto a las URL hackeadas que se han indexado en Google, nos encontraremos con 3 escenarios posibles:
- URL nuevas creadas por el hackeo, limpias, sin parámetros
- URL ya existentes con parámetros nuevos creados por el hackeo
- URL de negocio ya existentes, sin parámetros, a las que, como las otras opciones, habían hackeado cambiándole el contenido o las han utilizado para redirecciones engañosas.
PASO 2 – Reindexación del contenido original
Empezamos por el último de los escenarios que hemos numerado. De hecho, es el peor de ellos porque afecta a las URL que nos proveen de mayor tráfico y por donde es más fácil que entre una penalización manual.
Actualización de URL de negocio con el title y la descripción correcta
En este escenario se han indexado el contenido y las metas del hackeo, y ha sucedido en páginas que representan el core del negocio, sobre todo si el hackeo ha permanecido indexando durante un tiempo sin que el propietario se entere. Son esas mismas URL que antes formaban parte de tu estrategia para vender online.
Páginas que ahora muestran en Google algo tan turbio como esto:
En este caso no podemos tirar de desindexación, sino que tenemos que corregir la indexación cuanto antes del contenido con sus metas originales y quitar de la caché de google todo el contenido, el title y la meta description que tanto les está perjudicando.
En el primer paso ya habremos verificado que no hay rastros del hackeo que genere el title ni meta description, es decir, si entramos en la URL y miramos el código fuente deberíamos encontrar el title y meta description correcta. Así que nuestra función aquí será empezar a dar señales a Google de que se ha actualizado el contenido y que el anterior tenía «información sensible» para decirlo finamente.
Se hace mediante la opción de Borrar URL almacenada en caché, dentro del apartado Índice → Retirada de URL en nuestro querido Google Search Console (nuestra herramienta principal):
Lo que hace la opción de borrar URL almacenada en caché es borrar la página en caché y borra el fragmento de descripción de la página en los resultados de búsqueda, hasta que la página se rastree de nuevo, cuando se generará el fragmento a partir del nuevo contenido.
Hasta el próximo rastreo, la meta description estará vacía en los resultados de búsqueda.
¡Oh! ¿Voy a dejar la meta description vacía?
¡Oh! ¿Y tengo que hacerlo una a una?
Siempre puedes hacerlo primero mediante directorios. Si has segmentado bien tu web y tienes un directorio para /marcas/, para /productos/, para /categorías/ u otro tipo de directorios, empieza retirando todas las que tengan ese prefijo, pero la portada y otras páginas relevantes que no contienen prefijos, no se escapan de hacerlas a mano.
En este paso lo que hemos hecho es limpiar las meta de las URL que están rankeando (si aún siguen haciéndolo) y que son el CORE de tu negocio. Una vez nos aseguramos que todas las URL relevantes ya hemos pedido limpiar caché, ahora pediremos eliminar todo el sobrante.
PASO 3 – Desindexación del contenido hackeado
Repasamos los dos escenarios que nos faltan por cubrir:
- URL nuevas creadas por el hackeo, limpias, sin parámetros, con su title y meta description.
- URL ya existentes con parámetros que pertenecen al hackeo.
Desindexar contenido con parámetros
En este paso, verificaremos lo que hay indexado en Google. Haciendo un site: de la web nos encontramos un panorama como este:
Lo primero que vamos a hacer es identificar patrones de URL y parámetros, para ver cómo podemos rastrear y obtener todas las URL que queremos desindexar. Tal y como hemos hecho en el paso anterior, vamos a atacar a las páginas nuevas y las que ha creado con parámetros.
¿Desindexar todo este contenido hackeado es estrictamente necesario?
Sí. Muchas veces el contenido hackeado que se mantiene indexado está en versión http:// , lo que afecta a la experiencia de página.
¿La experiencia de página es un factor de posicionamiento al que cada vez se le da más importancia?
Sí.
Además, mantener el contenido del hackeo indexado perjudica gravemente a la imagen de marca, ofrece señales a otros hackers sobre la vulnerabilidad de ese sitio… son todo ventajas.
¿Hace falta que siga? Bien, empezamos con la limpieza.
Empezamos con las URL con parámetros y los directorios.
En este paso lo que intentamos es quitar del índice un montón de URL con parámetros, es por esto que utilizar un rastreo con una herramienta como Screaming Frog nos puede ayudar mucho. En este rastreo deberemos conectarnos con la API de Google Search Console y en el apartado de Análisis de búsqueda, activar la opción de rastrear nuevas URL descubiertas en Google Search Console:
Gracias a este rastreo podremos encontrar que, en este caso, se han creado URL’s con patrones y se han indexado, tipo:
/mejorzapatos/tags/…
/blablabla.php?cid=
o incluso la URL original más el parámetro: ?cid=
Con el listado de patrones y URL’s haremos varias acciones, la mayoría de ellas en Google Search Console:
La primera acción añadiremos el directorio que hayamos detectado, en este caso mediante un path que se encuentre en primer nivel:en el apartado Índice → Retirada de URL’s de Google Search Console
Muchas veces será difícil hacer más que esto en este apartado, ya que los parámetros que te crean los ubican al final o en el medio de la URL (sería genial que en GSC se pudiera retirar la URL temporalmente, mediante un regex match), así que en este apartado únicamente podemos colocar sub carpetas/paths/directorios que queramos desindexar, como esta:
Esto es una desindexación temporal, no nos servirá para todas esas URL nuevas que ha creado el hackeo.
El siguiente paso será recuperar el rastreo en Screaming Frog, el cual seguramente estará a reventar de URL’s con parámetros, esas URL que queremos desindexar definitivamente.
Filtramos por HTML y exportamos el rastreo, y mediante una operación fácil de hacer en Google Sheets o en Excel filtraremos por los parámetros que hayamos detectado. Quitando todas las URL’s buenas y dejando las que queremos desindexar.
Completaremos este listado con URL que tengan los parámetros, que hemos identificado como hackeadas, y que se encuentren como «Indexada, no enviada en el sitemap» en el apartado de Cobertura de Google Search Console.
Una vez tengamos el listado de URL’s a desindexar, tenemos varias opciones que nos servirán para diferentes casos:
1.- Si tenemos la suerte de utilizar WordPress y Rank Math, y además tenemos el plugin de instant indexing del mismo Rank Math, iremos al apartado Instant indexing, seleccionaremos la opción Remove URL, pegaremos allí las URL que queremos desindexar y le daremos a Send to API, si sale todo bien, nos saldrá este mensaje. Es muy posible que, aún ejecutándose satisfactoriamente, no lo haga a la primera, así que un rastreo al cabo de unos días y volved a insistir.
La API de indexación de Google tiene un límite de 200 URL al día, serán 200 peticiones que podremos ir lanzando día tras día, y como habrás podido comprobar en la gráfica anterior, hay un día que la magia sucede y se elimina de golpe más URL de las que habías enviado hasta la fecha. Llámalo Machine Learning, o como te apetezca.
Desindexar URL con 410
En este escenario, el hackeo ha creado una URL completamente nueva, así que no nos compromete si nos la cargamos. Es el más espectacular de todos, por la cantidad de URL que te puedes encontrar.
TIP: Para hacer el filtrado de URL por código de error va muy bien utilizar la opción de Búsqueda avanzada en la tabla dentro de Screaming Frog.
La página ya no existe, la instalación ya está limpia y por esta razón la URL que el hackeo ha generado no debería existir. La mitad del trabajo ya está hecho, puesto que lo que antes era una URL con código 200 (código de respuesta correcto), ahora deberían darte un error 404.
¿Cuál es la misión en este apartado? Convertir estos errores 404 en 410 y enviar sitemap con un listado de todas esas URL que hemos convertido en 410.
Si las URL que te ha creado son completamente nuevas, no habrá problema, nos vamos al rastreo de Screaming Frog, filtramos todas esas URL que ya deberían ser errores 404, y las exportamos.
Con el listado de URL que ofrecen un 404 podemos exportarlo, hacer un Buscar y reemplazar el dominio por «redirect gone » y así creamos un listado de códigos 410 que añadiremos en el .htaccess mediante este código, añadiendo al final el tipo de documento:
Redirect gone /urlhackeada/
Redirect gone /urlhackeadisima/
ErrorDocument 410 default
Finalmente volvemos a Screaming Frog y creamos un sitemap.xml en el apartado Sitemaps → Sitemap XML con todos los errores 404 que habremos convertido en 410, y así lo enviamos a Google Search Console para que detecte el cambio en el código de respuesta:
- Únicamente seleccionaremos códigos 404 (esos mismos que habremos puesto en .htaccess como 410).
- Última modificación ponemos una fecha personalizada, por ejemplo la misma fecha o el día anterior que se realiza el sitemap.
- En el apartado frecuencia de cambio estableceremos siempre, para que lo rastree muy seguidamente.
Enviaremos este sitemap y lo especificaremos también en el robots.txt
¿Es necesario especificar un código 410?
Un error 404 es un error que puede ser ocasional, que claramente debemos arreglar si es una URL relevante, puede ser interpretado como un error, pero no es permanente. Pero cuando ponemos un 410 es de forma intencionada, así que el trato en cuanto al rastreo, en teoría, debería ser ligeramente diferente uno del otro.
Muchos de vosotros pensaréis, «que dé un error 404 o un código 410 es prácticamente igual», pero nos sirve, en el caso que haya enlaces externos que estén apuntando hacia estas URL (casi siempre es así) para indicar a Google que estas páginas no existen ni van a volver a existir. Muy útil si tu web ha sido afectada por una acción manual y tenemos que reportar todas las acciones que hemos emprendido.
Si hacemos todas las redirecciones 410 tenemos un registro de lo que se ha realizado en esa limpieza, listado que enviaremos a Google para que nos quite la penalización manual.
¿Un código 410 disminuye la frecuencia de rastreo a la URL más que un 404?
Es algo que debemos comprobar con los logs de acceso. Según mis hipótesis, dependerá de las señales externas que esta URL reciba, tráfico, enlaces externos, etc… Así que en cuanto a la frecuencia de rastreo depende más de la URL que del conjunto, pero como siempre, los logs de acceso del proyecto serán los únicos que tendrán una respuesta certera.
Ahora bien, ¿un código 410 desindexa más rápido que un 404?
«Ligeramente» a corto plazo según Google, imperceptible a largo plazo tiene un según este vídeo del tito John, este video de preguntas y respuestas donde reparte dependes como panes.
Y este soy yo mientras veo el vídeo de John: «Pues será que a corto plazo se refiere a las URL que no tienen tráfico ni señales, y a largo plazo las URL más difíciles de desindexar por todas las señales que recibe».
Total, los logs de tu proyecto son los únicos que tienen la respuesta más precisa a esta pregunta, también.
Otros métodos de desindexación y recomendaciones
Podemos utilizar otras combinaciones cómo: redirigir todas las URL’s del hackeo hacia una única URL mediante redirecciones permanentes 301, y a esa URL de destino especificarle un código 410.
Posteriormente, se puede cambiar de servidor para que modifique la frecuencia de rastreo, ya que muchas veces Google hace un rastreo general después de un cambio de servidor, y se puede aprovechar esta migración de servidor para que actualice el estado de muchas URL.
La frecuencia de rastreo una vez instalada la web en el servidor está claro que puede bajar: servidor nuevo, Google lanza rastreos con menos frecuencia con el fin de no perjudicar el performance. Pero el rastreo intensivo justo después de cambiar el servidor, casi siempre lo hace, según las estadísticas de rastreo que me muestra en Google Search Console, así que podemos aprovechar que hemos hecho todos estos cambios, y con este cambio de servidor forzar a que los rastree otra vez.
También podemos aprovechar para ir a un servidor más seguro, con Imunify360, con enjaulado de cuentas, certificados SSL, sistema antivirus, últimas versiones de php, backups diarios, todo ayuda.
Paso 4 – Enlaces entrantes negativos
Es seguro que el mismo atacante haya creado miles de enlaces entrantes a tu web, del mismo modo que tu web estaba lanzando miles de enlaces salientes hacia otras webs infectadas.
Mi recomendación en este caso es verificar con herramientas como Ahrefs, Semrush o Google Search Console que dominios estaban enlazando masivamente a los nuestros, hacer un listado y utilizar la herramienta disavow. Especificando en el disavow cada uno de los dominios, los cuales no queremos que nos relacionen.
En estos casos, y aprovechando que voy a mandar un listado de dominios a la herramienta disavow, dedico un tiempo para obtener/conseguir (aka comprar) otros de calidad para la web, de este modo estamos substituyendo unos de bajísima calidad, spam, por otros de alta calidad.
Si la web se ha visto afectada por una acción manual y quieres mantener el dominio
Imagínate que Google se ha enterado de que la web ha permanecido hackeada y ha emprendido una acción manual. Esto sería equivalente a la llegada de extraterrestres a los que les gustan las cabezas de humanos, después de un apocalipsis zombi.
Es fácil enterarte de una acción manual porque te envían una notificación al correo y en Google Search console hay un bonito aviso justo al entrar al proyecto que te avisa de ello.
En estos casos las webs que han estado afectados por una acción manual, bajan mucho sus posiciones o simplemente desaparecen de las SERP, y es aquí cuando tendremos que hacer todas las acciones anteriores para que, una vez hecha toda la limpieza, podamos pedir a los revisores de Google que revisen el contenido.
Verás que este caso lo pongo casi al final del post, y es que la razón es simple, que Google haya emprendido una acción manual, no cambia con todo el trabajo previo de limpieza que debemos hacer. Es más, si lo realizamos correctamente, podemos reportar a Google casi todas las acciones que hemos emprendido (menos la compra de enlaces).
Es aquí dónde podemos reportar a Google que hemos realizado redirecciones masivas a estados 410 de las URL, otra razón más para realizarlas y así poder quitarle esta acción manual a tu dominio.
Resumen y recomendaciones
Si tuviera que puntuar qué método me ha ofrecido mayor desindexación con la mayor velocidad es sin duda la utilización de la API de indexación, que en este caso la utilizo para desindexar. Es algo que podemos realizar fácilmente en WordPress con la ayuda de Rank Math.
Si no utilizas WordPress como CMS ni Rank Math, quizás podrías valorar crear una instalación en un directorio nuevo de tu dominio, instalando un WordPress completamente vacío con Rank Math + instant indexing y ejecutarlo desde allí, será más fácil y rápido que crear una solución a medida para tu CMS.
La solución de los códigos 410 está bien para esas URL que te crea completamente nuevas y que quieres eliminar, pero cuando te crea parámetros y te los indexa, lo mejor es la API.
Por último, si las páginas pilares, sin parámetros añadidos, se han infectado y están ofreciendo un title y descripción no deseados, no es recomendable desindexar, sino corregir la indexación, como hemos visto en el Paso 2.
Si no se ha llegado a tiempo, Google va a marcar con una cruz ese dominio mediante la acción manual, tienes cómo opción intentar mantener el dominio o realizar una migración de dominio. Con todo el trabajo de redirecciones que esto conlleva. Aquí tienes que valorar según branding, histórico, cantidad de enlaces del proyecto, y un largo listado de factores a considerar.
Y te parecerá una obviedad, pero antes de empezar a tirar de API o a emplear horas y horas intentando limpiar el índice de Google, pide accesos y verifica que la instalación está completamente limpia.
Spam de valor
Si necesitas que haga SEO después de que tu web esté hackeada, contacta conmigo aquí. Si necesitas que un profesional te limpie la instalación porque aún está hackeada, especifícalo en el contacto y te derivaré a colaboradores expertos en seguridad.
Con esto ya termino.
Habrás comprobado de la importancia de mantener tu sitio web seguro, ya que un hackeo puede arruinar cualquier acción de SEO, en este post tan personal sobre las necesidades de una web podrás ver qué prioridad le doy a la seguridad dentro de un proyecto.