Preguntas de entrevista para Especialista en SEO

Respuesta modelo

Le cuento el rediseño de la arquitectura internacional de un ecommerce de moda con operación en España, México y Argentina. Punto de partida: un único sitio con contenido mezclado, donde el 34 % de las impresiones de Google España las recibía la versión mexicana, con precios en pesos y un CTR del 0,9 % frente al 3,4 % de las páginas correctas. Diagnóstico: crucé el informe de rendimiento de Search Console por país y página con un rastreo de Screaming Frog y detecté 900 URLs sin etiqueta hreflang de retorno y 140 canonicals que apuntaban entre países, lo que hacía que Google eligiera la versión equivocada. Intervención: propuse subdirectorios por mercado, hreflang recíproco y autorreferenciado, un x-default hacia un selector de país y la retirada de los canonicals cruzados. Mi parte: el diagnóstico, la especificación técnica, la validación en preproducción y el seguimiento; la implementación la hicieron dos desarrolladores en tres sprints, y el equipo de contenido adaptó tallas y precios. Resultado en nueve meses: la versión española recuperó esas consultas, el CTR de ese conjunto pasó del 0,9 % al 3,4 % y las sesiones orgánicas en España crecieron un 64 %, en un periodo en que los tres competidores directos perdieron visibilidad en Sistrix, así que la mejora no se explica por el mercado.

Respuesta modelo

Distingo dos casos, porque el tratamiento es distinto. La canibalización clásica, entre páginas del mismo idioma y mercado, la detecto exportando de la API de Search Console el par consulta-página de los últimos tres meses y buscando consultas donde dos o más URLs se alternan en impresiones; si además la posición media oscila mucho, es señal casi segura. La resuelvo decidiendo cuál es la página canónica para esa intención y aplicando una de tres soluciones: consolidar con 301 y reescribir, diferenciar de verdad la intención de cada página, o mantener ambas y redirigir el enlazado interno hacia la elegida. El segundo caso es distinto: es-ES frente a es-MX o es-AR no es canibalización de contenido, sino de mercado. Es el mismo idioma con precios, tallas, disponibilidad y hasta vocabulario diferentes, así que la solución no es consolidar sino separar bien: hreflang recíproco entre las tres versiones, autorreferencia en cada una, x-default hacia un selector, ningún canonical cruzado entre países y contenido suficientemente diferenciado para que no sea una copia. Lo compruebo país a país en el informe de rendimiento, porque el síntoma es siempre el mismo: impresiones altas en un país servidas por la URL de otro y un CTR muy bajo. Y tengo presente que ya no dispongo del informe de segmentación internacional en Search Console, que se retiró, de modo que la validación la hago con rastreo propio y con extracción de las etiquetas.

Respuesta modelo

Sigo siempre el mismo orden, de lo más barato de descartar a lo más caro. Primero, ¿ha caído el tráfico o ha caído la medición? Compruebo el consentimiento, las etiquetas y GA4 contra Search Console, porque un despliegue que rompe el contenedor de Tag Manager produce exactamente esta imagen. Segundo, lo técnico: cobertura e indexación en Search Console, robots.txt, respuestas del servidor, un noindex escapado a producción, certificados o un pico de 5xx en los logs. Tercero, la segmentación: si la caída se concentra en una plantilla, en un directorio, en un país o en un dispositivo, ya tengo el foco; si es transversal y coincide con una fecha concreta, miro si hay una actualización confirmada de Google. Cuarto, la SERP: reviso si las consultas afectadas han cambiado de aspecto, si ha aparecido una respuesta generada por IA sobre el resultado o si un competidor nuevo ha entrado; el indicio de lo primero es una caída de CTR con la posición intacta. Quinto, la estacionalidad y la demanda: comparo con el mismo periodo del año anterior y con el volumen total de búsqueda del sector, porque a veces no hemos perdido cuota, sino que ha bajado la marea. Solo cuando tengo el diagnóstico comunico algo, y siempre diciendo qué sé con certeza, qué es hipótesis y qué necesito para confirmarla.

Respuesta modelo

Convierto la auditoría en una tabla con cuatro columnas: impacto estimado en tráfico o ingresos, esfuerzo de desarrollo estimado con el propio equipo técnico, riesgo si no se hace y confianza que tengo en la estimación. Con eso ordeno, y presento solo las diez primeras, porque una lista de sesenta puntos no se prioriza, se ignora. Después traduzco cada una al lenguaje del interlocutor: a producto no le hablo de presupuesto de rastreo, sino de que 26.000 fichas de producto no son visibles y de cuánto factura de media una ficha visible. Reservo siempre un hueco para lo que llamo victorias baratas, cambios de menos de un día que dan resultado rápido y compran credibilidad para pedir lo grande. Y llevo la evidencia por delante: cuando pedí el cambio de renderizado, no fui con una recomendación, fui con la captura del HTML renderizado en la Inspección de URL donde faltaban el 60 % de los enlaces internos. Lo que no hago es enviar el documento de la auditoría por correo y esperar: los tickets los escribo yo, con criterios de aceptación y con la forma de verificarlos en preproducción.

Respuesta modelo

Lo trato como un cambio de mezcla, no como el fin del canal. Primero mido: separo las consultas donde el CTR cae con la posición estable, que es el indicio de que hay una respuesta generada por IA encima, de las que pierden posición de verdad. En mi último proyecto eso daba seis puntos de caída de CTR en consultas informativas y prácticamente ninguna en las comerciales y transaccionales. Segundo, hago un seguimiento manual de unas ochenta consultas al mes en AI Overviews, ChatGPT y Perplexity, anotando si la marca aparece citada y con qué URL, y lo llevo al informe junto a las posiciones; la visibilidad en respuestas generadas es hoy una métrica más, no la única. Tercero, tomo decisiones: desplazar presupuesto editorial hacia intención comercial y de comparación, donde el clic sigue produciéndose; reforzar las señales de E-E-A-T que hacen que una fuente sea citable, es decir, autoría real y verificable, datos propios, marcado de Organization y Person con sameAs y fechas de actualización honestas; y asegurar que el contenido responda a la pregunta de forma directa y bien estructurada en los primeros párrafos. Lo que no hago es prometer que vamos a aparecer siempre citados, porque no hay ningún método que lo garantice, ni tocar el robots.txt para bloquear rastreadores de IA sin una decisión de negocio consciente detrás.

Respuesta modelo

Con cuatro vías, y ninguna incumple mi contrato. Primera: le describo cada caso por sector, modelo y magnitud, con las cifras en porcentajes y plazos en lugar de importes absolutos; puedo detallarle el diagnóstico y la solución tanto como quiera, porque lo confidencial es la identidad y los datos internos del cliente, no mi método. Segunda: dos de los proyectos tienen caso de éxito publicado por la agencia y se los envío. Tercera: la evolución de la visibilidad de un dominio es pública en Sistrix o en Semrush, así que si el cliente autoriza la mención, usted mismo puede comprobar la curva y las fechas sin que yo le enseñe nada interno; ya he pedido esa autorización para dos cuentas y le paso el correo de conformidad. Cuarta: tengo recomendaciones en LinkedIn del responsable de marketing de dos clientes y le doy sus contactos para que hablen con ellos. Lo que no voy a hacer, y creo que le interesa que no lo haga, es enseñarle capturas de Search Console o de Analytics de cuentas que no son mías. Si prefiere ver trabajo en crudo, tengo un proyecto propio en el que puedo darle acceso completo a los datos.

Primero comprobaría si el problema importa: el presupuesto de rastreo solo es un asunto real en sitios grandes o con cambios muy frecuentes, y aquí claramente lo es. Empezaría por el informe de indexación de páginas de Search Console para ver la distribución de motivos: rastreada sin indexar, descubierta sin rastrear, duplicada sin canónica seleccionada por el usuario o excluida por etiqueta. Después iría a los logs con Python, verificando Googlebot por DNS inverso, para medir a qué se dedican de verdad las peticiones por directorio y por plantilla; en un caso parecido, el 71 % iba a combinaciones de navegación facetada y solo el 19 % a fichas de producto. Con ese dato, la intervención tiene tres partes: reducir el espacio rastreable —documentar qué combinaciones de parámetros tienen demanda real y cuáles no, bloquear estas últimas en robots.txt y aplicar noindex, follow donde ya estén indexadas, teniendo en cuenta que la herramienta de parámetros de URL ya no existe en Search Console y que hay que resolverlo en el propio sitio—; reforzar el enlazado interno hacia las páginas que sí deben indexarse, con sitemaps segmentados por tipo para poder medir la indexación de cada bloque por separado; y mejorar el rendimiento del servidor, porque una respuesta lenta reduce el ritmo de rastreo. Mediría el efecto con dos indicadores: proporción de peticiones de Googlebot a URLs útiles y páginas indexadas por sitemap.

La implementación: una etiqueta por versión en cada página, con autorreferencia incluida, usando es-ES, es-MX y es-AR, más un x-default apuntando a un selector de país o a la versión global. Puede ir en la cabecera HTML, en la cabecera HTTP para archivos no HTML o en el sitemap XML, y prefiero el sitemap cuando el número de páginas es alto porque se mantiene desde un solo sitio. La regla que lo sostiene todo es la reciprocidad: si A apunta a B, B tiene que apuntar a A, o Google ignora el conjunto. Los errores que más veo: falta de autorreferencia; etiquetas de retorno ausentes tras una migración; canonicals cruzados entre países, que anulan el hreflang y son el fallo más caro; códigos mal formados, como es-LA, que no existe, o usar un código de idioma donde va uno de región; hreflang apuntando a URLs que redirigen o devuelven 404; y redirecciones automáticas por IP que impiden a Googlebot ver las otras versiones. Añado dos matices del mercado español: primero, que la diferenciación real del contenido importa, porque tres versiones idénticas salvo el precio invitan a que Google elija por su cuenta; y segundo, que para catalán, gallego y euskera se usan ca, gl y eu, mientras que el valenciano no tiene código propio admitido por Google, que solo procesa idioma en ISO 639-1 con región opcional. Y hay que validar por cuenta propia, porque el informe de segmentación internacional desapareció de Search Console.

INP, interacción hasta el siguiente renderizado, sustituyó a FID como métrica de interactividad de los Core Web Vitals en marzo de 2024. La diferencia es sustancial: FID solo medía el retraso de la primera interacción, mientras que INP observa todas las interacciones de la visita y se queda con una representativa de las peores, midiendo el ciclo completo hasta que la interfaz pinta la respuesta. Por eso muchos sitios que pasaban holgadamente con FID suspenden con INP. El umbral bueno está en 200 ms o menos, y por encima de 500 ms se considera malo. Para diagnosticar parto siempre del campo, no del laboratorio: CrUX a través de PageSpeed Insights o del informe de experiencia en la página de Search Console, y a ser posible datos propios de usuario real, porque INP depende de lo que hace la gente y una prueba de laboratorio no lo reproduce. Después reproduzco en Chrome DevTools con la pestaña de rendimiento y limitación de CPU, busco tareas largas en el hilo principal, escuchadores de eventos pesados y trabajo de renderizado tras la interacción. Las causas habituales que me he encontrado: gestores de consentimiento que ejecutan una tarea larguísima en el primer clic, etiquetas de terceros cargadas de forma síncrona, y componentes que rehidratan de más. En mi último proyecto, aplazar dos etiquetas y trocear la tarea del gestor de consentimiento explicó el 80 % de la mejora, de 340 ms a 180 ms.

Comparo tres cosas: el HTML de origen, el HTML renderizado y lo que ve Google. Empiezo por la Inspección de URL de Search Console, que devuelve el HTML renderizado y la captura, y por una prueba de la herramienta de resultados enriquecidos; si el contenido y los enlaces no aparecen ahí, el problema es de renderizado, no de contenido. También rastreo con Screaming Frog en modo JavaScript y comparo el resultado con el rastreo sin JavaScript: la diferencia entre ambos es exactamente lo que Google podría perderse o retrasar. Los fallos que encuentro casi siempre: paginación y navegación construidas con elementos que no son enlaces con atributo href, de modo que no hay nada que seguir; contenido que solo se carga al hacer scroll o al pulsar; rutas que dependen del fragmento tras la almohadilla; llamadas a la API bloqueadas por robots.txt; y tiempos de respuesta que hacen que el renderizado se retrase días. La solución que suelo proponer es renderizado en servidor o generación estática para las plantillas que deben posicionar, dejando el renderizado en cliente para lo que no necesita indexarse, además de exponer siempre la navegación como enlaces reales. En un caso, pasar los listados a renderizado en servidor con Next.js llevó las categorías indexadas de 780 a 2.340 en tres meses.

Como base, en JSON-LD: Product con Offer —precio, moneda, disponibilidad y política de envíos y devoluciones, que Google admite en el marcado del comerciante—, AggregateRating y Review solo si son reseñas reales y visibles en la página, BreadcrumbList en todas las plantillas, Organization en la portada con sameAs y datos de contacto, y LocalBusiness en las páginas de tienda física. Para el blog, Article con autor real enlazado a una ficha de Person. Lo que ha cambiado y conviene saber: los resultados enriquecidos de preguntas frecuentes quedaron restringidos en 2023 a un conjunto muy pequeño de sitios oficiales y sanitarios, de modo que marcar FAQPage en un ecommerce ya no produce resultado enriquecido, aunque el marcado no haga daño; y el formato de instrucciones paso a paso dejó de mostrarse. La regla que no cambia es que el marcado debe describir contenido visible en la página: inventar valoraciones o precios distintos de los mostrados es motivo de acción manual por incumplimiento de las directrices. Y validaría siempre con la prueba de resultados enriquecidos y con el informe correspondiente de Search Console, no solo con el validador de Schema.org, porque no todo lo válido es admisible para Google.

Los proceso con Python y pandas, porque el volumen habitual —decenas de millones de líneas al mes— no cabe cómodamente en una hoja de cálculo. El primer paso, y el que más gente se salta, es verificar que Googlebot es Googlebot: DNS inverso y resolución directa, o contraste con los rangos de IP publicados por Google, porque una parte notable del tráfico que se identifica como Googlebot no lo es. Después construyo siempre las mismas vistas: reparto de peticiones por directorio y por plantilla, para ver dónde se gasta el rastreo; distribución de códigos de estado, con foco en 404 recurrentes, cadenas de redirección y picos de 5xx; frecuencia de rastreo de las URLs que importan frente a las que no; URLs rastreadas que no están en el sitemap, que suelen delatar espacios generados por parámetros; y URLs del sitemap que Googlebot no visita desde hace semanas. El cruce más útil es el de los logs con el rastreo de Screaming Frog y con la exportación de la API de Search Console: así se ven de un vistazo las páginas que se rastrean pero no se indexan, las que se indexan pero no reciben impresiones y las huérfanas que Google conoce y el sitio ya no enlaza. De ese informe salieron tres de los cuatro proyectos técnicos que conseguí que se aprobaran ese año, porque es la evidencia que convence a producto.

Primero asumo que el problema es mío: seguramente no he traducido el impacto a algo que le importe a quien prioriza. Rehago la petición en términos de negocio —26.000 fichas de producto no visibles, con una facturación media conocida por ficha— y la acompaño de una estimación de esfuerzo hecha con el propio equipo técnico, no inventada por mí, porque una recomendación sin coste estimado no entra en ninguna planificación. Después busco una prueba barata: propongo aplicar el cambio a una sola categoría o a un subconjunto de plantillas y medirlo en seis semanas; un piloto con resultado convence más que cualquier auditoría. También hablo antes con la persona que va a implementarlo, para que el ticket llegue entendido y sin sorpresas. Si aun así no avanza, lo escalo con datos y sin dramatismo a quien puede decidir, presentando el coste de no hacerlo y una alternativa más barata. Y acepto la respuesta si la decisión es que no: dejo constancia escrita del riesgo, y si el problema reaparece, la conversación ya está documentada.

No me opongo a la herramienta, me opongo al plan tal y como está. Explico el riesgo con lo que sabemos: Google no penaliza por usar IA, penaliza el contenido creado a escala sin valor propio, y las actualizaciones recientes han castigado con dureza justo ese patrón; además, el riesgo no se limita a esos artículos, porque un volumen grande de contenido flojo puede arrastrar la percepción de calidad de todo el sitio. Propongo una alternativa concreta en lugar de un no: un piloto de veinte artículos sobre consultas con demanda comprobada, con IA como apoyo en la documentación y el borrador, pero con una persona experta que aporte datos propios, ejemplos y criterio, autoría real y verificable, revisión editorial y una medición a noventa días de indexación, posiciones y conversión. Si funciona, se escala con el mismo estándar; si no, hemos perdido veinte artículos y no doscientos. Y añado el argumento de oportunidad: con las respuestas generadas por IA en el buscador, el contenido que se limita a repetir lo que ya existe es precisamente el que deja de recibir clics, así que producir más de lo mismo es invertir en el formato que está perdiendo valor.

Empiezo reconociendo el hecho, porque negarlo resta credibilidad: en España el mercado de enlaces de pago en prensa es habitual y a corto plazo funciona en algunos sectores. A continuación pongo el riesgo sobre la mesa sin exagerarlo: son enlaces contrarios a las directrices, el riesgo no es tanto una penalización manual inmediata como que Google deje de contarlos, con lo que el gasto se convierte en recurrente y no acumulativo, y hay que sumar el efecto de las políticas contra el abuso de la reputación de sitios ajenos, que ya ha afectado a secciones patrocinadas de medios grandes. Después ofrezco la alternativa con cifras propias: con PR digital basada en datos —tres estudios al año con datos internos cruzados con estadísticas del INE y envío segmentado a periodistas— conseguí 74 enlaces editoriales en once meses, dieciocho de dominios con DR superior a 70, con un coste inferior al de una campaña de compra equivalente y sin riesgo. Si la decisión final es comprar, la respeto porque no me corresponde a mí, pero pido tres cosas por escrito: que se marquen como patrocinados los enlaces que corresponda, que se limite a un porcentaje pequeño del perfil y que se registre la decisión y su motivo, para que dentro de un año se pueda evaluar con honestidad.

Lo primero es no discutir sobre el pasado, sino averiguar el alcance real en las siguientes horas: si cambia solo el dominio o también las URLs, la plantilla, el gestor de contenidos y el servidor, porque cada cosa añadida multiplica el riesgo. Con eso pido lo mínimo imprescindible: un inventario completo de URLs actuales, un mapa de redirecciones 301 una a una para las páginas con tráfico y enlaces —nunca una redirección masiva a la portada—, acceso a un entorno de preproducción abierto solo para el equipo, y una fecha que no sea viernes ni víspera de campaña. Después preparo el antes y el después: rastreo completo guardado, exportación de rendimiento de Search Console de dieciséis meses, inventario de los enlaces externos más valiosos y línea base de métricas por plantilla. El día del lanzamiento, verificación inmediata de robots.txt, de que no viaja ningún noindex, de las canonicals, del hreflang si lo hay, del sitemap nuevo y de una muestra de redirecciones. Después, seguimiento diario durante las primeras semanas y contacto con los sitios que enlazan las páginas más importantes para que actualicen la URL. Y si en dos semanas no es posible reunir el mapa de redirecciones, digo con claridad qué se arriesga y propongo un aplazamiento corto: la conversación incómoda de hoy es mucho más barata que recuperar el 40 % del tráfico durante seis meses.