SEO técnico capaz de resistir los análisis de IA, las reconstrucciones «Headless» y tu próxima actualización de algoritmo.

Rastreo, indexación, esquemas, Core Web Vitals, multilocalización, citabilidad en búsquedas con IA, integrados en el código base, no añadidos a posteriori tras el lanzamiento. WordPress, WordPress «Headless», Next.js, Astro, Nuxt y la capa de CMS que hay detrás de ellos.

¿QUÉ ES EL SEO TÉCNICO EN 2026?

El SEO técnico es el nivel de trabajo que determina si los motores de búsqueda y los asistentes de IA pueden rastrear, renderizar y confiar en tus páginas, antes de que el contenido o los enlaces entrantes tengan algún efecto. Abarca el comportamiento HTTP, la semántica HTML, los datos estructurados, hreflang, la canonicalización, los Core Web Vitals y la renderización de JavaScript. Si lo haces mal, el resto de tu inversión será un lastre.

En 2026, la definición se ha ampliado. Dos cambios han impulsado este cambio. En primer lugar, los resúmenes de IA y la búsqueda impulsada por ChatGPT se interponen ahora entre la mayoría de los usuarios y las páginas subyacentes, lo que significa que la facilidad para citar el contenido es tan importante como el posicionamiento. En segundo lugar, el sitio modal ya no es una instalación de WordPress, sino una variante de front-end «Headless» que extrae contenido de Sanity, Strapi, Payload, Storyblok, Contentful o un back-end de WordPress «Headless». Cada una de estas arquitecturas presenta sus propios modos de fallo técnico en materia de SEO que el manual de estrategias anterior no aborda.

Mi definición práctica para los clientes en 2026: el SEO técnico es todo lo que abarca una ejecución de Lighthouse, un informe de rastreo de Search Console, una comprobación de citas con AI Overview y una notificación del validador de esquemas, en todas las configuraciones regionales, todas las plantillas y todas las rutas de renderizado. Si alguna de esas cuatro señales falla en una URL representativa, ahí es donde comienza la intervención.

¿POR QUÉ EL SEO TÉCNICO ES DIFERENTE EN LOS SITIOS HEADLESS Y JAMSTACK?

En una web «Headless» o Jamstack, el marco de trabajo front-end se encarga de la representación y el CMS, del contenido, por lo que el SEO puede quedar relegado a un segundo plano entre ambos. El modelo clásico de WordPress + Yoast partía de la base de un único servidor, un único motor de representación y un único motor de reglas. Al extraer el contenido de WordPress para pasarlo a Next.js o Astro, no se hereda nada de eso de forma automática.

Pilas puramente modernas

Una aplicación creada con Next.js + Sanity, otra con Astro + Storyblok, otra con Nuxt + Strapi y otra con Next.js + Payload: todas ellas prescinden por completo de WordPress. El trabajo de SEO técnico se centra ahora en garantizar que el esquema de tu CMS modele los campos de SEO que necesita el front-end (sobrescritura canónica, mapa de redireccionamientos, grupo hreflang, JSON de extensión de esquema) y en asegurarse de que se active la revalidación bajo demanda cuando cambie el contenido. El envenenamiento de la caché ISR es el asesino silencioso: una página se muestra obsoleta durante horas tras su publicación porque nunca se configuró revalidatePath.

¿Qué es lo primero que se rompe realmente?

De las aproximadamente 200 auditorías «Headless» que hemos realizado, el problema más habitual que provoca fallos en producción es el conflicto canónico: el front-end genera una URL canónica, mientras que los metadatos del CMS o el mapa del sitio generan otra. Google elige una, casi siempre la que no querías, y la URL incorrecta acaba en el índice. Detectamos este problema con un linter de compilación que compara la URL canónica generada por la plantilla con la URL canónica almacenada en el CMS en una muestra de páginas y rechaza la compilación si hay alguna discrepancia.

¿EN QUÉ SE DIFERENCIA EL SEO TÉCNICO DE WordPress DEL Headless?

WordPress te ofrece la mayor potencia en cuanto a plugins y las más diversas formas de meterte en líos. La estrategia de SEO técnico en una web clásica de WordPress consiste principalmente en restar: eliminar las etiquetas canónicas duplicadas, acabar con los conflictos de Schema entre Yoast y RankMath y un tercer plugin que nadie recuerda haber instalado, domar los constructores de páginas que incluyen 2 MB de CSS y eliminar las cadenas de redireccionamientos que se han ido acumulando durante ocho años.

La configuración predeterminada que recomendamos en 2026: un único plugin de SEO (RankMath o Yoast, nunca ambos), un alojamiento gestionado con un almacenamiento en caché de borde adecuado (Cloudways, Kinsta, WP Engine), Bricks Builder para nuevas creaciones en las que el rendimiento sea importante o Gutenberg nativo con Kadence o Blocksy, un gestor de redireccionamientos que exporte a un formato portátil, y Perfmatters o FlyingPress para la limpieza de recursos. El trabajo de auditoría consiste en detectar cuáles de esas decisiones se tomaron de forma diferente en tu sitio web y revertir las consecuencias.

En el ámbito «Headless», el trabajo pasa de la sustracción a la construcción. No existe Yoast, por lo que hay que desarrollar la gestión de metadatos. No hay ningún plugin para Schema, así que hay que crear plantillas para JSON-LD. No hay un mapa del sitio integrado, por lo que hay que generarlo y transmitirlo. El volumen de código que añadimos a un proyecto «Headless» para el SEO suele ser entre tres y cinco veces mayor que el que ya te ofrece de forma gratuita un sitio de WordPress, pero ese código es de nuestra propiedad, está controlado por versiones, se puede probar y no deja de funcionar con la siguiente actualización del plugin.

¿QUÉ SIGNIFICAN LAS ABREVIATURAS GEO Y AEO PARA TUS PÁGINAS?

GEO y AEO son los nombres que reciben dos formas diferentes en las que las funciones de IA captan tráfico de búsqueda. AEO (optimización para motores de respuestas) es el término más antiguo; abarca funciones de Google como los fragmentos destacados, «La gente también pregunta» y los paneles de conocimiento, que extraen un fragmento de tu página y lo muestran como respuesta. GEO (Optimización para motores generativos) es el término más reciente, que se refiere a la optimización para resúmenes generados por IA, la búsqueda en ChatGPT, Perplexity y Bing Copilot, donde el asistente genera un párrafo y cita tu página como fuente.

Qué significa eso desde el punto de vista estructural

Ambas plataformas buscan lo mismo: un fragmento listo para citar. Las reglas estructurales que funcionan en todas ellas son las mismas. Utiliza una pregunta como título de segundo nivel (H2), no una etiqueta temática. Incluye la respuesta en la primera o las dos primeras frases tras el título. Que esa respuesta no supere las 250 palabras. Asegúrate de que la respuesta se genere del lado del servidor, no dentro de un componente de JavaScript que se cargue tras la carga de la página. Los rastreadores de IA y los extractores de Google, en su mayoría, no ejecutan JS; si tu respuesta necesita JS para aparecer, serás invisible.

En qué se diferencia GEO de AEO

Hay tres aspectos que cobran especial relevancia para GEO. La autoridad de las entidades: Google y los modelos de lenguaje grande (LLM) construyen un grafo que indica quién está autorizado a hablar de qué, y las menciones de marca no enlazadas alimentan ese grafo. El esquema con los campos «about» y las matrices de menciones hacen que tu página se pueda analizar como parte de un grafo de entidades, en lugar de como un bloque de texto. Y «llms.txt», un nuevo estándar de archivo ubicado en /llms.txt que proporciona a las herramientas de IA un mapa seleccionado de tu sitio web, del mismo modo que «robots.txt» y «sitemap.xml» ayudan a los rastreadores de búsqueda. Implementamos «llms.txt» en todos los sitios web que creamos y lo actualizamos cada vez que se publica una página importante.

¿QUÉ MARCADO SCHEMA NECESITAS REALMENTE?

Necesitas menos tipos de esquema de los que generan la mayoría de los complementos, pero los que incluyas deben ser válidos y coherentes. Una lista breve cubre nueve de cada diez proyectos.

  • Organización: incluye un único gráfico para todo el sitio web en tu diseño, con el logotipo, «sameAs» (solo cuentas reales en redes sociales), la dirección y el «contactPoint». No lo dupliques en cada página.
  • Sitio web: una vez, en el diseño, con la acción «potentialAction» para la búsqueda de enlaces relacionados, si dispones de un buscador interno.
  • Lista de navegación, en todas las páginas que no sean la página de inicio, con URL adaptadas a la configuración regional (una página en francés debe apuntar a subdirectorios de /fr/, no a /en/).
  • Artículo o entrada de blog, sobre contenido extenso, con matrices «about» y «mentions» para reforzar el grafo de entidades.
  • Servicio, en páginas comerciales, con los campos «serviceType», «provider», «areaServed», «audience» y «offers.priceSpecification», en el que se puede publicar un rango de precios.
  • Producto, en el comercio electrónico, con ofertas, precio, moneda, disponibilidad y valoración global solo si dispones de opiniones reales.
  • Página de preguntas frecuentes, siempre que haya al menos dos preguntas auténticas en la página. La creación de preguntas frecuentes falsas para obtener el marcado Schema es el motivo más habitual de acción manual que corregimos.
  • LocalBusiness o uno de sus subtipos, en páginas de ubicaciones físicas, con coordenadas GEO y especificación de horario de apertura.

Hay tres cosas que echan por tierra el esquema en producción: inventar propiedades que schema.org no define; inventar valores para «sameAs» (URL falsas de LinkedIn, nombres de usuario de Twitter abandonados); y enviar grafos de «Organization» contradictorios procedentes de varios complementos. Ejecutamos validadores de esquemas en el linter de compilación y rechazamos la compilación si se detecta cualquiera de esos tres patrones.

¿CÓMO SE PUEDE APLICAR HREFLANG A GRAN ESCALA SIN QUE DEJE DE FUNCIONAR?

Hreflang falla a gran escala porque la restricción es bidireccional y el conjunto de datos es escaso. Cada variante de una página en una configuración regional debe hacer referencia a sí misma, debe hacer referencia a todas las demás variantes y debe ser referenciada a su vez por todas las demás variantes. Si falla una de las direcciones en una página de una configuración regional, Google rebaja silenciosamente la calificación del clúster.

El patrón que se adapta a cualquier tamaño

Almacena un «content_group_id» (o equivalente) en cada fila traducible. Cada variante de idioma de una página comparte un único ID. El emisor hreflang, el emisor del mapa del sitio y el emisor canónico derivan su clúster a partir de ese ID. Nunca calcules el hreflang basándote únicamente en la coincidencia de patrones de URL, ya que falla en casos extremos (una página en español que no tenga traducción al hindi rompe el clúster si tu código asume que «si la página X existe en la variante de idioma A, existe en la variante de idioma B»).

¿Qué es lo que hace que «hreflang» deje de funcionar en la práctica?

Tres patrones que vemos repetidamente. El orden de las expresiones regulares de configuración regional: colocar «zh» antes de «zh-Hant» en la expresión regular de detección de configuración regional, lo que captura una configuración regional errónea y genera un atributo `hreflang` incorrecto. Olvidarse de `x-default`: cada clúster necesita un valor de reserva `x-default`, que suele apuntar a la versión en inglés. Desviación del ID de clúster: una traducción recibe un nuevo ID en lugar de heredar el ID de origen, lo que divide silenciosamente un único clúster en dos clústeres no relacionados, ninguno de los cuales tiene un conjunto recíproco completo.

Siempre incorporamos un verificador de hreflang en la fase de compilación que rastrea una muestra de páginas, recorre los grupos de hreflang a los que hacen referencia y da por fallida la compilación si algún grupo está incompleto o es asimétrico.

¿QUÉ ES EL SEO PROGRAMÁTICO Y CÓMO SE APLICA DE FORMA SEGURA?

El SEO programático genera miles de páginas a partir de una fuente de datos estructurada, junto con una plantilla, directorios, páginas comparativas, páginas de ubicación y páginas de glosario. Si se hace bien, puede abarcar la «cola larga» a una escala que el contenido de un solo autor no puede igualar. Si se hace mal, provoca una acción manual y elimina la mayoría de tus páginas indexadas de la noche a la mañana.

¿Qué diferencia a una estructura programática bien definida de una con contenido escaso?

Tres cosas. Datos reales por página: cada URL contiene al menos un dato, una cifra o un detalle exclusivo; las páginas programáticas con poco contenido comparten el 95 % de su contenido. Una plantilla significativa: la plantilla aporta contexto, comparativas, recomendaciones o agregaciones en torno a los datos exclusivos, no es solo un envoltorio optimizado para los motores de búsqueda. Y control de calidad: las páginas con datos exclusivos insuficientes se excluyen del mapa del sitio, se bloquean para su indexación o se mantienen en estado de borrador hasta que se complete la capa de datos.

Lo que hemos aprendido al ponerlo en práctica a gran escala

Creé HostList.io como una plataforma de SEO programático con páginas para más de 30 000 empresas de alojamiento web, desarrollada con Next.js y Supabase. Las páginas que sobrevivieron a dos años de actualizaciones de Google fueron aquellas que contaban con al menos tres datos únicos por URL, además de una plantilla que comparaba, puntuaba o recomendaba en función de esos datos. Las páginas que desindexamos fueron aquellas en las que los datos únicos se limitaban a un nombre y un precio. El coste de eliminar del índice las páginas con poco contenido fue mínimo; el coste de dejarlas ahí fue una penalización en el posicionamiento de todo el sitio web cuando se aplicó la actualización de contenido útil de marzo de 2024.

Aplicamos ese manual de operaciones a los desarrollos programáticos de nuestros clientes: front-end con Next.js o Astro, datos en Supabase o Postgres, un proceso de importación que evalúa la singularidad de las páginas antes de su publicación, un mapa del sitio que se carga por partes, ya que más de 50 000 URL no caben en un único archivo sitemap.xml, y un gráfico de enlaces internos que agrupa cada página final en un clúster temático.

¿CÓMO SE MANTIENEN EN VERDE LOS INDICADORES «CORE WEB VITALS» A GRAN ESCALA?

Supera los «Core Web Vitals» en el percentil 75 de los datos de campo, no en una ejecución controlada de Lighthouse en laboratorio. Google utiliza los datos de campo de CrUX; Lighthouse es una herramienta de depuración. A menudo, ambos presentan diferencias del 30 % o más en sitios web reales.

A dónde va realmente el presupuesto

El LCP suele ser casi siempre la imagen principal y casi siempre se resuelve recodificándola a WebP con una calidad del 80 %, ajustando el tamaño a las dimensiones reales de la pantalla más el doble para pantallas Retina, añadiendo una etiqueta «preload» en el encabezado y estableciendo «fetchpriority="high"». Una imagen principal de 1 MB que se convierte en un archivo WebP de 30 KB es el cambio que más impacto tiene en la mayoría de los proyectos. El CLS se debe a imágenes y anuncios sin dimensiones explícitas, a la falta de atributos explícitos de anchura y altura en cada imagen, a los espacios publicitarios de altura fija y al espacio reservado para cualquier widget del lado del cliente. El INP se debe a un JavaScript pesado en las interacciones, normalmente un gestor de etiquetas de terceros o una biblioteca de análisis demasiado entusiasta. La solución pasa por aplicar «debouncing», carga diferida o sustituir el código por un equivalente más ligero.

Donde la mayoría de los proyectos fallan

Hay dos casos. En primer lugar, una imagen LCP dentro de un componente «Carousel» o de un diseño controlado por JavaScript: la imagen solo se muestra una vez que se ejecuta el JS, y tu LCP es el esqueleto de carga del carrusel, no la foto. En segundo lugar, las fuentes web cargadas sin «font-display: swap» y sin precarga: el texto permanece invisible durante 200-400 ms mientras se descargan las fuentes, y el LCP supera el umbral de 2,5 s aunque la imagen se cargue rápidamente. Ambos casos se detectan mediante una revisión de los datos de campo de CrUX, no con una sola ejecución de Lighthouse.

¿QUÉ ES UN LINTER DE SEO EN TIEMPO DE COMPILACIÓN?

Un linter de SEO en fase de compilación es un script que se ejecuta al final de la compilación, toma una muestra de los archivos HTML renderizados del directorio de salida y da por fallida la compilación si detecta patrones que podrían perjudicar el SEO en producción. Es el hábito de mayor impacto que incorporamos a los códigos fuente de nuestros clientes.

Lo que comprobamos

  • Cada página tiene exactamente un H1.
  • La meta descripción de cada URL indexable tiene entre 120 y 155 caracteres.
  • El atributo «lang» de HTML coincide con la ruta de la configuración regional (una página «/fr/» tiene «lang="fr"»).
  • Los grupos «hreflang» están completos y son bidireccionales en las rutas traducibles.
  • El JSON-LD de cada página cumple con las definiciones de schema.org.
  • No contiene patrones de contenido prohibido, URL falsas de redes sociales en el atributo «sameAs», texto de marcador de posición de prueba codificado de forma fija ni palabras genéricas prohibidas en la redacción publicitaria.
  • La URL canónica generada por la plantilla coincide con la URL canónica almacenada en el CMS.
  • Comprobación de imágenes WebP y dimensiones explícitas en una muestra de plantillas.

El linter se ejecuta como último paso de «npm run build». Cualquier infracción provoca que falle la compilación, lo que a su vez hace que falle la implementación. Sin él, cada regresión, una meta descripción que supera el límite, un campo SEO que alguien se ha olvidado de configurar o un emisor de esquemas que ha dejado de funcionar al cambiar el nombre de una propiedad, se publica sin que nadie se dé cuenta. Con él, la regresión se detecta antes de que salga del portátil del desarrollador.

¿CÓMO CONSEGUIR QUE AI OVERVIEWS Y PERPLEXITY CITEN TUS PÁGINAS?

Consigue que te citen escribiendo cada página relevante como una serie de fragmentos listos para citar. Un fragmento listo para citar es un título de nivel H2 en forma de pregunta, seguido inmediatamente de una respuesta directa de una o dos frases, matizaciones de apoyo en las siguientes 100-200 palabras y ningún contenido generado por JavaScript en el bloque de respuesta. Los extractores de IA extraen esa frase inicial y citan la página.

Qué otros aspectos, además de la estructura del texto, resultan útiles

  • Autoridad de la entidad, presencia en Wikipedia, esquema organizativo coherente, cuentas «sameAs» reales, menciones de la marca en toda la web abierta.
  • El archivo «llms.txt», situado en la raíz del sitio web, es un mapa del sitio web seleccionado específicamente para herramientas de IA, independiente del archivo «robots.txt» y del «sitemap.xml», que están destinados a los rastreadores tradicionales.
  • Esquema con información sobre el contenido extenso y las menciones en el mismo, que define el grafo de entidades en el que se inscribe la página.
  • Lista de permitidos del archivo robots.txt para rastreadores de IA: permite explícitamente a GPTBot, PerplexityBot, ClaudeBot, OAI-SearchBot, Google-Extended, Applebot-Extended, CCBot y Anthropic-AI. Bloquear incluso uno solo de ellos supone una interrupción de las citas autoinfligida.
  • Propiedad «speakable» en las secciones con abundantes respuestas de las páginas de formato extenso, una indicación para los extractores de voz e IA de que se trata del fragmento citable.

El seguimiento de las citas es la parte que la mayoría de los equipos se saltan. Otterly, Profound y AthenaHQ realizan un seguimiento de la cuota de citas de AI Overview y Perplexity por dominio. Nosotros añadimos un seguimiento semanal de las citas a cada interacción y lo incluimos en el informe junto con el tráfico orgánico. Si no mides las citas, no puedes saber si tu trabajo de GEO está dando resultados.

¿CÓMO TE ASEGURAS DE QUE LOS RASTREADORES DE IA PUEDAN LEER TU PÁGINA WEB?

Los rastreadores de IA solo pueden leer tu sitio web si tu archivo robots.txt permite explícitamente su agente de usuario y tu proveedor de alojamiento no los bloquea en el perímetro de la red. Es necesario que se cumplan ambas condiciones. La configuración predeterminada de Cloudflare, las reglas predeterminadas del WAF de Vercel y los plugins de seguridad predeterminados de WordPress bloquean habitualmente a los bots de IA sin previo aviso.

La lista de sitios permitidos del archivo robots.txt que incluimos

GPTBot, ChatGPT-User y OAI-SearchBot para los productos de búsqueda de ChatGPT y OpenAI. PerplexityBot y Perplexity-User. ClaudeBot, Claude-Web y anthropic-ai. Google-Extended para Bard y resúmenes de IA. Applebot-Extended. CCBot para Common Crawl, que alimenta muchos modelos de código abierto. Cohere-AI. Meta-ExternalAgent. Bytespider, el rastreador de TikTok, que suele estar bloqueado porque es agresivo y la mayoría de los proyectos no quieren que TikTok extraiga su contenido.

Lo que también tienes que hacer

El archivo robots.txt es necesario, pero no suficiente. Hay que realizar otras tres comprobaciones: el modo de lucha contra bots y la gestión de bots de Cloudflare; desactiva aquellos que bloqueen a los agentes de IA o añádelos a la lista blanca por IP y agente de usuario. El WAF y el Edge Middleware de Vercel: asegúrate de que no identifiquen a los agentes de usuario de IA mediante una expresión regular genérica. Los plugins de seguridad de WordPress, como Wordfence, suelen incluir reglas que bloquean GPTBot y PerplexityBot de forma predeterminada; añádelos explícitamente a la lista blanca. Compruébalo ejecutando «curl» con cada agente de usuario en tres URL representativas y verificando que se obtiene una respuesta 200.

FABRICADO SEGÚN LAS NORMAS DE SERVICIO DE GDS

Construimos fundaciones de SEO técnico que se alinean con el Estándar de Servicio Digital del Gobierno del Reino Unido y el Sistema de Diseño GOV.UK. El Estándar de Servicio del GDS es el conjunto más rigurosamente documentado de principios de calidad de servicio digital en el dominio público: mejora progresiva, accesibilidad a WCAG 2.2 AA, desempeño, HTML semántico, y degradación elegante cuando JavaScript falla. Lo sigo en cada compromiso de SEO técnico.

Por qué esto es importante para el SEO en concreto: los sitios web que cumplen con el GDS superan de forma sistemática los Core Web Vitals, se posicionan bien en los resultados orgánicos clásicos y son especialmente adecuados para las citas de AI Overview, ya que la claridad estructural que exige el GDS es la misma de la que se nutren los resultados de IA. El estándar es anterior a la era de la búsqueda con IA, pero encaja perfectamente en ella.

Para los clientes del Reino Unido pertenecientes al sector empresarial, al sector público y a sectores regulados, la conformidad con los estándares GDS constituye un auténtico indicador de calidad en la contratación pública. Para el resto, es un indicador de calidad que distingue el trabajo de las agencias que se conforman con un nivel más bajo.

¿EN QUÉ CONSISTE REALMENTE UN PROYECTO DE SEO TÉCNICO CON NOSOTROS?

De tres a diez semanas, tres fases, precio fijo. La primera fase consiste en una auditoría, un rastreo completo, un análisis de GSC y Ahrefs, la validación de JSON-LD, la comprobación de clústeres hreflang, la recopilación de datos de campo de Core Web Vitals y el establecimiento de una referencia de citas mediante IA. La segunda fase es la corrección: implementamos las soluciones, ya sea con tu equipo o con el nuestro. La tercera fase es la capa de linter y monitorización que evita las regresiones.

Resultados esperados de la fase de auditoría

  • Análisis completo de Screaming Frog en formato CSV, además de un informe escrito sobre los problemas más relevantes, clasificados por impacto.
  • Exportación de Search Console, informe de cobertura, consultas, rendimiento a nivel de página, con anotaciones sobre lo que resulta anómalo.
  • El validador de esquemas revisa una muestra de plantillas y genera una nota escrita sobre cada tipo que presente errores o falte.
  • Informe sobre la integridad del grupo «hreflang» en las rutas traducibles.
  • Datos de campo de Core Web Vitals extraídos de CrUX, con un gráfico de las últimas 25 semanas por métrica.
  • Resumen sobre la IA y referencia de citas de Perplexity: cuota actual y análisis de diferencias con respecto a tres competidores concretos.

La fase de rehabilitación

Trabajo de alcance fijo. Cada ticket tiene un estado inicial y un estado final bien definidos. Los entregamos por orden de prioridad y puedes dar por finalizado el proyecto en cualquier hito si se agota el presupuesto. El primer lote que entregamos siempre son los elementos que no superan el linter de compilación, ya que son los que ofrecen un retorno más rápido: sin el linter, seguirán dando errores, y una vez que el linter está implementado, todas las correcciones se mantienen.

La fase de seguimiento

Revisión automática semanal del código en los entornos de staging y producción, informe mensual de Core Web Vitals, seguimiento mensual de menciones en redes sociales mediante IA y un canal de Slack activo en el que respondo a cualquier cuestión que señalen Google o tu equipo. Te entregamos los paneles de control al finalizar el servicio para que sigas teniendo visibilidad, tanto si renuevas como si no.