Te hackearon la web: el reloj no es tuyo

Limpiar un sitio infectado puede llevar una tarde. Que te saquen el cartel de «sitio peligroso» puede llevar semanas, y eso no depende de vos. Esta página es para que entiendas de qué lado está cada reloj, hagas las cosas en el orden correcto y no cometas el error que más días de cartel cuesta: pedir la revisión antes de tiempo.

Tu sitio se ve bien. Y eso es parte del problema

La escena se repite casi igual todas las veces. Alguien te avisa —un cliente, un proveedor, un correo de Google— que tu sitio aparece marcado como peligroso o pirateado. Vos lo abrís, lo recorrés entero, está perfecto. Y la conclusión natural, que es la equivocada, es que se trata de un error.

Leer el detalle

No es un error, y hay una explicación bastante específica. Mucho contenido inyectado está hecho para mostrarle una cosa al visitante y otra distinta al buscador. La documentación pública de Google lo nombra y lo describe: quien entra a la página la ve normal, mientras el buscador recibe palabras y enlaces de spam. Dicho de otro modo: no estás mirando lo mismo que mira Google, así que tu inspección visual no prueba nada.

Hay una segunda variante, todavía más incómoda: la inyección aparece solo para quien llega desde una búsqueda, o solo desde el teléfono, o solo para quien no tiene la sesión abierta. Vos entrás escribiendo la dirección, logueado y desde tu computadora de siempre, que es exactamente el perfil al que la infección está programada para no mostrarse. Es el mismo fenómeno que hace que el dueño de un sitio sea el peor juez de su propia velocidad, pero acá en vez de costar visitas cuesta reputación.

Por eso esta página no empieza por cómo limpiar. Empieza por cómo mirar, porque en los casos que nos llegan la demora casi nunca fue técnica: fueron las dos o tres semanas que pasaron entre el primer aviso y el momento en que alguien se convenció de que el aviso era cierto.

Tres problemas distintos, y tres relojes distintos

Esta es la parte que casi nadie te explica y la que más conviene saber antes de prometerle una fecha a nadie. Según de qué se trate, el tiempo que tarda en levantarse la advertencia cambia de un día a varias semanas. El trabajo de limpieza puede ser parecido; la espera, no.

Spam inyectado

El más común por amplio margen y el más barato de limpiar. Te aparecen páginas que no escribiste —palabras sueltas, direcciones raras, enlaces a sitios que no conocés— y en los resultados figura una etiqueta diciendo que el sitio puede estar pirateado. Es también el que más tarda en resolverse del lado de Google: su documentación dice que la revisión de un sitio hackeado con spam puede tardar varias semanas, porque puede incluir una investigación manual. Limpieza corta, espera larga.

Software malicioso

Acá el navegador se mete en el medio: antes de que el visitante llegue a tu sitio le aparece una pantalla de advertencia a pantalla completa. Es el que más daño comercial hace en el corto plazo, porque nadie pasa esa pantalla. La contracara es que la espera es mucho más corta: la documentación de Google indica que estas revisiones tardan unos días. Es el caso en que apurar el trabajo de limpieza sí tiene sentido económico.

Suplantación de identidad

Alguien montó en tu dominio una página que imita a un banco, a una empresa de envíos o a un organismo, para pedirle datos a gente que confía. Es el más grave en términos de responsabilidad y el que exige moverse más rápido, porque el engaño sale con tu nombre. Según la documentación de Google, es también el de revisión más rápida: alrededor de un día. Si tu caso es este, cada hora que la página sigue arriba es una hora de gente engañada en tu dominio.

Leer el detalle

Cómo saber en cuál estás, gratis y en cinco minutos: el informe de problemas de seguridad de Search Console lo dice con nombre y te muestra direcciones de ejemplo donde se detectó el problema. Si nunca diste de alta el sitio en Search Console, darlo de alta es el primer paso de la lista que sigue. Fuentes: documentación pública de Google sobre sitios hackeados y sobre la solicitud de revisión, publicada en web.dev y en Google Search Central, consultada el 6 de octubre de 2026. Los plazos son los que declara Google para su propio proceso y pueden cambiar sin aviso.

  • Nueve pasos, y el orden importa más que la velocidad

    Están ordenados a propósito: primero los que no destruyen evidencia, después los que cortan el daño, y al final el que pide que alguien de afuera mire. Esto lo publicamos para que puedas usarlo aunque no nos contrates, y para que puedas controlar a quien contrates.

  • No borres nada todavía.

    Es el impulso más natural y el más caro. Si borrás archivos antes de saber qué pasó, perdés la única forma de encontrar por dónde entraron, y un sitio que se limpia sin cerrar la puerta se vuelve a infectar. Lo primero es mirar, no limpiar.

  • Sacá una copia del estado actual, infectado y todo.

    Archivos y base de datos, tal como están. No es para restaurarla: es para poder comparar después y para no quedarte sin nada si la limpieza sale mal. Guardala fuera del servidor, con la fecha en el nombre.

  • Mirá tu sitio como lo mira un desconocido.

    Desde el teléfono, con datos móviles, sin tu sesión abierta y llegando desde una búsqueda en vez de escribiendo la dirección. Es el único modo de ver lo que la infección le muestra al visitante y te esconde a vos.

  • Entrá al informe de problemas de seguridad de Search Console.

    Ahí dice de qué tipo de problema se trata y muestra direcciones de ejemplo. Es gratis, es la fuente oficial del cartel que te están poniendo y es lo que define cuál de los tres relojes te toca.

  • Cambiá las contraseñas, pero todas y en el orden correcto.

    Hosting y panel de control primero, después base de datos, después los usuarios del administrador del sitio, después el correo asociado. Si cambiás solo la del sitio y la entrada fue por el hosting, cambiaste la cerradura de una puerta mientras la otra sigue abierta.

  • Revisá la lista de usuarios con permisos y borrá los que no reconozcas.

    Es habitual encontrar un administrador creado hace semanas con un nombre creíble. Y mientras estás ahí, mirá también los que sí reconocés: el pasante de 2019 y la agencia anterior probablemente no necesiten seguir teniendo acceso.

  • Si tenés tienda y toma pagos, cortá primero y averiguá después.

    Una tienda infectada puede estar capturando datos de tarjetas en el formulario de pago sin que se note nada raro en la pantalla. Acá la regla cambia: es mejor tener la tienda cerrada unas horas que abierta y comprometida, y conviene avisarle a tu plataforma de cobro antes de que te avise ella.

  • Averiguá si el problema es tuyo o del vecino.

    En alojamiento compartido hay casos en que la infección entró por otro sitio del mismo servidor. Si en esa cuenta hay varios sitios tuyos, revisalos todos: limpiar uno y dejar los otros infectados es volver a empezar en una semana.

  • Pedí la revisión recién cuando estés seguro, y este es el paso que más se arruina.

    La documentación de Google es explícita: si solicitás una revisión y el problema todavía existe, lo único que lográs es prolongar el período en que tu sitio queda marcado como peligroso. O sea que apurarte no adelanta nada: te atrasa. Primero limpio y verificado, después el botón.

Lo que cuesta un hackeo no es la limpieza

Es la idea que más le cambia la cabeza a quien nos escribe por esto, y conviene decirla con los plazos de Google adelante: la limpieza es trabajo tuyo y lleva lo que lleva; el levantamiento de la advertencia es decisión de otro y lleva lo que decide.

Leer el detalle

Juntá las dos cosas y el cálculo cambia de forma. Un spam inyectado se puede limpiar en una tarde, pero la revisión puede tardar varias semanas; en ese tiempo tu sitio sigue apareciendo con la etiqueta puesta y tu competencia no. Un caso de software malicioso es más urgente para el visitante —la pantalla de advertencia espanta a todo el mundo— pero la revisión tarda unos días. Y una suplantación de identidad, que es la peor en términos de responsabilidad, se revisa en alrededor de un día.

La consecuencia práctica es incómoda pero útil: en el caso más frecuente, buena parte del daño ya está hecha antes de que llames a nadie. No porque no se pueda arreglar, sino porque la parte que lleva tiempo no se acelera pagando más. Lo que sí se puede hacer, y es lo único que de verdad mueve la aguja, es no reiniciar el reloj: una revisión pedida a medias, rechazada, y vuelta a pedir, es la forma más eficiente de convertir tres semanas en seis.

Por eso cuando alguien nos escribe un sábado con el cartel puesto, lo primero que le decimos no es «lo arreglamos hoy». Es: vamos a averiguar bien qué tenés antes de tocar algo, porque el apuro es exactamente lo que alarga la espera. Y si tu caso es de los que esperan semanas, conviene usar esas semanas para resolver el problema de fondo en vez de para mirar el informe todos los días.

Casi siempre es una de estas cinco, y ninguna es sofisticada

Dicho de frente porque alivia y porque orienta: en los sitios de empresas chicas y medianas que nos toca mirar, casi nunca hubo un ataque dirigido. Hubo un programa automático recorriendo direcciones a ciegas y encontrando una puerta vieja. Nadie te eligió. Eso no lo hace menos grave, pero sí lo hace mucho más prevenible.

01

Un complemento que quedó sin actualizar

La primera por amplio margen, y la que más tiene que ver con cómo está armado el sitio. Un sitio con doce complementos de terceros tiene doce calendarios de actualización que alguien tiene que seguir, y cuando se publica una falla de seguridad en uno de ellos, la ventana entre el anuncio y el ataque automático es corta. El problema no fue el complemento: fue que nadie tenía el trabajo de mirarlos.

02

Una contraseña reutilizada

La misma clave en el hosting, en el sitio y en un servicio cualquiera que tuvo una filtración hace dos años. No hace falta que te ataquen a vos: alcanza con que la clave esté en una lista. Es también la más barata de cerrar y la que más resistencia genera, porque obliga a cambiar una costumbre y no un archivo.

03

Un usuario viejo que nadie dio de baja

El que hizo el sitio, el que lo mantuvo después, el pasante que subía las fotos, la agencia que se fue. Todos con permisos de administrador y todos con la clave guardada en algún navegador que ya no controlás. Es la puerta más incómoda de hablar porque no es técnica: es administrativa. Si estás en esta situación, la pieza hermana es la del proveedor que no contesta.

04

Una plantilla o un complemento «liberado»

Esta aparece seguido y conviene nombrarla sin vueltas: una plantilla paga descargada gratis de un sitio cualquiera suele venir con algo adentro. No es mala suerte, es el modelo de negocio de quien la publicó. Lo difícil del caso es que el sitio nunca funcionó mal, así que nadie lo relaciona: la puerta estuvo abierta desde el día uno.

05

El vecino del alojamiento compartido

En un plan compartido tu sitio convive con otros, y según cómo esté configurado el servidor, una infección en uno puede alcanzar a los demás. Es la única de las cinco que no depende de tus decisiones sino de las de tu proveedor, y es la razón por la que, cuando revisamos un caso así, lo primero que preguntamos es cuántos sitios hay en esa cuenta.

Limpiar y dejarlo igual es volver a empezar

Es la decisión que define el presupuesto y la que más se toma mal, porque la opción barata parece la obvia. La diferencia entre las dos no está en cuánta suciedad hay: está en si la puerta por la que entraron se puede cerrar de verdad.

Cuándo alcanza con limpiar

Cuando la puerta de entrada se identifica, se cierra y el resto del sitio está sano: un complemento viejo puntual, una clave filtrada, un usuario de más. Se reconoce porque se puede nombrar qué falló. Ahí el trabajo es acotado: se saca lo inyectado, se cierra la entrada, se verifica que no quedó nada escondido y se pide la revisión una sola vez. Si además hay una copia limpia anterior que alguien probó restaurar, mejor todavía.

Cuándo lo honesto es levantar limpio

Cuando no se puede decir por dónde entraron, cuando hay doce complementos sin sostén y ninguno se puede quitar sin romper algo, cuando el sitio ya se infectó antes, o cuando nadie tiene todos los accesos. En esos casos limpiar es comprar tiempo: vuelve a pasar. Lo que hacemos nosotros es rescatar el contenido, dejarlo en una base más limpia que el equipo del cliente pueda operar, y no sostener la misma estructura que ya falló.

Leer el detalle

Y una aclaración de alcance que preferimos dar antes y no después: no vendemos limpieza de infecciones como servicio suelto ni hacemos análisis forense, y no prometemos devolver un sitio infectado a su estado anterior en el mismo lugar donde está. Lo que hacemos es mirar, decirte en cuál de los dos casos estás, y ejecutar el camino que corresponda, que en la mayoría de los que nos llegan es recuperar el contenido y mudarlo a algo que no se vuelva a romper solo. Si lo tuyo se arregla sin nosotros, te lo decimos: está más abajo, en la sección de precios.

No todo cartel rojo es un hackeo

Vale la pena distinguirlo antes de asustarse, porque tres situaciones bastante distintas producen avisos parecidos y se resuelven de maneras que no se parecen en nada, ni en tiempo ni en plata.

Leer el detalle

Si el navegador dice «no es seguro» pero el sitio abre y se ve bien, lo más probable es que sea el certificado y no una infección. Es la falla más frecuente de todas, se arregla en minutos y no tiene nada que ver con esta página: está explicada en la del certificado vencido. La señal que las separa es simple: el aviso del certificado aparece siempre, para todos y en la barra de direcciones; el de sitio peligroso aparece en los resultados de búsqueda o como pantalla completa antes de entrar.

Si el sitio directamente no abre —error de servidor, pantalla en blanco, «no se puede acceder»— eso es una caída y no un hackeo, aunque a veces una termina en la otra. El orden de los primeros pasos es distinto y está en la página de la web caída, que es la madre de todo este cluster.

Y si tu sitio simplemente dejó de aparecer en Google, sin cartel y sin advertencia, hay varias explicaciones mucho más comunes que un ataque. Esa es otra conversación y está en mi sitio no aparece en Google. La diferencia clave: un sitio hackeado suele seguir apareciendo, pero con la etiqueta puesta; un sitio desindexado desaparece sin que nadie te avise nada.

Precios, y el caso en que te decimos que no

Como en todo el resto del sitio, los números están publicados. Y como en el resto del cluster de rescate, también está publicado el caso en el que lo más honesto es que no nos contrates.

El sitio no se infectó por descuido. Nadie era dueño de la actualización

Es el patrón que encontramos abajo de casi todos los casos y no tiene nada de técnico. Preguntale a cualquiera de los involucrados quién tenía que actualizar los complementos y la respuesta va a ser la misma de siempre: yo pensaba que lo hacía el otro.

Leer el detalle

La secuencia es casi idéntica todas las veces. El sitio se entregó funcionando y nadie habló de qué pasaba después. La empresa supuso que actualizar era parte de tener un sitio, igual que la luz viene con el local. Quien lo hizo supuso que el proyecto terminó cuando se aprobó el diseño. El hosting mandó dos o tres correos de aviso que llegaron a una dirección que ya nadie abre. Y durante dieciocho meses el sitio funcionó perfecto, que es precisamente lo que hace que nadie revise nada: no hay síntoma, no hay recordatorio, no hay factura que obligue a mirar.

Y acá está el punto incómodo, porque es una decisión de arquitectura y no de disciplina: un sitio armado sobre doce piezas de terceros necesita un dueño de la actualización, y uno armado sobre menos piezas necesita mucho menos dueño. Cuando cada necesidad chica se resolvió sumando un complemento —un formulario, un carrusel, un chat, un medidor— lo que se construyó no fue un sitio: fue una lista de mantenimientos ajenos. Es el mismo mecanismo que vuelve lento a un sitio que arrancó liviano, y el mismo que hace que un sitio que nadie toca hace años sea una bomba de tiempo en vez de un sitio estable.

Por eso cuando terminamos un rescate no entregamos solamente el sitio limpio. Entregamos quién actualiza qué, cada cuánto, y a quién se le reclama cuando algo falla, escrito y con nombre. Si esa pregunta no tiene respuesta, no importa cuán limpio quede hoy: en dieciocho meses estás leyendo esta misma página otra vez. Para tiendas, además, es una de las razones por las que hacemos e-commerce únicamente en Shopify: cuando algo se cae un sábado, lo que importa no es de quién es la culpa sino a quién se le reclama.

Sitios hackeados en Uruguay: lo que más nos llega

Somos una empresa uruguaya y los casos que nos llegan tienen un par de rasgos bastante locales que vale nombrar, porque cambian qué conviene hacer primero.

Leer el detalle

El primero es de tamaño: en una empresa de diez o quince personas no hay nadie cuyo trabajo sea mirar el sitio, y eso no es negligencia, es aritmética. El que podría hacerlo está facturando, atendiendo el mostrador o cerrando el mes. De ahí que el aviso casi nunca llegue por un monitoreo propio sino por un cliente que escribe para preguntar si pasó algo, o por un correo de Google que estuvo sin abrir cuatro días en una casilla de contacto genérica. Primera recomendación concreta y gratis: que la cuenta de Search Console esté a nombre de una persona que lee su correo todos los días, no de una dirección que mira todo el mundo y nadie.

El segundo es de infraestructura: mucho sitio uruguayo de PYME vive en planes de alojamiento compartido muy económicos, con varios sitios de la misma empresa en una sola cuenta —la web institucional, una landing de una campaña vieja, el sitio del emprendimiento del socio—. Cuando llega una infección, el error más caro es limpiar el sitio que importa y dejar los otros dos arriba. Si estás en esa situación, hacé el inventario antes que la limpieza: no se puede cerrar una casa mirando una sola puerta.

Y el tercero es de calendario, y pega especialmente en los negocios de temporada: si tu facturación se concentra entre diciembre y febrero, un cartel de sitio peligroso en noviembre es un problema de otra categoría, porque la espera de la revisión puede comerse el único período del año en que te buscan. En esos casos el consejo es el opuesto al intuitivo: no toques nada hasta tener claro el tipo de problema, porque una revisión rechazada en noviembre se paga en enero. Atendemos desde Montevideo a empresas de todo el país —Canelones, Maldonado, Salto, Paysandú, Colonia— y trabajamos sobre WordPress y sitios a medida.

Escribinos por WhatsApp al +598 97 532 651 o a comercial@biomadigital.com, cualquier día y a cualquier hora: te respondemos apenas lo vemos. Si todavía estás juntando información, las dos páginas que más ayudan al lado de esta son la de los accesos perdidos y la de cuánto sale rescatar una web.

Te contesta alguien en hora de Montevideo

Contanos qué dice el cartel, antes de tocar nada.

Con la dirección del sitio, qué tipo de problema figura en el informe de seguridad y si tenés los accesos del hosting, ya tenemos casi todo. Con eso te decimos si tu caso lo resuelve más rápido quien te hizo el sitio, si conviene una revisión, o si lo honesto es levantar el contenido y mudarlo a algo que no se vuelva a romper. Escribinos cualquier día y a cualquier hora: te respondemos apenas lo vemos.

  • Sin compromiso
  • Te respondemos por WhatsApp
  • Si no te conviene contratar, te lo decimos

Empezá por acá

¿Tenés los accesos?
Prefiero el formulario completo

Preguntas sobre sitios hackeados

¿Cuánto tarda en desaparecer la advertencia de «sitio peligroso»?

Depende del tipo de problema, y la diferencia es grande. Según la documentación pública de Google, las revisiones de suplantación de identidad tardan alrededor de un día, las de software malicioso unos días, y las de un sitio hackeado con spam pueden tardar varias semanas porque pueden incluir una investigación manual. Son plazos que Google declara para su propio proceso y pueden cambiar. Lo importante es que ese tiempo no se acelera pagando más: lo único que podés controlar es no reiniciar el reloj pidiendo la revisión antes de que el sitio esté realmente limpio, porque una revisión rechazada prolonga el período en que el sitio queda marcado.

Entro a mi sitio y se ve perfecto. ¿Seguro que está hackeado?

Puede estar hackeado igual, y es el caso más frecuente de todos. Mucho contenido inyectado está hecho para mostrarle una cosa al visitante y otra al buscador, o para aparecer solo ante quien llega desde una búsqueda, desde el teléfono o sin la sesión abierta. Vos entrás escribiendo la dirección, logueado y desde tu computadora de siempre, que es exactamente el perfil al que la infección está programada para no mostrarse. La forma de verificarlo sin adivinar es el informe de problemas de seguridad de Search Console, que te dice de qué tipo de problema se trata y te muestra direcciones de ejemplo.

¿Lo primero que tengo que hacer es borrar los archivos infectados?

No, y es el impulso más caro. Si borrás antes de saber qué pasó, perdés la posibilidad de encontrar por dónde entraron, y un sitio que se limpia sin cerrar la puerta de entrada se vuelve a infectar en semanas. El orden que recomendamos es: sacar una copia del estado actual aunque esté sucio, mirar el sitio como lo mira un desconocido, entrar al informe de seguridad para saber de qué tipo de problema se trata, cambiar todas las contraseñas empezando por el hosting, revisar la lista de usuarios con permisos, y solo después limpiar. Pedir la revisión es siempre el último paso.

Tengo una tienda online y creo que está infectada. ¿La cierro?

Si toma pagos, sí: en ese caso preferimos el corte antes que la averiguación. Una tienda comprometida puede estar capturando datos de tarjetas en el formulario de pago sin que se vea nada raro en la pantalla, y unas horas cerrada cuestan mucho menos que eso. Conviene además avisarle a tu plataforma de cobro antes de que te avise ella. Es también una de las razones por las que hacemos e-commerce únicamente en Shopify: cuando la plataforma y el sistema de pago responden a una sola empresa, hay a quién reclamarle un sábado.

¿Ustedes limpian el malware de mi sitio?

No vendemos limpieza de infecciones como servicio suelto ni hacemos análisis forense, y preferimos decirlo antes que después. Lo que hacemos es una revisión de diagnóstico de USD 90 más IVA que mira qué tenés, de qué tipo es el problema, por dónde entraron si se puede determinar y qué conviene hacer en qué orden, y termina en un informe escrito que queda tuyo. A partir de ahí hay dos caminos: si la puerta de entrada se identifica y se puede cerrar, el trabajo es acotado; si no se puede determinar o el sitio ya se infectó antes, lo honesto es recuperar el contenido y llevarlo a una base más limpia. Las dos cosas se cotizan por caso.

Me hackearon una vez y lo arreglamos. ¿Por qué volvió a pasar?

Porque lo más probable es que se haya limpiado la suciedad sin cerrar la entrada. Las cinco puertas que encontramos casi siempre son un complemento sin actualizar, una contraseña reutilizada, un usuario viejo con permisos de administrador que nadie dio de baja, una plantilla o un complemento descargado gratis de un sitio cualquiera, y en alojamiento compartido la infección de otro sitio del mismo servidor. Si el sitio se infectó más de una vez, el problema casi nunca es de limpieza: es que nadie es dueño de la actualización, y eso no se resuelve limpiando otra vez.

El navegador dice «no es seguro». ¿Me hackearon?

Probablemente no. Si el sitio abre, se ve bien y el aviso aparece siempre y para todo el mundo, lo más común por amplio margen es que sea el certificado vencido o mal instalado, que se arregla en minutos y no tiene nada que ver con una infección. La señal que las separa es dónde aparece el aviso: el del certificado aparece en la barra de direcciones y para todos; el de sitio peligroso aparece en los resultados de búsqueda como una etiqueta, o como una pantalla de advertencia completa antes de que el visitante llegue a entrar.

Se infectó el sitio y no tengo los accesos del hosting. ¿Qué hago?

Es una situación bastante común y cambia el orden de todo, porque sin acceso no se puede ni mirar ni limpiar. Lo primero no es técnico sino de titularidad: hay que reconstruir quién figura como titular del dominio y de la cuenta de alojamiento, qué correo recibe los avisos y quién contrató qué. Eso está explicado paso a paso en nuestra página sobre accesos perdidos. Mientras no se resuelva, no sirve apurar la limpieza, y tampoco conviene pedir la revisión: sin control del servidor no hay forma de garantizar que el problema esté resuelto.

Hasta dónde llega lo que hacemos

Bioma es una empresa de soporte tecnológico para PYMEs. No somos una empresa de seguridad informática: no hacemos análisis forense, no perseguimos a nadie, no auditamos redes ni equipos, y no vendemos limpieza de infecciones como servicio suelto. Tampoco damos asesoramiento legal: si hubo datos de clientes comprometidos y querés saber qué obligaciones te corresponden, eso lo contesta tu asesor y no nosotros. Lo nuestro es que la parte que vive en la web quede resuelta y la pueda operar tu equipo sin depender de un programador.

Leer el detalle

Para diagnosticar entramos a hostings y paneles de terceros sin problema. Para dar soporte continuo, el sitio tiene que vivir en nuestro hosting, y lo decimos de frente y no en la letra chica: sobre una infraestructura que no controlamos no podemos comprometernos a restaurar nada. El dominio no se toca: queda a tu nombre, como corresponde. Hay casos que revisamos y decidimos no tomar, y cuando pasa lo avisamos con el informe en la mano.

En esta página no hay estadísticas de ataques, porcentajes de sitios infectados ni estudios citados: no tenemos datos propios para sostenerlos y no citamos ajenos sin poder verificarlos. Las únicas referencias externas son las categorías de problemas de seguridad, el comportamiento del contenido inyectado que se muestra distinto al buscador, el informe de problemas de seguridad de Search Console y los plazos declarados de revisión —alrededor de un día para suplantación de identidad, unos días para software malicioso y varias semanas para spam—, tomados de la documentación pública de Google en web.dev y en Google Search Central y consultados el 6 de octubre de 2026. Son los plazos que Google declara para su propio proceso: es la fuente autorizada sobre su funcionamiento, no la verificamos contra una fuente independiente porque no existe una mejor, y pueden cambiar sin aviso. Conviene mirarlos en el informe el día que te toque. Los únicos números propios son nuestros precios.