Auditoría SEO: cómo hago una auditoría de una web paso a paso

Una auditoría SEO es la decisión de qué corregir primero en una web, con una prueba en cada recomendación y con una forma de comprobarlo tras la implantación. La lista de errores de una herramienta es solo el material de la auditoría. La auditoría técnica es la parte que comprueba si los robots de los buscadores y de los asistentes de IA pueden descargar y leer la web, y si el buscador puede indexarla.

Hago la auditoría en ocho pasos:

1. Fijo el objetivo y la situación de la web antes de lanzar el crawler, es decir, el programa que recorre la web como lo haría un robot de un buscador.
2. Compruebo si los robots reciben la página.
3. Reúno datos de varias fuentes y compruebo qué no ve cada una de ellas.
4. Estudio las palabras clave y los resultados de Google antes de ocuparme de la parte técnica.
5. Reviso la web según un catálogo de problemas con condiciones de prioridad.
6. Muestro una prueba en cada asunto.
7. Establezco el orden, el esfuerzo y las variantes.
8. Entrego el resultado a un control cruzado y, tras la implantación, compruebo cada asunto.

¿Qué es una auditoría SEO y en qué se diferencia de una auditoría técnica?

La auditoría SEO dice en qué estado está la web y qué limita su visibilidad, y la auditoría técnica comprueba si el buscador puede descargar, renderizar e indexar la web. En una auditoría completa reviso la parte técnica, la arquitectura y el contenido de las páginas, las palabras clave, los enlaces externos y la competencia, y al final ordeno las acciones. La auditoría técnica basta cuando la pregunta es técnica: una caída tras una implantación, una migración, páginas que desaparecen del índice.

La auditoría es la entrada de la estrategia, no la estrategia. La estrategia dice por qué demanda compites y a qué renuncias, y la auditoría dice qué se lo impide hoy. En el texto sobre la estrategia SEO describí cómo pasa lo uno a lo otro.

¿Cómo hacer una auditoría SEO paso a paso?

El orden de los pasos importa, porque los pasos anteriores deciden si las cifras de los posteriores son fiables. En dos momentos detengo el proceso para tomar una decisión: tras el primer paso fijo el alcance, y tras el control cruzado, antes de enviarlo al cliente, reviso las prioridades y las tesis.

Paso 1. Objetivo y situación de la web, antes de lanzar el crawler

La primera pregunta es si la web pierde tráfico o no lo está construyendo, porque de la respuesta depende toda la auditoría. Una web sin visibilidad necesita primero un mapa de palabras clave y de las páginas que deben responder a ellas. Una web que tiene visibilidad necesita primero proteger lo que ya ocupa posiciones, antes de que alguien empiece a corregirla.

Antes de empezar pregunto por cosas que ninguna herramienta va a mostrar. Qué productos o servicios dan beneficios, si está prevista una migración del sistema de gestión de contenidos o un rediseño, quién va a implantar las recomendaciones y de cuánto tiempo dispone. De las respuestas sale el alcance de la auditoría y la lista de cosas que no detallo, porque nadie las va a implantar.

Esta etapa hay que hacerla personalmente, aunque hoy muchos especialistas se la dejan a un modelo de lenguaje. Un modelo de lenguaje puede ayudar, pero no entiende el negocio del cliente. Tampoco aporta la mirada creativa y única de un especialista SEO con experiencia.

Paso 2. Si los robots reciben la página

Antes de leer cualquier cifra de una herramienta compruebo si el servidor deja entrar a los robots, porque un robot bloqueado produce datos que parecen problemas de SEO. En una semana de julio de 2026, tres «problemas de SEO» en tres sitios distintos resultaron ser un bloqueo de robots:

1. Un sitio «perdía» más de 2200 enlaces, porque las páginas desde las que se enlazaba estaban tras un cortafuegos que rechazaba al robot de la herramienta de análisis de enlaces.
2. Una tienda tenía en la herramienta una puntuación de salud de 0 con casi 42 mil errores, porque en lugar de las páginas el robot de la herramienta recibía respuestas del cortafuegos de Cloudflare.
3. En un tercer sitio, un bloqueo detenía al crawler en la primera dirección y durante tres semanas nadie lo advirtió.

Descargo la misma dirección como un navegador normal y como los robots de Google, Bing, OpenAI, Perplexity y Anthropic, y después comparo los códigos de respuesta y el tamaño de la página. La diferencia entre el navegador y el robot es lo primero que hay que aclarar, antes de empezar a calcular nada. Una prueba así envía las peticiones desde mi dirección IP con el nombre de un robot, y los cortafuegos reconocen a los robots auténticos de Google y Bing por la dirección desde la que llegan. El bloqueo de «Googlebot» en la prueba no demuestra, por tanto, el bloqueo del Googlebot auténtico. Search Console, el panel gratuito de Google para propietarios de webs, muestra cómo ve la web el Googlebot auténtico.

El archivo robots.txt lo leo hasta el final con un parser, es decir, un programa que aplica las reglas como un robot, y no a simple vista. El robot de Google aplica solo un grupo de reglas, el del nombre de robot que mejor coincide, y omite los demás. La regla Disallow: sin ruta no bloquea nada (Google Search Central). En agosto de 2026, de un fragmento del robots.txt de una web parecía deducirse que bloqueaba a Google. El parser mostró que Googlebot tenía acceso completo y que los bloqueados eran los robots de Bing y de los asistentes de IA. El diagnóstico era por tanto otro: el problema afectaba a Bing y a los robots de IA, no a Google.

La ausencia del archivo robots.txt no bloquea a Google, pero tras cada implantación compruebo que el archivo no haya desaparecido. Google trata un error 4xx en el robots.txt (salvo el 429) como si el archivo no existiera, es decir, sin restricciones (Google Search Central). Mi web devolvía en agosto de 2026 un error 404 en el robots.txt, antes de que lo corrigiera.

Paso 3. Datos de varias fuentes y lo que cada una no ve

Cada cifra de un crawler es una hipótesis hasta que la confirma una segunda fuente. Reúno un rastreo con ejecución de JavaScript y sin ella y datos de velocidad de usuarios reales del informe CrUX. A ello añado el perfil de enlaces y los resultados de Google para las palabras clave importantes el día de la medición. En el texto sobre el link building describí cómo compruebo el perfil de enlaces antes del plan de una campaña. De cada archivo anoto la fuente, la fecha y el alcance, para que al cabo de un mes se pueda reproducir cada cifra.

Los datos de Search Console los descargo mediante la API, es decir, una interfaz para descargar datos de forma automática, porque la exportación del panel recorta la lista a 1000 filas. La API devuelve hasta 50 mil filas al día por cada tipo de resultados, por ejemplo por separado para resultados de páginas, de imágenes y de vídeo (Google, Ayuda de Search Console). En el texto sobre las herramientas de IA para el SEO mostré cómo una exportación recortada infló el CTR en un sitio.

Un crawler puede subestimar el tamaño de un sitio, así que el número de páginas y de productos lo compruebo en una segunda fuente. En dos tiendas, el crawler llegó a la primera página de la lista de productos de una categoría y no siguió, aunque las páginas siguientes de la lista funcionaban y no estaban bloqueadas. En una tienda encontró menos de la mitad de los productos, y en la otra menos de un tercio. Si hubiera dado esas cifras como el estado de las tiendas, la auditoría habría descrito carencias de oferta que no existían.

Los cambios bruscos en los datos diarios los describo antes de atribuirles una causa. Lo hago con los clics, las impresiones, las posiciones, las sesiones y las peticiones del robot de Google. Busco los días a partir de los cuales la mediana de siete días consecutivos difiere al menos un 25% de la mediana de los catorce días anteriores. En cada una de esas fechas anoto una explicación: una implantación, una actualización de Google, una avería, un cambio en la medición o «causa desconocida». La descripción de las fechas da hipótesis, y señalo la causa solo después de comprobar otras explicaciones posibles.

Paso 4. Palabras clave y resultados de Google antes de la parte técnica

Primero busco oportunidades y después corrijo errores. Una parte de los problemas técnicos solo se puede valorar en el contexto de las palabras clave: si un filtro de una tienda debe indexarse, si una etiqueta merece una página propia, si dos páginas compiten de verdad por lo mismo. En el catálogo, 32 tipos de problemas están marcados como imposibles de valorar sin un análisis de palabras clave y de resultados de Google.

La falta de una página para una palabra clave importante es uno de los problemas más frecuentes en mis auditorías: 15 de 63 auditorías, en 14 de 50 sitios. El crawler no lo señalará por sí solo, porque descarga solo las páginas que existen. Se ve solo cuando contrasto la demanda con la lista de direcciones y con las páginas de la competencia que aparecen en los resultados.

Paso 5. Revisión según un catálogo con condiciones de prioridad

El mismo error tiene una prioridad alta o baja según dónde aparezca. Un enlace interno a una dirección con redirección en una plantilla que se repite en miles de páginas tiene prioridad alta. El mismo enlace en el contenido de una sola entrada tiene prioridad media, y en entradas archivadas, baja.

Cada tipo de problema del catálogo tiene una regla de detección, una condición de notificación, la prueba exigida, una prioridad con condiciones y una forma de comprobarlo tras la implantación. De los 256 tipos, 86 empiezan la regla de prioridad con «alta», pero casi siempre con una condición: cuando la palabra clave tiene demanda, cuando la página tiene tráfico, cuando el error está en la plantilla.

Por eso la puntuación de salud del sitio de una herramienta no determina las prioridades. La herramienta cuenta errores, no el tráfico que depende de ellos. Una recomendación sobre páginas de tráfico desconocido no recibe prioridad alta hasta que compruebo los datos.

Paso 6. Una prueba en cada asunto

Un asunto sin prueba se queda en la auditoría como «por comprobar» y no como recomendación. La prueba es una captura del lugar en el código o el HTML del servidor junto a la versión tras ejecutar JavaScript. También puede ser un gráfico de Search Console o una medición de velocidad con el nombre del elemento que la empeora. El elemento que empeora la carga o desplaza el diseño de la página lo nombro como lo indica la medición, no como encaja en mi hipótesis.

Cada asunto lo describo en cuatro partes, del problema a la comprobación de la corrección. Escribo en qué consiste el problema, por qué perjudica y a qué afecta, cómo corregirlo paso a paso y cómo comprobaremos que la corrección funcionó. El código que hay que corregir lo copio de la web literalmente, para que el programador vea exactamente el lugar que debe cambiar.

Así se ve en resumen un aviso sobre enlaces a redirecciones:

• Problema: los enlaces del menú llevan a direcciones sin barra final, que redirigen a la versión con barra.
• Por qué perjudica: el menú está en todas las páginas, así que cada clic y cada descarga de un robot pasa por una redirección adicional. En los informes de las herramientas, miles de enlaces así dificultan encontrar errores más importantes.
• Corrección: sustituir en la plantilla del menú las direcciones por las de destino, con un fragmento de código antes y después del cambio.
• Comprobación: tras la implantación, el rastreo no muestra en la plantilla enlaces a direcciones con redirección.

Paso 7. Orden, esfuerzo y variantes

El resultado de la auditoría es un orden, no un número de hallazgos. Al principio del documento está la tabla de todos los asuntos con la prioridad y el esfuerzo. El esfuerzo lo describo en cuatro categorías: unas horas, uno o dos días, una semana o un proyecto entero. Un equipo con menos posibilidades recibe una variante mínima junto a la completa, con una descripción clara de lo que pierde al elegir el camino más corto.

La implantación sigue exactamente la auditoría. Si al presupuestar la implantación aparece una variante más barata, la elige el cliente y lo anoto expresamente, en lugar de sustituir la recomendación sin que lo sepa.

Paso 8. Control cruzado y comprobación tras la implantación

Antes de que la auditoría llegue al cliente, la revisa alguien que no la ha escrito. Hago dos rondas de control: la primera sobre todo el documento y la segunda solo sobre lo que cambió tras la primera. El control recalcula las cifras desde cero y busca tesis que no se pueden defender con una prueba. Al final reviso yo mismo las prioridades y las tesis que dependen de la situación del cliente.

Tras la implantación compruebo cada asunto en la web en funcionamiento y lo marco como implantado correctamente, en parte o no implantado. Esa comprobación está incluida en el precio de la auditoría. Sin este paso, la auditoría termina en un documento y no en un cambio en la web.

¿Qué reviso en una auditoría de SEO técnico?

En una auditoría técnica repaso una quincena de áreas, y los problemas se señalan con más frecuencia en las redirecciones, la arquitectura de la web y el contenido. La última columna muestra en cuántas de las 63 auditorías del archivo el autor señaló al menos un problema del área. La columna «Qué reviso» da ejemplos, no el alcance completo del área. La tabla muestra áreas seleccionadas, y el catálogo divide los problemas en 22.

Un problema que se señala poco no tiene por qué ser poco frecuente. La velocidad y JavaScript tienen en esta tabla pocos avisos, pero las auditorías del archivo tenían un alcance distinto. Que haya pocos avisos no dice, por tanto, con qué frecuencia aparecen esos problemas en las webs.

¿Cómo compruebo la indexación de una web?

La indexación la compruebo en tres listas: qué hay en el mapa del sitio, qué ha indexado Google y qué encuentra el crawler a través de los enlaces. La discrepancia entre las tres listas muestra el problema mejor que cada una por separado. Un mapa del sitio con direcciones que devuelven una redirección, un error o están excluidas del índice se señaló en 20 de las 63 auditorías, en 18 de 50 sitios. Para direcciones sueltas uso la inspección de URL de Search Console, que muestra también la página tras ejecutar JavaScript.

¿Influyen los Core Web Vitals en las posiciones?

Los Core Web Vitals forman parte de los sistemas de clasificación de Google, pero no ganan a la relevancia del contenido. Google escribe expresamente que los sistemas de clasificación usan los Core Web Vitals. Escribe también que siempre intenta mostrar el contenido más relevante, incluso con una experiencia deficiente en la página (Google Search Central). En la auditoría uso datos de usuarios reales del informe CrUX y no una sola prueba en una herramienta de laboratorio. Allí donde Google tiene esos datos para cada tipo de página, los doy por separado. Las carencias de esos datos las describo en la auditoría. Desde el 12 de marzo de 2024 la medida de la reacción de la página es el INP, que sustituyó al FID (web.dev).

¿Qué errores encuentro con más frecuencia en las auditorías SEO?

Los errores que más se repiten son los de mantenimiento, es decir, los que las herramientas detectan con facilidad: enlaces a redirecciones y a errores 404, mapas del sitio con direcciones incorrectas y títulos y descripciones de página duplicados. Los enlaces internos a direcciones con redirección aparecieron en 24 de las 63 auditorías, en 20 de 50 sitios. Las herramientas los detectan bien, y el coste de la corrección depende de la plantilla y del sistema de la web.

Los problemas de estructura que se señalan con menos frecuencia pueden influir más en el tráfico que los errores de mantenimiento. La falta de páginas para palabras clave importantes se señaló en 15 de las 63 auditorías, y otras tantas veces un blog que no enlaza a las páginas de oferta y de categorías. El catálogo da prioridad alta a una página ausente cuando la palabra clave tiene demanda y la competencia ocupa las posiciones con páginas propias. Un blog sin enlaces recibe prioridad alta cuando las páginas de destino tienen tráfico o ingresos y el blog tiene autoridad. Estas condiciones las compruebo con datos antes de asignar la prioridad.

• 938hallazgos en 63 auditorías en 50 sitios, con los que construí un catálogo de 256 tipos de problemasArchivo de auditorías 2020-2026, catálogo del 11/10/2026
• 38%de las auditorías con enlaces internos a direcciones con redirección, el problema señalado con más frecuencia en el archivo (24 de 63)Catálogo del 11/10/2026
• 15 de 63auditorías con falta de páginas para palabras clave importantes, algo que el crawler no señalará por sí soloCatálogo del 11/10/2026
• 14tipos de recomendaciones que el catálogo marca hoy como obsoletas, y otros 30 como práctica cambiadaCatálogo del 11/10/2026

¿Qué ha cambiado en las auditorías SEO desde 2020?

En las auditorías de 2023-2026 los datos estructurados y la paginación aparecen con más frecuencia que en 2020-2022, y las redirecciones, las URL canónicas y la indexación, con menos. Los problemas de datos estructurados se señalaron en 23 de las 33 auditorías más recientes frente a 16 de las 30 más antiguas. Redirecciones y códigos de respuesta: 23 de 33 frente a 27 de 30. Los bloqueos de robots de IA aparecen solo en las auditorías de 2026. El año de la auditoría es la fecha del archivo en el registro, así que no siempre es el año en que se hizo el trabajo.

La bajada no demuestra que los problemas de redirecciones hayan desaparecido. Cambió la composición de las auditorías: las más recientes trataron con más frecuencia datos estructurados, contenido y visibilidad en la IA, y cambió también el modo de trabajar. De este gráfico se deduce de qué se ocuparon las auditorías, no cómo han cambiado las webs en Polonia.

¿Qué recomendaciones SEO están hoy obsoletas?

Algunas recomendaciones siguen apareciendo en auditorías y guías, aunque hoy no conviene implantarlas. Una parte funcionaba hace unos años, y otra la desaconsejaba Google o la ignoraba desde hacía tiempo. En la tabla doy, para cada práctica, el motivo y lo que hay que hacer en su lugar.

Fuentes de la tabla: Google sobre la paginación, Google sobre cinco errores con rel=canonical, Google sobre los resultados FAQ y HowTo, Matt Cutts sobre el nofollow y el reparto de la fuerza de los enlaces, John Mueller sobre las redirecciones a la página de inicio, según Search Engine Roundtable, Google sobre el robots.txt, Google sobre las reglas no admitidas en el robots.txt, Google sobre los mapas del sitio, Google sobre los campos lastmod, changefreq y priority, web.dev sobre el INP, Google sobre el cuadro de búsqueda en los resultados.

Por eso cada recomendación de mi catálogo tiene un campo de vigencia con su justificación. El catálogo marca hoy 14 tipos de recomendaciones como obsoletas y 30 como práctica cambiada. Una recomendación que era correcta hace unos años no entra en una auditoría solo porque antes funcionaba.

¿Cómo comprobar el acceso de los robots de IA en una auditoría?

El acceso de los robots de IA lo compruebo en el mismo paso que el acceso de Googlebot, porque puede bloquearlos el mismo ajuste del cortafuegos o de la CDN. La CDN es una red de servidores intermediarios, por ejemplo Cloudflare. En septiembre de 2026 comprobé 12 dominios de mis clientes que funcionan tras Cloudflare. Solo el archivo robots.txt mostró:

• 3 dominios bloqueaban el mismo conjunto de siete robots que recogen datos para entrenar modelos, con una lista idéntica de nombres. Una lista idéntica sugiere un origen común, por ejemplo un ajuste ya preparado en el panel de Cloudflare. Desde fuera no se ve ese ajuste, así que hay que confirmarlo en el propio panel.
• 1 dominio bloqueaba los robots que descargan páginas para las respuestas de ChatGPT, Perplexity y Claude. No lo hacía expresamente, sino con una regla general para todos los robots no nombrados. Ese mismo dominio mostraba a GPTBot una página de seguridad sin la etiqueta noindex, que excluye la página del índice. Si una página así la recibiera un robot indexador, en el índice podría acabar la página del bloqueo en lugar del contenido.
• 8 dominios no tenían bloqueos en el robots.txt.

Sobre los robots que descargan páginas para las respuestas y los que recogen datos para entrenar se decide por separado. En el texto sobre GEO y AI SEO describí cómo distinguirlos. Desde el 31 de agosto de 2026 hay además un ajuste aparte en Search Console que excluye una página de AI Overview, del Modo IA y de las funciones generativas de Discover. Según Google, no afecta al resto de los resultados de búsqueda (Ayuda de Search Console). Ese ajuste lo compruebo en la auditoría igual que el robots.txt, porque alguien pudo activarlo sin que lo supiera la persona responsable del SEO. Si tras abrir el acceso la marca aparece en las respuestas es ya una medición aparte, que describí en el texto sobre la visibilidad de marca en la IA.

Una prueba desde una sola dirección IP muestra solo una parte de la situación y por sí misma puede dar una falsa alarma. En esa misma revisión, una serie de peticiones notificó en dos dominios un bloqueo tras superar un límite. Ese bloqueo lo provocaron mis propias peticiones anteriores. Una comprobación unos minutos después, con un solo identificador de robot y peticiones sueltas, dio cinco y siete respuestas correctas seguidas. Sin esa comprobación, dos clientes habrían recibido información sobre un bloqueo que no existía. Solo los registros del servidor muestran si ChatGPT descarga de verdad la página. En el texto sobre el archivo llms.txt muestro qué se ve en los registros de mi web.

El código 200 no significa que el robot haya recibido el contenido. En un cliente con una aplicación en JavaScript, Googlebot y Bingbot recibían HTML ya preparado de un servicio de prerenderizado, y los robots de los asistentes de IA una página vacía. El servicio reconocía a los robots por el nombre y no tenía a los robots de IA en la lista. Mi prueba dio el resultado «correcto», porque medía el código de respuesta y no el contenido. Desde entonces comparo el contenido que recibe el robot con el contenido tras ejecutar JavaScript en el navegador.

¿Basta con una auditoría SEO gratuita?

Una herramienta gratuita mostrará una lista de errores, pero del informe solo no se deduce cuáles te cuestan tráfico. Para la búsqueda «audyt seo» (auditoría SEO en polaco), 7 de los 9 resultados orgánicos de la primera página de Google son herramientas u ofertas de auditoría gratuita (resultados del 17 de octubre de 2026). Un informe así cuenta errores según las reglas de la herramienta, no según cuánto tráfico e ingresos dependen de ellos. Hay que comprobar además que el resultado no proceda de un bloqueo del robot, como en el caso de la tienda con una puntuación de salud de 0.

Se puede hacer mucho gratis si sabes dónde mirar. Search Console muestra los datos de Google sobre indexación, Core Web Vitals y la página tras ejecutar JavaScript. La versión gratuita de Screaming Frog recorre hasta 500 direcciones en un rastreo (Screaming Frog), lo que basta para una web pequeña de empresa. Una auditoría con un consultor tiene sentido cuando el error cuesta mucho (una migración, una caída de tráfico, una tienda grande) o cuando no tienes tiempo para reunir y valorar los datos.

¿Hará ChatGPT una auditoría SEO?

Ni ChatGPT ni ningún otro modelo de IA hará solo una auditoría completa, porque no ve la web como un robot de un buscador. Normalmente la ve a través de una herramienta que la descarga y la convierte en texto. El modelo leerá los datos que le des y propondrá qué comprobar. La herramienta de descarga puede, sin embargo, perder parte de la página: en septiembre de 2026 comprobé que la herramienta de descarga de páginas de Claude Code elimina los datos estructurados al convertir la página en texto. El modelo respondió que la información no existía, aunque estaba en una etiqueta de la misma página. Una auditoría hecha así habría señalado la falta de datos estructurados que no faltan. En mi proceso, la IA es una herramienta, sobre todo para agregar datos del rastreo, de Search Console y de otras fuentes. El alcance, la valoración y las prioridades las establezco yo.

¿Cuánto cuesta una auditoría SEO?

La auditoría la facturo como una consultoría: 70 EUR netos por hora de trabajo, con un tope de horas fijado antes de empezar. El número de horas depende de lo que haya que revisar:

• una auditoría de diagnóstico, es decir, uno o dos problemas concretos (una caída, una migración, la indexación), suele ser de 10 a 16 horas, es decir, 700-1120 EUR netos;
• una auditoría completa con el orden de las acciones suele ser de 32 a 50 horas, es decir, 2240-3500 EUR netos;
• una web pequeña de hasta 500 direcciones se acerca al límite inferior, y una tienda con miles de direcciones y filtros, al superior;
• las versiones de idioma suelen añadir de 3 a 5 horas, y una crisis en curso que hay que diagnosticar, de 4 a 8 horas.

En el precio están el análisis, el informe con las recomendaciones, la reunión en la que lo comentamos y la comprobación tras la implantación. La implantación la hace tu equipo, o la presupuesto aparte.

Sin acceso a Search Console, al panel de la CDN y al hosting no podré comprobar del todo la parte técnica, y lo digo antes de presupuestar. Indico entonces qué no podré verificar sin esos accesos y acoto el alcance en consecuencia. En el texto sobre la consultoría SEO describí cuándo, en lugar de una auditoría, basta una conversación sobre una decisión.

Preguntas frecuentes sobre la auditoría SEO

¿Por dónde empezar?

Empieza por una pregunta: si la web pierde tráfico o no lo está construyendo. De la respuesta depende si primero proteges las páginas que tienen posiciones o buscas las palabras clave para las que faltan páginas. Después haz las tres comprobaciones gratuitas de la respuesta sobre la auditoría por tu cuenta: robots.txt, el informe de indexación de Search Console y un rastreo con la versión gratuita de Screaming Frog. Si el resultado te sorprende o no sabes qué corregir primero, es un buen tema para una consultoría.