Indexar en Google en 2026: lo que aprendimos en la Search Central Live Deep Dive Europe

Google nos invitó a la Search Central Live Deep Dive Europe 2026, el congreso que organiza para profesionales del SEO y que este año se ha celebrado en Barcelona. El primer día se dedicó a cómo rastrea Google la web. El segundo, a cómo la interpreta y decide qué guarda en el índice. Este artículo recoge ese segundo día, ordenado con un hilo común: entender cómo procesa Google el contenido de nuestra web para saber qué hacer para que se indexe.

Es el formato más técnico de los Search Central Live: sesiones largas con el equipo de Google Search y espacio para preguntar. Para una agencia que trabaja SEO y desarrollo es una ocasión de escuchar de primera mano cómo funcionan sus sistemas y contrastarlo con lo que vemos cada día en los proyectos de clientes.

Indexar ha dejado de ser un trámite. Google solo guarda una parte pequeña de lo que encuentra, y el contexto ha cambiado: hay cada vez más webs y aplicaciones construidas con JavaScript, muchas ya generadas con IA; la página de resultados incorpora resúmenes y módulos que hacen que no todo sea un enlace azul (lo tratamos en SEO en 2026), y los asistentes de IA leen la web con capacidades distintas a las de Google. Si la página no llega bien al índice, el resto del trabajo SEO no sirve de nada.

El artículo sigue el recorrido que hace una página desde que Google la encuentra hasta que decide si la guarda. En cada paso explicamos qué hace Google, dónde suelen fallar las webs y qué conviene revisar. Son nuestras notas de las ponencias, no documentación oficial de Google: para los detalles finos, la documentación de Search Central sigue siendo la referencia. Si algún concepto no te suena, nuestro Diccionario SEO los recoge.

El recorrido de una página hasta el índice

Desde que Google encuentra una URL hasta que decide guardarla hay seis pasos:

1. Google decide qué URLs visita y con qué ritmo, y las descarga.
2. Parsing del HTML. Lee el código, separa el contenido principal del resto, mira el head y extrae los enlaces y las metaetiquetas robots.
3. Si la página depende de JavaScript y CSS, pasa por una segunda cola donde se ejecuta y se ve como la vería un usuario.
4. Deduplicación. Agrupa páginas con contenido igual o muy parecido y elige la más representativa.
5. Extracción de características y de señales. Datos estructurados, imágenes, vídeo, idioma, país, frescura y calidad.
6. Selección para el índice. Con todo lo anterior, decide si la página entra.

Un problema en un paso condiciona los siguientes. Una página que Google no puede renderizar no llegará bien interpretada a la deduplicación, ni a las señales, ni al índice. Por eso lo más útil es saber en qué paso se pierde cada página.

Rastreo: el acceso y el presupuesto

Google no rastrea toda la web ni siempre al mismo ritmo. Lo que visita depende de lo que encuentra y de cómo responde el servidor, y eso es el crawl budget. El primer día del congreso se habló sobre todo de esto, y las respuestas del servidor son lo que más lo afecta:

Para ver estas respuestas en la práctica, tenemos la guía de Google Search Console y un post sobre cómo solucionar errores 5xx y 4xx.

Otras decisiones que se aclararon:

• Sitemaps HTML. No hace falta hacerlos, y mal implementados pueden hacer daño.
• Sitemap en el robots.txt. Es preferible, pero queda público para todo el mundo, también para quien no nos interesa. Si solo queremos que lo encuentre Google, basta con enviarlo desde Search Console.
• El robots.txt no es un sistema para desindexar. Si bloqueamos una URL por robots, Google puede indexarla igualmente, pero sin contenido. Para sacar una página de la búsqueda hace falta noindex, y para que Google lo lea la URL tiene que ser rastreable. Lo explicamos en el post cómo desindexar una URL de Google.
• Productos agotados. Depende del caso. Si el producto es importante, exclusivo, difícil de encontrar y el usuario puede esperar, lo más seguro es mantener el 200 con preorder o una acción que no genere frustración. Si volverá pronto, 200 con el stock indicado en los datos estructurados; ni 404 ni redirección.

El HTML: qué lee Google y en qué orden

Cuando Google llega a una página, hace un parsing del HTML siguiendo los elementos del DOM. Primero separa lo que considera contenido principal del resto. Después lee el head (canonical, hreflang, title), extrae los enlaces y consulta las metaetiquetas robots.

Los enlaces

Los enlaces son la forma en que Google descubre páginas nuevas, y tienen que ser . Cualquier otra solución es un riesgo.

En webs hechas con frameworks de JavaScript es una de las primeras cosas que mirar: si el menú o los productos se abren con un onclick o un routerLink, Google no los ve como enlaces.

Metaetiquetas robots

En el head se pueden indicar reglas para todos los robots o para uno concreto. Las que hay que conocer:

Las directivas de limitación son una decisión de negocio: si damos toda la respuesta en la página de resultados, el usuario no tiene motivo para hacer clic. Aun así, para la mayoría de webs el objetivo es la máxima visibilidad, y la combinación que recomendó la ponencia es esta:

max-image-preview:large, max-snippet:-1

Dos precisiones más. El robots.txt manda: si bloquea el acceso a recursos que después queremos potenciar con metaetiquetas robots, estas no sirven de nada. Y se pueden incluir metaetiquetas robots mediante JavaScript, pero es inestable, sobre todo ante cambios. Mejor evitarlo.

JavaScript, el camino largo

Google ha mejorado mucho el rastreo y la indexación de contenido en JavaScript, pero todavía no es perfecto. Lo que quiere es entender lo que ve una persona para saber si la página responde, y no siempre lo consigue. A la primera, casi nunca.

Una página con JS pasa por dos colas: la del HTML y, después, la de renderizado. El camino es algo más largo, pero si el contenido está bien servido, Google acaba recogiéndolo. Lo que hay que tener claro es que CSS y JS cambian cómo se ve la página, y el resultado puede ser muy distinto al del HTML desnudo. Si Google no puede renderizar bien, la mayoría de enlaces y menús no los recoge.

Si la web está hecha con React, Vue o Next.js, nuestra guía de SEO para webs con base JavaScript entra en más detalle.

Qué hay que vigilar

• Enviar por JS atributos SEO básicos como el title y la meta description. En la ponencia se mostró un caso real donde eran distintos en el HTML bruto y en el renderizado.
• Actualizar información con JS (datos, precios), lo que puede alterar lo que Google indexa.
• Inyectar texto desde campos de la base de datos.
• Timeouts de renderizado.
• Violaciones de Content Security Policy (CSP).
• Recursos bloqueados por JS o por robots.txt.
• Exceso de JS externo que no controlamos y que difícilmente podremos ofrecer en HTML.

Caso mostrado en la ponencia: el title y la meta description del HTML bruto no coinciden con los del renderizado.

[Archivo: title-meta-description-html-vs-renderizado.png · ALT: Comparativa entre HTML bruto y renderizado en una página de Lidl donde el title y la meta description cambian con JavaScript]

Los errores que más se ven

1. Contenido que no está en el HTML renderizado. Si no está en el DOM final, Google no lo ve. Pasa cuando el JS no es accesible para Googlebot o cuando las APIs que hay que cargar están bloqueadas o no responden. Es habitual en scrolls infinitos, donde Google solo recoge la primera parte.
2. Fragmentos (#) en la URL cuando cambia el contenido. Google no los procesa. La solución es la History API, con URLs con path o parámetro: /path/products y /?path=products funcionan, /#path=products
3. Soft 404. La aplicación muestra un "no encontrado" pero responde 200, o la página llega rota. Antes eran páginas vacías o pobres; ahora a menudo son errores reales servidos con un 200 vía JS. Hay que revisar las respuestas de servidor de las páginas que Google rastrea y ajustarlas a la realidad.
4. Recursos bloqueados. Todavía hay muchos robots.txt que bloquean el JS o endpoints de API que la página necesita para renderizar.

[Archivo: puntos-ciegos-javascript-seo.png · ALT: Resumen de puntos ciegos con JavaScript (cambios de contenido, enlaces invisibles, timeouts, CSP y recursos bloqueados)]

Cómo depurarlo

Método para encontrar la petición que hay detrás del contenido que falta.

1. En Chrome, abrir la pestaña Network, filtrar por Fetch/XHR y recargar la página.
2. Localizar la llamada que suministra el contenido que falta: ¿se ha ejecutado? ¿Ha devuelto datos? ¿Se ha bloqueado?
3. Si sigue faltando, buscar el texto en todos los scripts cargados con Cmd/Ctrl + Shift + F.
4. En Search Console, hacer una inspección de URL, probar la URL publicada y ver la página probada. Hay que mirar la captura de pantalla, el HTML renderizado y los mensajes de la consola de JavaScript. El Rich Results Test sirve igual.
5. Comparar el código fuente con el DOM y revisar los recursos bloqueados.

Un detalle que conviene recordar: el servidor puede responder 200 y el contenido JS estar roto, y entonces Google lo trata como un soft 404. Nosotros lo probamos durante la sesión con una página de nuestra web: la URL estaba disponible para Google y solo mostró dos avisos de consola por recursos precargados que no se utilizaban.

JavaScript, IA y renderizado en servidor

Los sistemas de Google recogen bastante bien el contenido en JavaScript, pero otros asistentes de IA todavía no. Por eso lo más seguro es servirlo con SSR, es decir, renderizado en servidor. Vale la pena preguntarse también si los bots de IA pueden acceder a todo el contenido de la web, en el caso de que queramos que lo hagan.

El headless CMS es limpio y seguro, pero el resultado suele ser poco legible para Google, aunque el usuario lo vea bien. Se puede compensar en parte con un buen marcado de datos estructurados.

Para aplicaciones generadas con IA que después hay que entregar para que se indexen, la ponencia presentó el reframing con web fragments, que sirve la app como fragmentos aislados dentro de la página. Todavía cuesta encontrar estándares y queda camino, así que conviene seguirla de lejos. También salió WebMCP, que cobra importancia en la era agéntica.

Cómo entiende Google una página

Google separa tres zonas cuando llega a una página: header, navegación y contenido principal. Y da cada vez más peso a la tercera. Por eso, muchas veces, el título y la descripción que muestra en los resultados no son los que le hemos entregado en el head.

La consecuencia es práctica: todo lo que sea importante tiene que ir en el contenido principal, pero con criterio, sin cargarlo de todo. En la ponencia lo ilustraron con un post de un blog personal: el título y el texto del cuerpo se consideran importantes, mientras que las categorías o el pie de página pesan menos.

Contenido principal frente a contenido secundario, con un post del blog de John Mueller como ejemplo.

Lo que Google guarda en el índice tampoco es la página como texto. Tokeniza el contenido: separa cada palabra, registra su posición y la zona de la página donde está (cabecera, pieza central), y asigna cada palabra a las URLs donde aparece. Así intenta entender de qué va el contenido y en qué formato está. Tiene problemas graves con las lenguas que no separan las palabras con espacios.

Cómo se separan las palabras al guardar una página en el índice, y por qué las lenguas sin espacios lo complican.

Esto no es el chunking que hacen los modelos de IA. Google busca contexto y no necesita el contenido cortado en fragmentos: no tiene sentido optimizarlo en bloques pensando en Google. Para otros modelos de IA sí puede tenerlo, de momento.

La tokenización que hacen los modelos de IA, que no es lo que Google guarda en su índice.

Duplicados y canonicals

Google considera que el usuario no quiere ver páginas iguales, y deduplicar también le ahorra tiempo de rastreo para leer páginas nuevas. El proceso tiene tres pasos:

1. Entiende clusters de contenidos, los relaciona y los diferencia dentro del cluster.
2. Agrupa las páginas, elige la más representativa y la indexa.
3. Revisa señales adicionales (enlaces, etc.) para tener más contexto.

Si las páginas son iguales, canonicaliza. Si están en idiomas distintos, consulta el hreflang y lo respeta. También guarda las marcas: en un rebranding intenta relacionar la marca antigua con la nueva, de modo que quien busque la antigua vea la nueva. Y el mismo criterio vale para las migraciones de contenido.

Dónde suelen aparecer duplicados

• Redirecciones mal hechas. Tienen que ir hacia contenido equivalente. Si no lo es, no se traslada el SEO acumulado.
• La misma web servida con y sin www, o con http y https. Parece mentira, pero todavía se encuentra a menudo.
• Estructura de URLs poco clara. En la ponencia lo ilustraron con /buy/fax, /buy/typewriter y /office-equipment/ como posibles duplicados, y con /barcelona/services, /madrid/services y /valencia/services como páginas casi idénticas. Si solo cambia el nombre de la ciudad, hay que preguntarse si vale la pena rastrearlas todas.
• El mismo contenido para distintos países, o redirecciones automáticas por geolocalización. Aquí hay que usar hreflang.
• Bloqueadores de bots. Algunos afectan también al rastreo de Google.

Canonicals: buenas prácticas

Hay que poner siempre la rel canonical, aunque Google la revisa y no siempre sigue lo que le decimos. Las discrepancias se revisan en Search Console. En concreto:

• Agrupar las URLs canonicalizadas para entender los casos (paginación, parámetros, idioma).
• Evitar cadenas de canonicals y canonicals que apunten a una URL que no responde 200.
• Comprobar que la canonical del HTML coincide con la que se sirve después con JavaScript. Cuando no coinciden, Google se puede liar, y es un fenómeno nuevo.
• Hacer el enlazado interno siempre hacia la URL canónica. Si enlazamos URLs no canónicas, Google acaba llegando a la buena, pero le hacemos perder tiempo y presupuesto.
• En paginación y filtros, canonicalizarlo todo a la primera página normalmente no tiene sentido.

Cuando la canonical que elige Google no es la nuestra, la causa suele ser una de estas:

1. Un intento de hijacking: dominios duplicados, entornos de staging abiertos que no deberían estarlo, o robo de contenido.
2. Problemas graves en la página: velocidad de carga, seguridad, HTTPS.
3. Señales incorrectas en el header, en el sitemap o en el robots.txt.

Lo primero que hay que hacer es revisar que la página que queremos sea indexable y que el HTML y el renderizado sean correctos. Si nada de esto lo explica, se puede probar a redirigir la URL indexada hacia la buena.

Con el hreflang hay un matiz: en páginas con el mismo idioma para muchos países, Google acaba indexando una o unas cuantas URLs, por mucho que las marquemos todas. Conviene decidir cuál es la URL principal y trabajar para que sea la que Google elija.

La ponencia lo cerró con siete recomendaciones: usar redirecciones en migraciones, usar códigos de respuesta HTTP y no bloquear agentes, revisar los rel canonical, usar hreflang para ayudar a localizar, reportar canonicals extrañas en los foros, hacer páginas seguras que funcionen y mantener las señales canónicas claras.

Datos estructurados, imágenes y vídeo

Cuando Google ya tiene el HTML, hace una extracción de características: coge el HTML general, guarda aparte las imágenes y los vídeos y extrae los datos estructurados. La página de resultados actual está llena de módulos que no son los diez enlaces azules, y casi todos salen de aquí.

Datos estructurados

Para Google es más fácil, y más barato, leer datos estructurados que interpretar el contenido visible, como hace la IA. Además, permiten dar información que no está en la página y ayudan a los robots a centrarse en el contenido relevante. Hacen la página elegible para rich results, para funciones de sitio y de página (nombre del sitio, breadcrumb) y para visibilidad en Discover. Varios estudios apuntan a que una buena implementación puede aumentar el tráfico orgánico.

Cómo trabajarlos:

• Seguir los estándares de schema.org.
• Formato recomendado: JSON-LD. Hay otras opciones, pero es más sencillo de hacer funcionar y da menos errores.
• Un exceso no penaliza, pero conviene no añadir elementos secundarios y centrarse en lo importante.
• Google no usa todos para mostrar resultados. La galería de búsqueda indica cuáles.
• Validar con el Rich Results Test.

Para e-commerce hay novedades: ahora se pueden enviar el programa de fidelidad, la política de envío y la categoría de producto.

Imágenes

Las imágenes tienen cada vez más presencia en Search, Discover y otras superficies. Google las extrae del HTML con los elementos y . Las que solo están referenciadas como background-image de CSS no se indexan de forma fiable. Mejor ; también las recoge, pero conviene evitarlo.

Dentro de la imagen, Google usa:

1. src: tiene que estar disponible y no bloqueada.
2. alt: debe describir la imagen a alguien que no la ve, sin llenarlo de keywords. Más detalles en la guía del ALT text.
3. title: puede aportar contexto complementario al alt.

El resto de atributos se ignoran. Sí lee las palabras que rodean la imagen para coger contexto. Como buenas prácticas, conviene incluirlas en los sitemaps, ofrecer varios formatos y tamaños, usar AVIF y WebP siempre que se pueda y buscar el equilibrio entre calidad y compresión. Tenemos más detalles en el post de SEO para imágenes.

Vídeo

El peso del vídeo depende de la intención de búsqueda. Aparece en Search, YouTube y Discover, ahora con previsualizaciones y momentos clave. El marcado de vídeo en el HTML es muy importante. Las buenas prácticas son:

• Una URL para cada vídeo.
• Títulos y descripciones trabajados y miniaturas atractivas.
• Datos estructurados y vídeos en los sitemaps.
• Formato mp4 preferente.
• El vídeo, dentro del contenido principal y al principio de la página, con el texto que lo rodea trabajado.
• Vigilar el tiempo de carga de la página.
• Plataformas como YouTube o Vimeo, que ya los distribuyen, y moverlos por otros canales como las redes sociales, porque genera señales. Para YouTube, tenemos un post de SEO en YouTube.

Imágenes y vídeo tienen robots propios en Google, de modo que se pueden bloquear por separado con el robots.txt o gestionar con metaetiquetas robots. Para Discover, max-image-preview:large. Y sobre el contenido generado con IA, la recomendación es revisarlo antes de publicarlo.

Idioma y mercado: SEO internacional

Google identifica el idioma por el contenido de la página, no por la URL ni por el hreflang. Por eso hay que evitar más de un idioma en una misma URL. Para saber a qué país se dirige una web, mira varios factores:

1. Dominio de primer nivel geográfico (.es, .sg...). Es la señal más fuerte. Tener un dominio propio por país es lo mejor, pero no siempre es viable; si no lo tenemos, hay que reforzar el resto.
2. Hreflang, en etiquetas, cabeceras o sitemaps.
3. Ubicación del servidor (dirección IP).
4. Otras señales: idioma, moneda, enlaces y perfil de negocio.

Google no varía la ubicación del rastreador para detectar versiones distintas de una misma página, e ignora las metaetiquetas de localización tipo geo.region.

El SEO multiidioma gana importancia en el contexto de la IA. Se puede traducir con IA, pero hay que revisar la calidad de la traducción. Y a menudo no basta con traducir: hay cuestiones legales, de contexto y culturales. La moneda, las ofertas y promociones, las opiniones y reseñas, la reputación de marca o la durabilidad del producto pesan distinto según el país. La ponencia lo ilustró con datos de Think with Google sobre qué valoran los compradores de Estados Unidos y de Europa, y con diferencias entre países como Alemania y Francia. Traducir con IA puede quedarse corto para este tipo de factores, y dependerá de los recursos y de los riesgos de cada proyecto.

El SEO internacional no se resuelve con traducciones, ni siquiera con un buen hreflang:

• El mismo catálogo, con los mismos precios y fotos, puede vender mucho en un país y nada en otro.
• Si hay varios países con la misma lengua y dialectos, hay que adaptarla: castellano, inglés o francés en países distintos.
• Hay que valorar la autoridad que tenemos en cada país. ¿Nos conocen? ¿Hemos ganado premios? ¿Tenemos tiendas físicas? ¿Hacemos promociones? Un buen hreflang no lo compensa.
• A veces habrá que cambiar fotos, precios o promociones para adaptarse al mercado.

Para profundizar, recomendamos el artículo de Alizée Baudez sobre SEO internacional.

Sobre cómo estructurar la web por mercados, tenemos un post dedicado a SEO internacional: dominio, subdominio o carpeta.

Señales y selección del índice: qué entra y qué no

Google solo indexa una parte pequeñísima de las páginas que encuentra. Intenta quedarse con las que dan más satisfacción a los usuarios, y la selección se hace al final, cuando ya ha analizado contenido y señales. Para decidirlo necesita saber si el contenido es fiable y relevante.

La esencia no ha cambiado: contenido útil, original, bien estructurado y bien escrito, con buenos metadatos y schema. PageRank sigue existiendo, pero se ha refinado. Las señales que se destacaron son cuatro:

• País e idioma. Detecta la lengua y el país o región de destino. La indexación puede variar por dominio, por presencia o porque hay menos recursos para lenguas minoritarias. Es normal que una web en castellano y catalán indexe mejor en castellano.
• Siempre se tiene en cuenta, y más en búsquedas que necesitan resultados recientes. Una página puede estar indexada pero sin visibilidad, y a la larga se puede desindexar.
• Safe Search. Hay mucho cuidado con el contenido explícito.
• Google encuentra páginas de spam a espuertas y se lo toma como una prioridad, especialmente con IA: contenido artificial, masivo, peligroso o suplantaciones. Aun así, tiene dificultades para detectarlo.

Hay también señales negativas que sacan una página de la carrera: el noindex, el contenido caducado (unavailable_after), el soft 404, los duplicados y las señales de spam. Las señales de usuario también cuentan.

Los estados de Search Console

Dos estados del informe de indexación de páginas tienen una lectura clara:

• Discovered, currently not indexed. Google sabe que la URL existe pero no la ha rastreado del todo. Está en la cola, y se ha gastado crawl budget.
• Crawled, currently not indexed. Google ya la ha analizado y no la considera elegible. Volver a enviarla no sirve si no hay un cambio sustancial. Normalmente es contenido pobre, duplicado o desfasado.

Qué pasa en el índice

Google tokeniza el contenido y etiqueta cada token con la zona de la página donde está (por ejemplo, cabecera o pieza central). Después construye una posting list: cada palabra queda asociada a las URLs donde aparece, etiquetada por formato. Así intenta entender de qué va el contenido y en qué formato está.

Respuestas rápidas a casos habituales

Si quieres entender por qué Google reescribe los títulos, nuestro post sobre cómo elige Google los títulos de las páginas lo detalla.

El contenido sigue siendo el rey, según la ponencia, y tiene sentido: todo el sistema descrito hasta aquí existe para decidir qué contenido vale la pena guardar.

Para decidir qué contenido vale la pena crear, una buena fuente es Google Trends, que también se presentó en la ponencia. Tiene datos desde 2004 hasta pocos minutos atrás, combina búsqueda de texto, imágenes y shopping, y sirve tanto para tendencias a largo plazo como para temas del momento. Es una buena herramienta para estudios de marketing, para tomar decisiones de SEO o SEM y para presentar datos a cliente. No incluye Discover, porque allí el usuario no busca.

Por dónde empezar

Todo lo anterior se puede convertir en una revisión ordenada. Este es el orden que proponemos, de más rápido y con más impacto a más trabajo.

Revisiones rápidas

1. txt. Que no bloquee JS, CSS ni APIs necesarias para renderizar, y que el sitemap esté enviado a Search Console.
2. Search Console. Mirar los soft 404 y los estados "Discovered" y "Crawled, currently not indexed". No reenviar URLs sin cambios. Esta revisión forma parte de cualquier auditoría SEO.
3. Enlaces de navegación. Que todos sean , también en los menús y los filtros.
4. Autorreferenciales, sin cadenas, hacia URLs que respondan 200, y con enlazado interno siempre a la versión canónica. Comprobar www y sin www, http y https.
5. Metaetiquetas robots. max-image-preview:large y max-snippet:-1, salvo donde haya un motivo para limitarlo.

Revisiones con más trabajo

1. Comparar HTML bruto y DOM renderizado. Title, meta description, canonical y enlaces tienen que estar en el HTML inicial. En webs con mucho JS, valorar SSR. Para los equipos de desarrollo, tenemos unas directrices SEO imprescindibles.
2. Datos estructurados. JSON-LD validado con el Rich Results Test, centrado en lo importante.
3. Imágenes y vídeo. con alt descriptivo, formatos WebP o AVIF, sitemaps, y una URL y un marcado para cada vídeo.
4. Landings de ciudad con el mismo contenido, versiones por país y hreflang.

En proyectos nuevos

1. Redirecciones una a una hacia contenido equivalente. Más detalles en migración web y SEO.
2. Webs multipaís. Adaptar precios, moneda, promociones y reseñas, y valorar la autoridad local en cada mercado.
3. Aplicaciones generadas con IA. Pensar desde el diseño cómo se entregará el contenido para que Google lo indexe.

Documentación de Google

Las fuentes oficiales de cada tema, para contrastar lo que hemos explicado. Toda la documentación está en inglés.

• Rastreo:gestión del crawl budget en webs grandes e introducción al robots.txt.
• Metaetiquetas robots:robots meta tag, data-nosnippet y X-Robots-Tag.
• fundamentos de SEO para JavaScript y cómo depurar problemas de JavaScript en la búsqueda.
• Canonicals y duplicados:qué es la canonicalización y consolidar URLs duplicadas con canonicals.
• Datos estructurados:introducción, galería de búsqueda y Rich Results Test.
• Imágenes y vídeo:buenas prácticas para imágenes y buenas prácticas para vídeo.
• SEO internacional:versiones localizadas y hreflang.
• Search Console:informe de indexación de páginas y herramienta de inspección de URLs.
• Tendencias de búsqueda:Google Trends.

Y dos referencias técnicas mencionadas en la ponencia: la History API (MDN) para las URLs en aplicaciones de una sola página y Web Fragments para la entrega de apps generadas con IA.

Cómo lo trabajamos en La Teva Web

La indexación es un tema en el que SEO y desarrollo tienen que hablarse. Muchas de las decisiones que determinan si Google ve bien una web (cómo se renderiza, cómo se generan los enlaces, qué responde el servidor) son de desarrollo y se toman antes de que nadie piense en SEO. En La Teva Web trabajamos con equipo propio, sin subcontratar, y eso nos permite revisar estos puntos con quien construye la web.

Si quieres saber en qué paso del recorrido se pierden las páginas de tu web, escríbenos y hacemos una revisión de indexabilidad. Puedes ver cómo trabajamos el SEO en nuestra agencia SEO de Barcelona y repasar los fundamentos en la Guía SEO.