Screaming Frog: las funciones que uso y recomiendo

Las funciones de Screaming Frog que cambiaron mi forma de hacer análisis técnico, y por qué dejé las alternativas para trabajo agéntico desde su servidor MCP de 2026.

Screaming Frog SEO Spider es una aplicación de escritorio que recorre un sitio como lo haría un buscador, sigue los enlaces, descarga cada URL y devuelve su estado técnico en una tabla. Es la herramienta con la que empieza casi cualquier auditoría, y la segunda más usada del rubro después de Search Console.

La distancia entre instalarlo y sacar una auditoría que sirva está en un puñado de funciones que hay que configurar, no en la cantidad de pestañas que trae. Esas funciones deciden si el informe describe el sitio o explica lo que le pasa.

Empecé a usarlo en 2019, en la versión 11, cuando la novedad de esa entrega era la validación de datos estructurados. Hoy va por la 24. En el camino se sumaron funciones muy buenas, y tres cambiaron de verdad mi forma de trabajar: el JavaScript personalizado y los n-gramas, que llegaron juntos en mayo de 2024, y el servidor MCP, en mayo de 2026.

La versión gratuita de Screaming Frog no sirve para auditar

La versión gratuita rastrea hasta 500 URL por crawl y no pide registro. Eso alcanza para mirar un sitio pequeño por encima, y esa es toda su utilidad.

Sin licencia solo alcanza para siete cosas: detectar enlaces rotos y redirecciones, leer títulos y metadatos, revisar meta robots y directivas, comprobar hreflang, encontrar duplicados exactos, generar sitemaps XML y usar las visualizaciones. Todo lo que uso cuando audito el sitio de un cliente exige licencia.

• Configurar el crawl: acotar qué rastrea, hasta dónde llega y con qué reglas.
• Guardar y reabrir un crawl, que es lo que permite trabajarlo en dos sesiones y compararlo con el del mes pasado.
• Renderizar JavaScript, imprescindible en la mayoría de los sitios de hoy.
• Extraer y buscar dentro del código con XPath, selectores CSS o expresiones regulares.
• Conectar Analytics, Search Console y PageSpeed Insights al mismo crawl.
• Comparar dos crawls, segmentar el sitio por tipo de página y tener soporte técnico.

La licencia cuesta 279 dólares al año por usuario, con descuentos por volumen desde cinco licencias. Comparada con lo que cuesta una hora de consultoría, la discusión sobre el precio dura poco. La discusión real es qué se hace con ella.

Las funciones que marcan la diferencia en una auditoría

Acá doy por hecho que ya usas Screaming Frog. La mayor parte de sus funciones no las voy a explicar: vienen preconfiguradas de fábrica, se entienden solas y hacen lo que prometen.

Si recién estás partiendo y lo que necesitas es aprender la herramienta desde cero, el mejor camino son los tutoriales oficiales de Screaming Frog, que ordenan la curva de aprendizaje mucho mejor de lo que podría hacerlo un resumen mío.

Las que de verdad importan son menos. Ninguna sirve sin configurarla antes, ninguna es evidente la primera vez que se abre, y son las que llevan el análisis técnico un paso más allá: cambian la profundidad del diagnóstico y la calidad de los accionables que llegan al entregable.

Renderizado de JavaScript: comparar lo que sirve el servidor con lo que ve el navegador

En Configuration, Spider, Rendering elijo entre texto plano y JavaScript. En modo JavaScript la herramienta ejecuta la página en su Chromium y rastrea el HTML resultante, sin dejar de leer los enlaces del HTML crudo.

Lo que de verdad uso no es el renderizado en sí, es la comparación. La pestaña JavaScript enfrenta las dos versiones columna por columna: título, meta descripción, encabezado principal, canonical, meta robots y recuento de palabras en crudo contra renderizado, más los enlaces que solo existen después de ejecutar el script.

En un retailer grande esa comparación resolvió una discusión que llevaba semanas. El equipo veía los títulos correctos en el navegador y yo los veía vacíos en el crawl. No era un error de la herramienta ni del equipo: el HTML que entregaba el servidor llegaba sin ese dato en un puñado de fichas, y solo el JavaScript lo completaba después. Con las dos columnas lado a lado dejó de ser mi palabra contra la suya y pasó a ser un hallazgo con evidencia.

Extracción personalizada: convertir el sitio en una base de datos

La extracción personalizada recoge cualquier dato del HTML mediante XPath, selector CSS o expresión regular, y lo devuelve como una columna nueva junto al resto del crawl. Admite XPath de la versión 1.0 a la 3.1 y permite sacar el elemento completo, su HTML interno, solo el texto o el valor de una función, por ejemplo cuántos encabezados principales tiene cada página. El techo son 100 extractores y 1.000 extracciones en total.

Es la función que más uso y la que más lejos llega. Con ella saco el precio y la disponibilidad de cada ficha, el autor y la fecha de cada artículo, el bloque de preguntas frecuentes, la etiqueta de categoría o el identificador interno que el equipo de desarrollo dejó en un atributo. Lo que sale de ahí es una tabla que se cruza con lo que sea.

El caso que mejor lo explica es el de un retailer de mejoramiento del hogar. Extraje el texto de las páginas de categoría y lo comparé contra el catálogo real, consultado aparte por su API. De cincuenta páginas, quince prometían productos que el catálogo no tenía. No era un problema de SEO técnico ni de redacción: era una promesa incumplida en la página que recibe al comprador. Ningún informe estándar de la herramienta marca eso, porque no es un error, es una contradicción entre dos fuentes. La extracción es la que permite ponerlas frente a frente.

Desde la versión 19 hay un selector visual: se abre la página en el navegador incorporado, se hace clic en el elemento y la herramienta propone la expresión y muestra qué devolvería. Acorta mucho el ensayo y error con XPath.

Búsqueda personalizada: saber en qué páginas del sitio aparece algo

La búsqueda personalizada vive en Config, Custom, Search, justo al lado de la extracción personalizada, y se confunde con ella todo el tiempo. El motivo es entendible: las dos miran dentro del código de cada página que se rastrea, las dos se configuran con reglas que se escriben a mano y las dos aceptan expresiones regulares.

La diferencia no está en cómo se configuran, sino en qué devuelven. Una dice dónde aparece algo y la otra dice cuánto vale ese algo en cada página.

La uso para preguntas de inventario, no de datos: en qué páginas quedó el píxel de una herramienta que el cliente dejó de pagar, cuáles siguen nombrando una marca que ya no distribuye, dónde aparece un aviso legal que legal mandó a cambiar. La regla con la que no me confundo es esta: si quiero saber dónde está algo, búsqueda; si quiero el dato en sí, extracción.

N-gramas: la forma más rápida de encontrar enlaces internos que faltan

Es la función que menos aparece en las guías y la que más tiempo me ahorra. Se selecciona un grupo de URL en la pestaña Internal y abajo se abre la pestaña N-grams, que muestra las frases que se repiten en ese conjunto, desde una palabra hasta seis, con su frecuencia en el cuerpo del texto, en los encabezados, en el título y en el texto ancla de los enlaces entrantes.

La columna que importa para enlazado interno es la de las apariciones sin enlazar. Ahí está, listado, cada lugar donde el sitio ya nombra un término y no lo enlaza a la página que debería recibir esa autoridad. Lo que antes era buscar a mano con el buscador del navegador, página por página, pasa a ser una tabla ordenada por frecuencia.

El flujo que sigo es siempre el mismo. Marco la sección que quiero trabajar, filtro por los términos objetivo con una expresión regular separada por barras verticales, ordeno por apariciones sin enlazar y de ahí sale la lista de enlaces a crear, priorizada por volumen y no por corazonada. En un blog con cientos de artículos, eso es la diferencia entre un plan de enlazado que se ejecuta y uno que queda en un documento.

Exige dos cosas fáciles de olvidar: activar el almacenamiento del HTML y del HTML renderizado en Config, Spider, Extraction antes de rastrear. Sin eso la pestaña aparece vacía y no hay forma de recuperarla sin volver a crawlear.

JavaScript personalizado: pedirle a cada página algo que la herramienta no trae

Desde la versión 20 se pueden inyectar fragmentos de JavaScript que corren en cada página del crawl y devuelven lo que uno quiera como columna. Está en Configuration, Custom, Custom JavaScript, con dos botones: uno para escribir el fragmento y otro para tomarlo de la biblioteca que trae la propia herramienta. El fragmento corre sobre cada URL interna que responde 200, salvo PDF, y devuelve el resultado con seoSpider.data, o el error con seoSpider.error.

Con eso el crawler deja de estar limitado a lo que el fabricante decidió medir. Se puede llamar a una API externa desde cada página, disparar un evento para cargar contenido que aparece al desplazar, o calcular algo a partir del texto. El que más uso es el de embeddings.

Extraer embeddings de cada página con la API de OpenAI

Un embedding es la representación numérica del significado de un texto: un vector largo donde dos textos que hablan de lo mismo quedan cerca aunque no compartan ni una palabra. Traer ese vector al crawl convierte una tabla de URL en algo que se puede comparar por significado y no por coincidencia de términos.

Este es el fragmento que uso. Se pega tal cual en el cuadro de JavaScript personalizado, se reemplaza la clave de la primera línea por una propia de OpenAI y listo: cada URL del crawl devuelve su vector en una columna.

const OPENAI_API_KEY = 'tu_api_key_aqui';
const userContent = document.body.innerText;

function chatGptRequest() {
    if (new TextEncoder().encode(userContent).length > 8191) {
        // Divide el contenido en trozos manejables
        function chunkString(str, size) {
            const numChunks = Math.ceil(str.length / size);
            const chunks = new Array(numChunks);

            for (let i = 0, o = 0; i < numChunks; ++i, o += size) {
                chunks[i] = str.substring(o, o + size);
            }
            return chunks;
        }

        const chunks = chunkString(userContent, 8191);

        // Pide los embeddings de todos los trozos en una sola llamada
        function chatGptBatchRequest(chunks) {
            return fetch('https://api.openai.com/v1/embeddings', {
                method: 'POST',
                headers: {
                    'Authorization': `Bearer ${OPENAI_API_KEY}`,
                    "Content-Type": "application/json",
                },
                body: JSON.stringify({
                    model: "text-embedding-3-small",
                    input: chunks,
                    encoding_format: "float",
                })
            })
            .then(response => {
                if (!response.ok) {
                    return response.text().then(text => { throw new Error(text); });
                }
                return response.json();
            })
            .then(data => {
                if (data.data.length > 0) {
                    const numEmbeddings = data.data.length;
                    const embeddingLength = data.data[0].embedding.length;
                    const sumEmbedding = new Array(embeddingLength).fill(0);

                    data.data.forEach(embed => {
                        embed.embedding.forEach((value, index) => {
                            sumEmbedding[index] += value;
                        });
                    });

                    const averageEmbedding = sumEmbedding.map(sum => sum / numEmbeddings);
                    return averageEmbedding.toString();
                } else {
                    throw new Error("No embeddings returned from the API.");
                }
            });
        }

        return chatGptBatchRequest(chunks);
    } else {
        return fetch('https://api.openai.com/v1/embeddings', {
            method: 'POST',
            headers: {
                'Authorization': `Bearer ${OPENAI_API_KEY}`,
                "Content-Type": "application/json",
            },
            body: JSON.stringify({
                model: "text-embedding-3-small",
                input: userContent,
                encoding_format: "float",
            })
        })
        .then(response => {
            if (!response.ok) {
                 return response.text().then(text => {throw new Error(text)});
            }
            return response.json();
        })
        .then(data => {
            console.log(data.data[0].embedding);
            return data.data[0].embedding.toString();
        });
    }
}

// Ejecuta la petición y devuelve el resultado al crawl
return chatGptRequest()
    .then(embeddings => seoSpider.data(embeddings))
    .catch(error => seoSpider.error(error));

Con esa columna hago cuatro cosas, todas con clientes reales.

• Medir relevancia semántica: comparo el vector de cada página contra el de la consulta que quiero ganar y ordeno por cercanía. Así se ve qué página es la candidata natural para un término y si el sitio tiene una sola página relevante o cinco compitiendo entre ellas.
• Detectar canibalización de verdad: dos páginas con vectores casi idénticos compiten, aunque sus títulos parezcan distintos. Es un criterio mucho más fiable que comparar palabras clave.
• Mapear redirecciones en una migración: para cada URL que se va, la de destino es la más cercana por significado. En sitios grandes eso convierte un trabajo manual de semanas en una propuesta que se revisa y se corrige.
• Encontrar contenido pobre: las páginas cuyo vector queda lejos del promedio del sitio suelen ser las de poco texto, las plantillas vacías o las que se salieron del tema.

Desde la versión 22 la herramienta también calcula embeddings por su cuenta y trae similitud semántica y búsqueda por significado dentro de la interfaz. Sigo usando el fragmento cuando quiero el vector crudo para trabajarlo fuera: cruzarlo con páginas de la competencia, guardarlo en una planilla o alimentar un script propio. Para mirar el sitio por dentro, lo nativo alcanza y sobra.

Comparación de crawls: qué cambió desde la última vez

Disponible desde la versión 15, exige licencia y modo de base de datos. Compara dos crawls del mismo sitio y clasifica cada URL en cuatro estados que no son sinónimos: añadida y eliminada son URL presentes en ambos crawls que entraron o salieron de un filtro, mientras que nueva y ausente son URL que solo existen en uno de los dos.

La uso en dos momentos. Después de un despliegue, para comprobar que no se llevó por delante lo que no debía, y en una migración, para ver qué quedó en el camino. La pestaña de detección de cambios vigila catorce elementos, entre ellos indexabilidad, título, encabezado principal, profundidad de clic y enlaces entrantes, más un filtro que marca las páginas cuyo contenido cambió más de un 10%.

Segmentación: dejar de auditar un sitio como si fuera uno solo

Agrupo las URL por sección o por tipo de plantilla, y esa división se propaga a todo: a las columnas, a la pestaña de problemas, a las visualizaciones, a los sitemaps que se generan y a las hojas del informe para Looker Studio. En un ecommerce cambia la lectura por completo, porque el mismo error pesa distinto en las fichas de producto que en el blog, y el promedio del sitio entero esconde justamente eso.

Páginas huérfanas: las que existen y nadie enlaza

El crawler clasifica como huérfana toda URL sin ningún camino de enlaces desde el punto de partida. Por definición el crawl solo no puede descubrirlas: hacen falta fuentes externas, y son exactamente tres, los sitemaps XML, la API de Analytics y la API de Search Console.

En una tienda de artículos de cuchillería aparecieron así decenas de categorías que existían, recibían visitas y no estaban en ningún sitemap ni enlazadas desde la navegación. Nadie las había borrado: simplemente quedaron fuera cuando cambió el menú. Con el listado en la mano, recuperar esas páginas fue un trabajo de dos semanas con retorno inmediato.

Hay un paso que se olvida siempre: después del crawl hay que ejecutar el análisis final, o marcar que se ejecute solo al terminar. Sin eso los filtros de huérfanas quedan vacíos aunque las APIs estén conectadas.

Exportaciones masivas: la sábana que la interfaz no muestra

Los menús de Bulk Export e Informes sacan en un CSV mucho más de lo que se ve en pantalla. La exportación de todos los enlaces entrantes, por ejemplo, devuelve una fila por cada enlace encontrado en el sitio, con la página de origen, el destino, el texto ancla, el tipo de enlace, el código de respuesta y si es follow. En la interfaz esos datos están repartidos entre pestañas y paneles inferiores, y ahí llegan juntos y cruzables.

No es un recurso para una auditoría inicial ni para ver el estado general del SEO técnico de un sitio, y por eso casi nunca aparece en las guías. Es una herramienta para preguntas muy concretas, de esas donde la interfaz se queda corta. Algunos de los casos en los que la he usado:

• Migraciones: saber exactamente qué páginas enlazan a cada URL que se va, para no dejar enlaces apuntando a una redirección o a un error.
• Revisión de códigos de respuesta internos: sacar todos los enlaces que apuntan a 404 o a redirecciones, con su página de origen, que es el dato que permite corregir en vez de solo reportar.
• Enlaces internos absolutos: localizar cuáles apuntan al dominio completo en lugar de usar rutas relativas. Es el trabajo previo que evita que un cambio de dominio, un salto a un subdominio o el paso a HTTPS deje medio sitio enlazando al lugar equivocado, y también el que permite limpiar los que quedaron mal después de una migración.
• Podas de contenido: antes de borrar o redirigir un lote de páginas, saber desde dónde se enlaza cada una. Es lo que impide que la poda deje decenas de enlaces internos apuntando al vacío.

El patrón es siempre el mismo: el trabajo no termina en la lista de páginas con problema, sino en la lista de lugares donde hay que ir a corregir. Esa segunda lista casi siempre sale de una exportación masiva y no de la pantalla.

Modo lista: auditar un conjunto cerrado de URL

Rastrea solo las URL que se le entregan, pegadas a mano, subidas en un archivo o tomadas de un sitemap. Es el modo con el que verifico un lote de redirecciones antes de una migración, reviso las URL que Search Console reporta como excluidas o compruebo un grupo de páginas nuevas sin rastrear el sitio completo. También es donde pruebo cualquier fragmento de JavaScript personalizado antes de soltarlo sobre todo el dominio.

Las integraciones que convierten el crawl en un diagnóstico

Un crawl describe el sitio tal como está. No sabe qué páginas reciben tráfico ni cuáles están indexadas. Las integraciones de API traen esa capa y se conectan antes de lanzar el crawl, para que los datos lleguen pegados a cada URL.

La única cuota con cifras públicas es la de PageSpeed Insights: 25.000 consultas al día y 36 URL por minuto, lo que significa unas cuatro horas y media para diez mil URL. Conviene lanzarlo sobre una muestra o sobre un segmento, no sobre el sitio completo.

Hay un encargo donde esa capa se volvió imprescindible y que cada vez piden más los sitios grandes: la poda de contenido. Cientos o miles de páginas que no reciben nada, que envejecieron mal o que se publicaron por publicar, y que le quitan foco a las que de verdad sostienen el negocio.

El crawl solo no permite decidir qué se poda, porque desde adentro todas esas páginas se ven iguales. Con Search Console conectado aparecen las que llevan meses sin un clic ni una impresión, que es la lista de candidatas. Con las métricas de enlaces encima se separan dos grupos que no se tratan igual: las que se pueden eliminar sin costo y las que tienen enlaces externos apuntando y hay que redirigir para no regalar esa autoridad. Sin esas dos integraciones, una poda es una apuesta.

Automatizar: programación, línea de comandos y el servidor MCP

Screaming Frog tiene modo de línea de comandos y programación de crawls desde la versión 10, de septiembre de 2018. Con eso se dejan crawls periódicos que se exportan solos a una carpeta, a Google Drive o a una hoja de cálculo, e incluso se acumulan en una serie temporal para Looker Studio.

Dos cosas que aprendí montando esos crawls automáticos. Para que exporte sola hay que dejarla en modo headless, porque si no se queda esperando un clic que nadie va a dar. Y cada crawl programado abre una instancia nueva: si dos se solapan corren en paralelo, se pelean la memoria y terminan los dos a medias. Programarlos con holgura entre uno y otro evita el problema.

En mayo de 2026, la versión 24 sumó un servidor MCP, que es el estándar con el que un asistente de IA se conecta a una herramienta. La diferencia con lo que ofrecen otros es que aquí el asistente no solo lee el crawl: lo ejecuta. Hay órdenes para iniciar, pausar, reanudar, cargar y exportar un crawl, además de las de lectura de informes, exportaciones masivas, contenido de una URL, capturas y embeddings.

Trae además ejecución de scripts Node y acceso al sistema de archivos incorporados, así que no hace falta montar otros servidores para que el asistente escriba un archivo o corra un script. Las herramientas de Node vienen desactivadas por defecto, y esa decisión del fabricante es correcta: dejar que un modelo ejecute código arbitrario sobre la máquina de trabajo no es una función, es un riesgo que conviene encender a conciencia.

Esa librería es la de Antonio Maculus, y abre el archivo del crawl directamente, así que un script puede trabajar con los datos sin tocar la interfaz.

Fue de gran ayuda en los inicios del sistema de trabajo agéntico que hoy tenemos en Milimetrix, cuando no existía otra forma de que un agente leyera un crawl: su repositorio sigue publicado en GitHub. Después la reemplazamos por el servidor MCP oficial, que hace lo mismo y además lanza el crawl.

Hasta dónde escala en una máquina de escritorio

Screaming Frog guarda el crawl en memoria o en disco, y esa elección decide el techo. En modo memoria, con los dos gigabytes que se pueden asignar como máximo, se rastrean entre diez mil y cien mil URL. En modo de base de datos, que es el recomendado para sitios grandes, las cifras oficiales son otras.

Sitebulb publica la regla más útil para calcular antes de empezar: cuatro gigabytes de memoria por cada 500.000 URL auditadas, que son unos ocho kilobytes por URL. Con ese número cualquiera estima en diez segundos si su equipo aguanta el sitio que tiene enfrente.

El techo real, entonces, no es una cifra del programa sino el hardware del consultor y el tiempo que puede tener la máquina ocupada. Cuando el crawl dura días, cuando hay que repetirlo cada semana o cuando lo necesita un equipo completo con histórico compartido, el escritorio deja de ser el lugar correcto.

Los errores que más veo, y cómo los resuelvo

Casi todos los problemas de un crawl se parecen entre ellos: la herramienta devuelve mucho menos de lo que el sitio tiene, y la primera reacción es culpar a la herramienta. En mi experiencia el orden correcto es al revés, porque el crawler casi siempre está mostrando algo real sobre el sitio o sobre su infraestructura.

Códigos 429: el servidor pide que bajes el ritmo

Un 429 significa que se hicieron demasiadas peticiones en poco tiempo. La herramienta rastrea con cinco hilos por defecto, que para un servidor compartido o una tienda con poco músculo ya es bastante. Lo primero es bajar hilos y URL por segundo en Config, Speed, y lo segundo es cambiar el agente a Chrome en Config, User-Agent.

Ahora, la solución de fondo no es esconderse. Cuando el crawl es para un cliente, lo primero que pido es que autoricen mi dirección IP y el agente del rastreador en su plataforma de seguridad. Es lo único que sostiene un crawl grande sin sobresaltos. Disfrazarse de navegador funciona hasta que el cortafuegos aprende el patrón, y entonces el bloqueo llega en mitad de un crawl de ocho horas, que es justo cuando peor viene.

Sitios en React o Next.js donde solo aparece la página de inicio

Es el caso más frecuente hoy y tiene dos causas distintas que conviene no mezclar, porque se arreglan en lugares opuestos.

La primera es simple: el crawler no ejecuta JavaScript por defecto, así que los enlaces que solo existen después de ejecutarlo no los ve. Se resuelve pasando a modo de renderizado en Config, Spider, Rendering, comprobando que los archivos JavaScript y CSS no estén bloqueados en robots.txt, y subiendo el tiempo de espera si la aplicación tarda en montar. Con eso, la mayoría de los sitios en React o Next.js se rastrean completos.

La segunda no se arregla en el crawler. Si la navegación no usa enlaces reales, sino elementos que responden a un clic y cambian la ruta por código, no hay nada que seguir: no existe el destino como enlace. El crawler no los encuentra porque no están, y Googlebot tampoco los sigue. Ahí el hallazgo de la auditoría no es una configuración, es una corrección en el código del sitio, y tiene prioridad alta porque afecta al descubrimiento de páginas completo.

La diferencia entre ejecutar JavaScript y descubrir enlaces está desarrollada, con el experimento que la mide, en mi guía de SEO técnico y Core Web Vitals, donde también está el dato de que los rastreadores de IA directamente no ejecutan JavaScript.

Mientras el equipo de desarrollo corrige la navegación, el inventario se saca igual: modo lista con el sitemap como fuente. No reemplaza al crawl por enlaces, porque no dice nada sobre la arquitectura interna, pero permite auditar el estado técnico de cada página y no dejar la auditoría detenida esperando un despliegue.

Cuando el crawl se vuelve lento o se cae a mitad

Si el sitio es grande y la herramienta se arrastra, casi siempre es el modo de almacenamiento. En memoria el techo llega rápido; pasar a modo de base de datos cambia el orden de magnitud y además guarda el crawl solo, lo que evita perder ocho horas de trabajo por un cierre inesperado. Es lo primero que configuro en una máquina nueva, antes de rastrear nada.

Lo que Screaming Frog no hace

Hay tres cosas que Screaming Frog no hace, y las tres se suelen descubrir tarde.

• No analiza logs de servidor. Eso es otro producto del mismo fabricante, el Log File Analyser, que cuesta 139 dólares al año aparte y es gratis hasta mil líneas.
• No tiene nada de visibilidad en buscadores generativos: ni llms.txt, ni seguimiento de citas, ni informes de menciones. Los perfiles de bots de IA para identificar a GPTBot, ClaudeBot o PerplexityBot están en el analizador de logs, no en el crawler.
• No reemplaza a Search Console. El crawler dice qué páginas existen y en qué estado, pero solo Search Console dice cuáles están indexadas de verdad y qué consultas las traen.

Esa separación entre lo que revela un crawl y lo que revela la indexación real es la base del método que seguimos en Milimetrix, la agencia donde lidero el área de SEO y AEO, donde el crawl es el punto de partida de la auditoría y nunca su conclusión.

Alternativas que valen la pena

Una alternativa solo merece el nombre si propone algo distinto. Ofrecer lo mismo con menos mantenimiento no basta, y ese es el caso de dos nombres que siguen apareciendo en las comparativas: Netpeak Spider no publica una versión desde junio de 2024 y Visual SEO Studio no actualiza sus notas de versión desde febrero de 2023.

RustySEO: el crawler libre con el que empezamos el trabajo agéntico

RustySEO es un crawler de escritorio gratuito escrito en Rust, con interfaz gráfica y versiones para Windows, macOS y Linux. Hace 43 comprobaciones técnicas reales, entre ellas canonicals, cadenas de redirección, contenido mixto, páginas huérfanas y datos estructurados, exporta a Excel y a once archivos CSV, y trae análisis de logs dentro de la misma aplicación, que es justo lo que Screaming Frog cobra como producto aparte.

Fue el primer scraper del sistema de trabajo agéntico que armamos en Milimetrix, por una razón concreta: en ese momento Screaming Frog no tenía ni API ni servidor MCP, y necesitábamos un crawler que un agente pudiera invocar y leer sin intervención humana.

En abril de 2026 lo reemplazamos por la línea de comandos de Screaming Frog. El detonante fue un ecommerce sobre VTEX donde la aplicación de una sola página devolvía dos enlaces en lugar de las miles de URL que el sitio tenía de verdad. Su renderizado existe, pero viene desactivado y no resolvió ese catálogo.

Sigue siendo una opción razonable para revisar un sitio pequeño sin pagar licencia, y sobre todo para mirar logs de servidor sin sumar una segunda suscripción. Para una auditoría de cliente sobre un sitio que depende de JavaScript, hoy prefiero pagar la licencia.

Sitebulb: más barata y explica por qué cada problema importa

Es la única alternativa de escritorio que propone algo que Screaming Frog no hace: además de listar el problema, explica por qué importa y qué lo causa, con la prioridad ya asignada. Cuesta desde 18 dólares al mes, bastante menos que la licencia anual de Screaming Frog, y desde septiembre de 2026 incluye un servidor MCP de solo lectura gratis en todos los planes, incluso durante la prueba. A cambio, no analiza logs y no corre en Linux.

Alternativas libres que siguen con mantenimiento

Si la restricción es no pagar licencia, hay tres proyectos con código público y actividad reciente. FreeCrawl es el único crawler SEO gratuito con servidor MCP verificable, que es exactamente lo que buscábamos en su momento. LibreCrawl renderiza con Playwright y está pensado para varios usuarios sobre Docker. SiteOne Crawler encaja en una tubería de integración continua y genera llms.txt desde el propio crawl.

Cuándo el escritorio ya no alcanza

Cuando el sitio pasa del millón de URL, cuando el crawl tiene que repetirse solo cada semana o cuando el histórico lo necesita un equipo y no una persona, la respuesta es un crawler en la nube. JetOctopus y Lumar cubren ese terreno con crawls muy rápidos, integración de logs y retención de histórico compartida. Cuestan bastante más y se justifican por la frecuencia y el tamaño, no por las funciones.

Preguntas frecuentes sobre Screaming Frog

En resumen

Screaming Frog sigue siendo el estándar por una razón simple: es la herramienta que permite preguntarle cualquier cosa al sitio, no solo las preguntas que el fabricante anticipó. La extracción personalizada, la comparación entre crawls y la segmentación son las funciones que separan una auditoría que describe de una que explica, y ninguna está en la versión gratuita.

La novedad de 2026 es que el crawler dejó de ser una isla. Con el servidor MCP, un asistente puede lanzar el crawl, leerlo y cruzarlo con otras fuentes sin exportar un solo archivo. Ese cambio vale más que cualquier función nueva de la interfaz, y explica por qué volvimos a esta herramienta después de haber empezado con otra.

Si el sitio ya está auditado y la pregunta es qué se arregla primero y cuánto vale cada arreglo, eso es trabajo de estrategia y no de herramienta. Es lo que hacemos en Milimetrix como agencia de SEO y AEO.

Una herramienta rastrea, ordena y exporta. Lo que decide el resultado sigue siendo el criterio para saber qué de todo eso importa, en qué orden se arregla y qué se deja pasar.