Cruzar un rastreo de Screaming Frog con datos de Google Search Console parece, en principio, una tarea sencilla: exportar dos archivos, buscar una columna de URL que tengan en común y unirlos. En la práctica, ahí empiezan buena parte de los problemas.
- Las URLs pueden tener variaciones de protocolo, parámetros, barras finales, redirecciones o canónicas distintas. Search Console puede atribuir el rendimiento a la URL canónica elegida por Google, mientras que Screaming Frog muestra las direcciones que encontró durante un rastreo configurado de una forma determinada. Una página puede aparecer en una fuente, faltar en la otra o estar representada por una variante diferente.
En este artículo:
Si esos problemas no se resuelven antes del análisis, la inteligencia artificial no los corrige automáticamente. Puede incluso agravarlos: agrupar mal las páginas, sumar datos que no corresponden o producir conclusiones convincentes sobre un universo contaminado.
Por eso, en MaIA no comienzo pidiéndole a la IA que “analice el crawl”. Primero defino qué URLs importan, conservo las fuentes originales, normalizo las claves de cruce y clasifico las coincidencias. La IA entra después, cuando los datos ya representan razonablemente bien el sitio que queremos estudiar.
Este proceso desarrolla una de las etapas centrales de nuestra metodología de automatización de auditorías SEO con IA: pasar de exportaciones separadas a una base donde los datos técnicos y el rendimiento orgánico puedan leerse juntos.
¿Qué aporta Screaming Frog y qué aporta Search Console?
Screaming Frog y Google Search Console no compiten entre sí. Tampoco se reemplazan.
Un rastreo de Screaming Frog permite observar cómo responde el sitio desde la perspectiva de un crawler configurado por nosotros: códigos de estado, indexabilidad, canonicals, titles, descriptions, H1, profundidad, enlaces internos y otros elementos técnicos.
Search Console muestra otra parte de la realidad: cómo Google rastrea e indexa el sitio y qué rendimiento obtiene en sus resultados.
El informe de rendimiento de Search Console trabaja principalmente con clics, impresiones, CTR y posición media, que pueden analizarse por dimensiones como página, consulta, país, dispositivo y apariencia en búsquedas. Google aclara que la posición es un promedio de las posiciones registradas en las impresiones, no un ranking fijo que una URL ocupa permanentemente.
La diferencia podría resumirse así:
| Fuente | Qué permite observar | Qué no permite concluir por sí sola |
| Screaming Frog | Respuesta técnica, indexabilidad declarada, canonicals, arquitectura, profundidad, enlaces internos y elementos on page | Si una página recibe impresiones, genera clics o tiene valor orgánico real |
| Search Console | Visibilidad y rendimiento en Google, consultas, clics, impresiones, CTR, posición media y datos de indexación | Cómo está construida toda la arquitectura interna ni por qué existe cada problema técnico |
| Cruce de ambas | Qué problemas afectan páginas con visibilidad, qué URLs aparecen en Google pero no en el rastreo y qué patrones merecen prioridad | La decisión final sobre impacto, causa y acción recomendada |
El cruce cambia la pregunta. Ya no observamos simplemente que existen 300 titles duplicados. Podemos averiguar si esos duplicados afectan páginas indexables, si pertenecen a una misma plantilla, si reciben impresiones o si forman parte de un universo que no tiene valor orgánico.
Ese contexto es lo que convierte una exportación técnica en un diagnóstico.
El primer error: Analizar todas las URLs como si fueran iguales
Uno de los problemas más frecuentes en auditorías grandes es confundir el universo detectado por una herramienta con el universo que realmente necesita análisis.
- Un crawl puede incluir HTML, imágenes, JavaScript, CSS, redirecciones, páginas bloqueadas, parámetros, canonicals externas, recursos y URLs descubiertas por distintas vías. Incluso dentro de las páginas HTML, no todas son internas, responden con 200, son indexables o tienen alguna función SEO.
En un análisis interno reciente de nuestra agencia sobre un medio editorial de gran alcance, el universo exportado superaba ampliamente las 700.000 URLs detectadas. Sin embargo, después de separar recursos, URLs externas, redirecciones, errores y páginas no indexables, el primer universo accionable quedó por debajo de las 10.000 páginas HTML internas, con respuesta 200 e indexables.
Las cifras están redondeadas y el cliente se mantiene anonimizado, pero la diferencia es suficientemente clara: pedirle a una IA que analice más de 700.000 filas habría producido mucho procesamiento y poco diagnóstico.
Antes de cruzar datos, conviene distinguir al menos entre:
- URLs detectadas;
- URLs rastreadas;
- URLs internas;
- documentos HTML;
- páginas con respuesta 200;
- páginas indexables;
- páginas con rendimiento o relevancia estratégica.
Esta clasificación no significa que debamos descartar todo lo demás. Las redirecciones, páginas no indexables, errores y recursos también pueden revelar problemas. Significa que no deberían mezclarse bajo la idea de que cada fila representa una página SEO equivalente.
Dos formas de conectar Screaming Frog con Search Console
Hay dos caminos válidos para combinar estas fuentes. No sirven exactamente para lo mismo.
Integrar Search Console directamente en Screaming Frog
Screaming Frog permite conectar las APIs de Search Analytics y URL Inspection desde Configuration > API Access > Google Search Console.
De forma predeterminada, la integración obtiene clics, impresiones, CTR y posición de los últimos 30 días. El periodo, las dimensiones y otras opciones pueden modificarse desde la configuración de Search Analytics. También es posible activar la exploración de URLs descubiertas en Search Console para encontrar páginas que no aparecieron mediante enlaces internos.
Esta vía resulta útil cuando necesitamos una primera lectura rápida dentro de la propia herramienta.
Permite observar, por ejemplo:
- URLs con clics;
- páginas sin datos de Search Analytics;
- URLs no indexables que conservan datos de rendimiento;
- páginas descubiertas en Search Console, pero no a través del rastreo;
- diferencias entre la canonical declarada y la seleccionada por Google.
También se puede activar la API de inspección de URLs, que proporciona datos de indexación para un máximo de 2.000 URLs por propiedad y por día. Como Screaming Frog consulta inicialmente las primeras URLs HTML que encuentra siguiendo la profundidad de rastreo, conviene limitar el alcance, trabajar por secciones o utilizar el modo lista cuando se necesita revisar un conjunto prioritario.
La integración directa es cómoda, pero no siempre es suficiente para una auditoría compleja.
Exportar las fuentes y hacer el cruce fuera de la herramienta
En proyectos donde necesito mayor trazabilidad, suelo conservar los datos en archivos separados y hacer el cruce en una hoja de cálculo, una base de datos o un flujo con Python.
Este método permite:
- preservar una copia sin modificar de cada fuente;
- trabajar con varios periodos;
- controlar las reglas de normalización;
- comparar consultas y páginas en tablas diferentes;
- repetir el análisis con el mismo procedimiento;
- documentar qué transformaciones se aplicaron;
- preparar una base específica para la IA.
También evita depender exclusivamente de la exportación manual de la interfaz de Search Console. Google indica que esas descargas están limitadas a 1.000 filas representativas. Los totales del informe pueden incluir más datos, pero la tabla descargada no necesariamente contiene todas las páginas o consultas de un sitio grande. Para volúmenes mayores, es posible utilizar la API o la exportación masiva diaria a BigQuery, aunque incluso la API de Search Analytics está sujeta a limitaciones internas y no garantiza devolver todas las filas posibles.
En una auditoría pequeña, la integración directa puede ser suficiente. En una auditoría recurrente, de gran escala o que debe ser reproducible, prefiero mantener las fuentes y el proceso de unión bajo control.
Cómo preparar el rastreo de Screaming Frog
El archivo de Screaming Frog no debería ser una exportación indiscriminada con todas las columnas disponibles.
Para un primer cruce con Search Console, suelo partir de las páginas HTML internas y conservar las variables que permiten entender el estado técnico, la arquitectura y el tipo de URL.
Como base, conviene incluir:
- Address;
- Status Code;
- Indexability;
- Indexability Status;
- Canonical Link Element;
- Content Type;
- Title 1;
- Meta Description 1;
- H1-1;
- Crawl Depth;
- Inlinks;
- Redirect URL, cuando corresponda.
No todas estas columnas se usarán como clave de unión. Su función es aportar contexto una vez que cada URL tenga asociados sus datos de rendimiento.
La configuración del rastreo también debe quedar documentada. Un crawl con JavaScript rendering puede descubrir o interpretar elementos diferentes a uno realizado solo sobre HTML. Las reglas de include y exclude, el user-agent, los límites, el tratamiento de parámetros y el punto de inicio también modifican el universo obtenido.
Un crawl no es “el sitio”. Es una representación del sitio producida bajo una configuración y en un momento determinado.
Cómo exportar Search Console para cruzarlo por página
Para unir rendimiento con datos técnicos, la dimensión básica debe ser Página.
El periodo dependerá del objetivo. Treinta días pueden servir para observar un cambio reciente, pero suelen ser insuficientes para sitios estacionales o contenidos con poco volumen. En muchos casos, una ventana de tres meses ofrece una base más estable.
Para investigar caídas, migraciones o actualizaciones, puede ser necesario construir tablas separadas para comparar periodos equivalentes.
La exportación mínima por página debería conservar:
- URL;
- clics;
- impresiones;
- CTR;
- posición media;
- fecha inicial y final del periodo;
- filtros aplicados;
- tipo de búsqueda analizado.
Si necesitamos estudiar intención, canibalización o distribución de consultas, la tabla página-consulta debe mantenerse separada. Unirla directamente al crawl puede multiplicar cada URL tantas veces como consultas tenga y alterar los conteos técnicos.
- Ese es un error muy común: una página con 200 consultas termina apareciendo como 200 “errores técnicos” cuando, en realidad, sigue siendo una sola página.
Primero conviene construir una tabla agregada por URL. Después se pueden conectar las consultas como una capa adicional.
La normalización de URLs es la parte más delicada
La columna parece la misma en ambos archivos, pero no siempre representa la misma dirección.
Podemos encontrar variaciones como:
- http y https;
- dominio con y sin www;
- URL con y sin barra final;
- parámetros de campaña;
- fragmentos;
- versiones redirigidas;
- URLs antiguas;
- canónicas diferentes;
- caracteres codificados de distintas formas.
La normalización no consiste en borrar indiscriminadamente todo lo que parezca diferente. Consiste en crear una clave comparable sin perder la URL original.
En mi flujo mantengo, como mínimo, estas columnas:
| Campo | Función |
| url_original_sf | URL exacta obtenida de Screaming Frog |
| url_original_gsc | URL exacta informada por Search Console |
| url_normalizada | Clave creada para buscar coincidencias |
| canonical_sf | Canonical declarada y encontrada en el crawl |
| estado_cruce | Coincidencia directa, solo SF, solo GSC o posible variante |
| observacion | Razón probable de una diferencia relevante |
Es importante no convertir toda la URL a minúsculas automáticamente. Los esquemas y hosts se comparan sin distinguir mayúsculas, pero otros componentes, incluido el path, se consideran sensibles a mayúsculas salvo que el sistema que los interpreta establezca otra cosa. Normalizar todo el string podría fusionar recursos distintos.
Tampoco conviene eliminar todos los parámetros por defecto. Algunos son únicamente de seguimiento, pero otros cambian el contenido, la paginación, los filtros o incluso la identidad de la página.
La transformación correcta depende de cómo funciona el sitio.
¿Por qué las canonicals generan diferencias entre ambas fuentes?
Search Console atribuye normalmente los clics, impresiones y posiciones a la URL canónica seleccionada por Google. Esa URL puede coincidir con la canonical declarada por el sitio, pero no necesariamente lo hace en todos los casos.
Esto genera situaciones como la siguiente:
- Screaming Frog rastrea https://ejemplo.com/producto?color=rojo;
- la página declara como canonical https://ejemplo.com/producto/;
- Google atribuye el rendimiento a https://ejemplo.com/producto/;
- la unión directa por la URL rastreada no encuentra coincidencia.
El resultado podría interpretarse erróneamente como “esta página no tiene impresiones”. En realidad, las impresiones están consolidadas bajo otra URL.
Por eso, cuando una dirección aparece en Screaming Frog pero no encuentra rendimiento en GSC, reviso antes:
- si redirige;
- si declara otra canonical;
- si Google seleccionó una canonical diferente;
- si la URL de Search Console utiliza otra variante;
- si la exportación está limitada;
- si realmente no tuvo impresiones durante el periodo.
“No hay coincidencia” es un estado del cruce. Todavía no es un diagnóstico.
Cómo clasificar el resultado de la unión
Una vez normalizadas las URLs, el resultado puede dividirse en cuatro grupos principales.
URLs presentes en Screaming Frog y Search Console
Son las coincidencias directas. Permiten combinar rendimiento con información técnica y suelen formar el núcleo inicial del análisis.
Aquí podemos estudiar preguntas como:
- ¿Qué páginas con impresiones tienen titles duplicados?
- ¿Qué URLs con clics están a demasiada profundidad?
- ¿Qué contenidos con visibilidad reciben pocos enlaces internos?
- ¿Qué páginas indexables tienen un CTR bajo en relación con su posición e intención?
URLs presentes solo en Screaming Frog
No significa automáticamente que sean páginas inútiles. Pueden ser URLs nuevas, sin impresiones durante el periodo, no indexadas, bloqueadas, canónicas hacia otra dirección o excluidas de la exportación por los límites de Search Console.
También pueden ser páginas de negocio importantes que todavía no lograron visibilidad. El dato “sin rendimiento” debe interpretarse junto con su intención y función.
URLs presentes solo en Search Console
Este grupo suele ser especialmente interesante. Puede incluir páginas huérfanas, URLs antiguas, direcciones que ya no están enlazadas, variantes seleccionadas por Google, secciones excluidas del crawl o páginas que el rastreador no pudo descubrir con la configuración utilizada.
Screaming Frog puede añadir al rastreo las URLs descubiertas mediante Search Console cuando se activa la opción correspondiente. La propia herramienta clasifica como huérfanas las direcciones encontradas a través de Search Analytics y no mediante enlaces internos.
Sin embargo, no conviene llamar “huérfana” a cada URL que aparece solamente en GSC sin revisar antes la configuración del crawl y sus posibles fuentes de descubrimiento.
URLs no indexables con datos de Search Console
Este grupo puede señalar:
- una página que antes era indexable;
- una redirección reciente;
- una canonical hacia otra URL;
- un cambio de robots;
- datos históricos dentro del periodo;
- una discrepancia entre la configuración actual y la versión reconocida por Google.
Screaming Frog incluye precisamente un filtro para URLs no indexables con datos de Search Analytics. También diferencia las URLs sin datos, aunque aclara que esa ausencia puede deberse tanto a falta de impresiones como a diferencias entre las direcciones del crawl y las de Search Console.
- Otra vez: es una señal para revisar, no una instrucción automática para cambiar la indexabilidad.
No todas las fuentes responden la misma pregunta. Algunas muestran visibilidad, otras comportamiento y otras problemas técnicos. El valor aparece cuando las cruzamos.
¿Qué columnas derivadas ayudan a analizar el cruce?
Después de unir las fuentes, creo variables que facilitan la lectura sin pedirle todavía ninguna decisión a la IA.
Por ejemplo:
- tiene_impresiones;
- tiene_clicks;
- es_indexable;
- respuesta_200;
- canonical_autorreferencial;
- profundidad_alta;
- pocos_inlinks;
- title_duplicado;
- solo_en_gsc;
- solo_en_crawl;
- no_indexable_con_rendimiento;
- tipo_de_pagina;
- seccion;
- plantilla_probable.
Estas columnas deben construirse con reglas explícitas. “Profundidad alta”, por ejemplo, no significa lo mismo para todos los sitios. Un valor de cuatro clics puede ser problemático para una landing comercial pequeña y completamente normal para un archivo editorial con muchos años de contenido.
También conviene diferenciar los datos observados de las interpretaciones:
- Dato: la URL está a profundidad cinco.
- Inferencia: puede tener poca prominencia en la arquitectura.
- Validación pendiente: revisar navegación, breadcrumbs, sitemap y enlaces contextuales.
- Recomendación: decidir si necesita nuevos enlaces o una ubicación diferente.
Esa separación hace que el análisis sea más confiable y también mejora el uso posterior de la IA.
¿Dónde puede ayudar la IA?
Una vez que la base está limpia y clasificada, la IA puede ahorrar mucho tiempo. Puede agrupar URLs por patrones de carpeta, title, H1 o plantilla. También puede resumir los problemas que se repiten, clasificar páginas por función aproximada, detectar combinaciones poco frecuentes y proponer hipótesis para revisión.
- Por ejemplo, en vez de entregarle 600 URLs con descriptions duplicadas y pedirle que redacte 600 descriptions nuevas, podemos pedirle que identifique si el problema proviene de tres plantillas, qué secciones están afectadas y cuáles de esas páginas tienen visibilidad orgánica.
La pregunta deja de ser:
¿Cómo arreglo todas estas URLs?
Y pasa a ser:
¿Qué patrones explican el problema, qué páginas tienen valor y qué parte requiere una solución de plantilla?
- Una instrucción inicial podría ser:
Analiza esta tabla como apoyo para una auditoría SEO. No recomiendes cambios todavía. Separa datos observados, patrones, posibles explicaciones y validaciones pendientes. Agrupa los hallazgos por tipo de página y plantilla. No asumas que una URL sin datos de Search Console no tiene valor, ni que una URL con muchas impresiones debe modificarse. Señala cualquier problema de calidad o consistencia en los datos antes de interpretar el rendimiento.
El prompt ayuda, pero no compensa una base defectuosa. Si la unión multiplicó filas, mezcló periodos o fusionó URLs diferentes, una instrucción bien escrita solo producirá una explicación mejor redactada del error.
¿Qué análisis prácticos podemos obtener del cruce de datos entre herramientas?
El cruce entre Screaming Frog y Search Console permite construir análisis mucho más útiles que una lista general de incidencias.
Páginas con impresiones y CTR bajo
Este grupo puede ayudar a encontrar oportunidades en titles, descriptions, intención o presentación en resultados.
Pero el CTR no debe analizarse aislado. La posición media, el tipo de consulta, la marca, el dispositivo y la apariencia de búsqueda cambian la interpretación.
- Un CTR aparentemente bajo puede ser razonable para una página que aparece en posiciones lejanas o en consultas muy amplias.
Páginas con visibilidad y poca profundidad interna
También podemos detectar URLs que obtienen impresiones a pesar de tener pocos enlaces internos o una ubicación débil en la arquitectura.
Esto no demuestra que agregar enlaces aumentará el tráfico. Lo que si hace es que permite formular una hipótesis razonable: la página ya muestra alguna capacidad de aparecer y podría merecer una revisión de su integración dentro del sitio.
Problemas técnicos concentrados en páginas valiosas
Un mismo problema puede afectar 2.000 filas, pero corresponder a una sola plantilla. Al cruzarlo con Search Console podemos estimar cuántas páginas con impresiones o clics están realmente involucradas.
- En otra revisión interna de la agencia, miles de registros de una incidencia técnica se redujeron a unos pocos cientos de documentos HTML y, finalmente, a un problema común de implementación. La prioridad no era editar miles de URLs, sino corregir el origen compartido y volver a rastrear.
Este tipo de agrupación es uno de los usos más valiosos de la automatización: convertir volumen de filas en unidades reales de trabajo.
URLs con rendimiento que ya no forman parte de la arquitectura
Las páginas presentes en Search Console, pero ausentes del crawl, pueden revelar activos olvidados, enlaces perdidos, migraciones incompletas o URLs antiguas que todavía conservan visibilidad.
Antes de redirigirlas o eliminarlas, hay que revisar su contenido, backlinks, consultas, canonical, estado actual y función histórica.
Páginas indexables sin rendimiento
Este grupo puede incluir contenido nuevo, páginas mal enlazadas, URLs de poco valor, temas sin demanda, problemas de intención o simplemente datos insuficientes.
La IA puede ayudar a clasificarlas. No debería decidir sola cuáles eliminar.
Antes de automatizar cualquier análisis, conviene revisar si la base ya tiene el nivel mínimo de calidad y contexto necesario. Si eso falla, la IA no corrige el problema: lo amplifica.
Errores que pueden arruinar el análisis
El problema más evidente es unir las tablas sin normalizar las URLs. Pero no es el único.
También deberíamos evitar:
- mezclar periodos distintos sin registrarlos;
- comparar clics de un país con un crawl de todo el sitio sin aclararlo;
- multiplicar URLs al unir directamente consultas;
- interpretar posición media como una posición estable;
- asumir que la exportación manual contiene todos los datos;
- considerar cada fila técnica como una página independiente;
- eliminar parámetros sin entender su función;
- confundir canonical declarada con canonical seleccionada;
- tratar la falta de datos como prueba de que una página no tiene valor;
- pedirle a la IA una prioridad final sin contexto comercial.
Una auditoría se vuelve menos confiable cuando oculta estas decisiones. Por eso conviene conservar una pestaña o registro con las transformaciones realizadas: fuentes, fechas, filtros, columnas eliminadas, reglas de normalización y criterios de clasificación.
La trazabilidad no es burocracia. Es lo que permite corregir el análisis cuando una conclusión no cierra.
El cruce técnico todavía no es una prioridad de negocio
Después de todo este proceso podemos saber qué páginas tienen visibilidad, qué problemas técnicos presentan y qué patrones se repiten.
- Todavía falta decidir qué importa.
Una landing con pocas impresiones puede ser comercialmente estratégica. Un artículo con mucho tráfico puede no generar ninguna acción valiosa. Una incidencia que afecta cientos de URLs puede tener poco impacto, mientras que una canonical incorrecta en cinco páginas de servicio puede justificar una intervención inmediata.
Screaming Frog y Search Console acercan el diagnóstico a la realidad. No reemplazan el contexto de negocio.
Por eso, el siguiente paso no debería ser “implementar todo lo detectado”, sino clasificar los hallazgos por impacto potencial, esfuerzo, riesgo, dependencia técnica y prioridad comercial.
La IA puede ayudar a ordenar esa matriz. El criterio SEO y el conocimiento del negocio deben validar el resultado.
¿Cómo usamos este cruce en una auditoría SEO con IA?
En MaIA, nuestra agencia, el flujo general quedaría así:
- Definimos el alcance y la pregunta de la auditoría.
- Configuramos y documentamos el rastreo.
- Separamos el universo técnico del universo SEO accionable.
- Exportamos Search Console con periodos y filtros claros.
- Conservamos las fuentes originales.
- Normalizamos URLs y canonicals sin borrar diferencias relevantes.
- Clasificamos coincidencias, ausencias y posibles conflictos.
- Creamos variables técnicas y de rendimiento.
- Usamos IA para agrupar, resumir y formular hipótesis.
- Revisamos manualmente los hallazgos críticos.
- Incorporamos contexto comercial.
- Convertimos el diagnóstico en un plan de implementación.
La parte automatizada no consiste en delegar toda la auditoría. Consiste en reducir el tiempo dedicado a ordenar miles de filas para poder dedicar más atención a las decisiones difíciles.
Ahí está el valor del cruce: no en tener más datos, sino en descubrir cuáles se relacionan, cuáles se contradicen y cuáles necesitan una explicación antes de convertirse en una tarea.
De los datos técnicos a una auditoría accionable
Cruzar Screaming Frog con Google Search Console permite dejar de priorizar problemas por la cantidad de filas que ocupan en una exportación.
Nos ayuda a entender qué URLs tienen visibilidad, qué problemas afectan páginas relevantes, qué direcciones reconoce Google y no aparecen en la arquitectura actual, y qué incidencias se repiten porque existe un problema común de plantilla o configuración.
La inteligencia artificial puede acelerar mucho este análisis. Puede encontrar patrones, clasificar grupos y convertir una planilla difícil de leer en una base más manejable. Pero el orden sigue siendo importante: primero se define el universo, después se limpian y cruzan los datos, luego se usa IA y finalmente se valida con criterio técnico y comercial.
Hacerlo al revés produce más respuestas, incluso, no aplicables. Hacerlo en este orden produce mejores preguntas y decisiones más defendibles.
¿Necesitás convertir tus datos de Screaming Frog y Search Console en un diagnóstico accionable?
En MaIA combinamos rastreo técnico, datos propios, automatización y revisión SEO experta para detectar patrones y convertirlos en prioridades que puedan implementarse.
Podemos realizar la auditoría completa o ayudarte a diseñar un flujo interno para que tu equipo prepare, cruce y analice sus datos con apoyo de IA, sin perder trazabilidad ni criterio humano.
Preguntas frecuentes
Sí. Screaming Frog permite integrar Search Analytics y, opcionalmente, URL Inspection. La integración puede importar métricas como clics, impresiones, CTR y posición, además de ayudar a localizar URLs descubiertas en Search Console. Para auditorías complejas, puede convenir conservar y cruzar también las exportaciones fuera de la herramienta.
Puede no estar enlazada internamente, haber quedado fuera del alcance del rastreo, utilizar otra variante, redirigir, depender de JavaScript o corresponder a una URL canónica seleccionada por Google. La ausencia debe investigarse antes de clasificarla como página huérfana.
No. Puede ser nueva, estratégica, estacional, mal enlazada o no estar incluida en la exportación. El rendimiento orgánico es una señal importante, pero no es el único criterio para decidir si una página debe conservarse, actualizarse, fusionarse o eliminarse.
Puede ayudar a programar transformaciones, clasificar URLs y analizar la tabla resultante. Sin embargo, las reglas de normalización, el universo analizado, los periodos y la interpretación de las discrepancias deben definirse y validarse. Una unión técnicamente ejecutada no es necesariamente una unión metodológicamente correcta.
Nota editorial: artículo escrito por Marjory Landaeta con asistencia de la inteligencia artificial. La investigación, experiencia profesional, edición, enfoque metodológico y validación final corresponden a criterio humano.