Indexación de Next.js en Google: la guía completa para App Router y Pages Router
Navega por SSG, SSR, ISR y componentes de cliente para que cada ruta sea descubrible por Google
En esta guía
Next.js es el framework de React más popular para apps en producción, y su modelo de renderizado --que abarca SSG, SSR, ISR y renderizado en cliente-- crea tanto oportunidades potentes como trampas de indexación sutiles. Algunas rutas sirven HTML perfecto en la primera petición; otras envían un cascarón vacío que requiere ejecución de JavaScript.
Esta guía cubre tanto el App Router como el Pages Router, recorriendo la Metadata API, generateStaticParams, sitemaps programáticos con sitemap.ts, configuración de robots.ts, datos estructurados y las trampas específicas que hacen que las páginas de Next.js aparezcan en blanco para Googlebot.
Estrategias de renderizado y su impacto en la indexación
Next.js ofrece cuatro estrategias de renderizado, y cada una tiene implicaciones distintas sobre cómo (y si) Googlebot ve tu contenido.
Static Site Generation (SSG) es el estándar de oro para la indexación. Las páginas se renderizan a HTML completo en tiempo de build y se sirven como archivos estáticos. Googlebot recibe el HTML completamente formado al instante, sin necesidad de ejecutar JavaScript. En el App Router, cualquier Server Component que no llame a funciones dinámicas (como cookies(), headers() o searchParams) se renderiza estáticamente por defecto. En el Pages Router, consigues SSG exportando getStaticProps.
Server-Side Rendering (SSR) genera HTML en cada petición. Googlebot recibe HTML completo igual que con SSG, pero la página no se cachea (a menos que añadas cabeceras de caché). El SSR se activa en el App Router usando funciones dinámicas o estableciendo export const dynamic = "force-dynamic" en un segmento de ruta. En el Pages Router, usas getServerSideProps. El SSR es fiable para la indexación pero más lento que el SSG porque cada petición de rastreo dispara un renderizado completo.
Incremental Static Regeneration (ISR) es un híbrido: la página se genera estáticamente en tiempo de build, se sirve desde la caché y se regenera en segundo plano tras un intervalo de tiempo configurable. En el App Router, el ISR se consigue estableciendo export const revalidate = 3600 (en segundos) en una página o layout. En el Pages Router, añades revalidate al valor de retorno de getStaticProps. El ISR es excelente para la indexación: Googlebot recibe HTML estático rápido, y el contenido se mantiene razonablemente fresco.
El renderizado en cliente (CSR) es donde surgen los problemas de indexación. Si un componente está marcado con "use client" y obtiene datos en un hook useEffect, el HTML inicial enviado al navegador (y a Googlebot) no contiene nada más que un estado de carga. Aunque Googlebot puede ejecutar JavaScript hasta cierto punto, procesa el JavaScript en una pasada de indexación secundaria que puede ocurrir horas o días después, y la obtención de datos compleja en el cliente a menudo falla silenciosamente en el entorno de renderizado de Google.
La regla: cualquier contenido que quieras indexar debe estar presente en el HTML inicial renderizado en el servidor, no cargado vía JavaScript del cliente después de la hidratación.
La Metadata API: generateMetadata y metadata estática
El App Router introdujo una potente Metadata API que reemplaza al antiguo componente <Head> del Pages Router. Hay dos formas de definir metadatos: exports estáticos y la función dinámica generateMetadata.
Para metadatos estáticos, exporta un objeto metadata desde cualquier archivo page.tsx o layout.tsx. Esto funciona bien para páginas con metadatos conocidos y fijos.
Para rutas dinámicas donde los metadatos dependen de datos (como el slug de una entrada de blog), usa generateMetadata. Esta función async recibe los params de la ruta y puede obtener datos para construir los metadatos dinámicamente.
Un punto crítico: generateMetadata se ejecuta en el servidor, así que siempre corre para las peticiones de Googlebot. Si en su lugar estableces los metadatos en un componente "use client" usando document.title o un gestor de head de terceros, Googlebot puede no capturarlos durante su parseo inicial de HTML. Define siempre los metadatos a través de la Metadata API del lado del servidor.
La Metadata API soporta toda la gama de meta tags:
titleydescriptionopenGraphytwitterpara compartir en redes socialesrobotspara control de indexaciónalternatespara hreflang y URLs canonicalverificationpara Google Search Consoleiconspara favicons
Para URLs canonical, usa el campo alternates.canonical. Para páginas con variantes de idioma, rellena alternates.languages con un mapa de códigos de locale a URLs.
En el Pages Router, los metadatos se gestionan importando Head desde "next/head" y colocando meta tags dentro de él en tu componente. Aunque esto sigue funcionando, tiene limitaciones: el contenido de Head solo se procesa después del renderizado de React, y los componentes Head anidados complejos pueden dar lugar a duplicación de etiquetas. Si estás empezando un proyecto nuevo, usa la Metadata API del App Router.
Generando sitemaps con sitemap.ts y sitemap.xml
El App Router de Next.js soporta la generación programática de sitemaps a través de un archivo especial sitemap.ts (o sitemap.xml/route.ts) colocado en el directorio app. El enfoque más simple es crear app/sitemap.ts que exporte una función por defecto que devuelva un array de entradas del sitemap.
Esto genera /sitemap.xml automáticamente. La función se ejecuta en tiempo de petición en desarrollo y en tiempo de build en producción (para exports estáticos) o en cada petición (para renderizado dinámico).
Para sitios grandes con más de 50.000 URLs, usa el patrón de índice de sitemap. Crea app/sitemap.ts que devuelva un índice de sitemap apuntando a múltiples sub-sitemaps, luego crea route handlers individuales para cada sub-sitemap (p. ej., app/sitemaps/[id]/route.ts). La especificación de sitemap de Google permite hasta 50.000 URLs por archivo de sitemap y hasta 500 archivos de sitemap en un índice.
El error crucial que cometen los desarrolladores es olvidar incluir rutas dinámicas en el sitemap. Si tu app tiene una ruta como /blog/[slug], la función del sitemap debe consultar tu base de datos o CMS para obtener cada slug válido y generar URLs para cada uno. Simplemente listar /blog/[slug] en el sitemap no significa nada: Google necesita las URLs reales y resueltas.
En el Pages Router, no hay generación de sitemap incorporada. Tienes dos opciones:
- Usar el paquete npm
next-sitemap(genera sitemaps en tiempo de build leyendo tu directorio pages y la salida degetStaticPaths) - Crear una ruta de API personalizada en
pages/api/sitemap.tsque genere XML dinámicamente
El paquete next-sitemap es la opción más común y soporta sitemaps del lado del servidor, generación de robotsTxt y división en múltiples sitemaps.
Rutas dinámicas: generateStaticParams y comportamiento de fallback
Las rutas dinámicas (app/blog/[slug]/page.tsx) son la fuente más común de huecos de indexación en aplicaciones Next.js. Sin la configuración adecuada, las rutas dinámicas pueden no pre-renderizarse en tiempo de build, lo que significa que Googlebot se encuentra con un 404 o un estado de carga en la primera visita.
En el App Router, exporta una función generateStaticParams desde tu página dinámica para pre-renderizar rutas específicas en tiempo de build. Cada slug devuelto por esta función se convierte en una página generada estáticamente.
¿Pero qué pasa con los slugs que no existen en generateStaticParams? Esto se controla con el export dynamicParams:
- `dynamicParams = true` (por defecto): Next.js intenta renderizar en el servidor los slugs no coincidentes bajo demanda y cachear el resultado
- `dynamicParams = false`: los slugs no coincidentes devuelven un 404
Para SEO, el valor por defecto (true) suele ser correcto porque permite que el contenido recién publicado se renderice sin un rebuild completo.
En el Pages Router, el equivalente es getStaticPaths con un parámetro fallback:
- `fallback: false`: devuelve 404 para rutas desconocidas
- `fallback: true`: renderiza una página de carga en la primera petición (Googlebot ve el estado de carga, lo cual es terrible para la indexación)
- `fallback: "blocking"`: bloquea la respuesta hasta que la página esté completamente renderizada, luego la cachea
Para SEO, usa siempre `fallback: "blocking"` en el Pages Router.
La interacción entre generateStaticParams e ISR es importante. Si estableces revalidate en una página dinámica, las páginas pre-renderizadas se regeneran en segundo plano tras el periodo de revalidación. Los nuevos slugs que no estén en generateStaticParams se renderizan en la primera petición (si dynamicParams es true) y luego se cachean con ISR. Esta combinación te da lo mejor de ambos mundos: servicio estático rápido para páginas conocidas y renderizado bajo demanda para contenido nuevo.
robots.ts, reglas noindex y control de rastreo
El App Router soporta un archivo robots.ts en app/robots.ts que genera /robots.txt programáticamente.
Consideraciones clave específicas de Next.js para robots.txt:
- Bloquea siempre las rutas
/api/(devuelven JSON, no HTML) - Bloquea
/_next/data/(datos JSON para navegación del lado del cliente que no deberían indexarse como páginas independientes) - Bloquea cualquier ruta de dashboard autenticada
- NO bloquees
/_next/static/: contiene archivos CSS y JS que Googlebot necesita para renderizar tus páginas correctamente
Para el control de noindex a nivel de página, usa el campo robots en la Metadata API. Establece robots: { index: false } en el export de metadata de cualquier página que quieras excluir de los resultados de búsqueda. Esto es apropiado para:
- Páginas de autenticación (
/login,/register) - Dashboards de usuario
- Documentación de API tras autenticación
- Cualquier página con contenido personalizado
El middleware (middleware.ts en la raíz del proyecto) también puede afectar a la indexación. Si tu middleware realiza redirecciones para autenticación o detección de idioma, asegúrate de que Googlebot no quede atrapado en bucles de redirección.
Un patrón seguro común es middleware que redirige a los usuarios no autenticados de /dashboard a /login: esto está bien porque quieres que /dashboard esté noindex de todos modos. Pero el middleware que redirige basándose en geolocalización puede atrapar a Googlebot (que rastrea desde IPs de EE.UU.) haciendo que siempre vea la versión de EE.UU., evitando que se indexen otras versiones de locale.
Probar el comportamiento de tu middleware con la herramienta Inspección de URLs de Google Search Console para ver exactamente lo que Googlebot encuentra.
Datos estructurados y Open Graph para resultados enriquecidos
Los datos estructurados (JSON-LD) son críticos para conseguir resultados enriquecidos en Google: valoraciones con estrellas, acordeones de FAQ, breadcrumbs, fechas de publicación de artículos y más. En el App Router, el enfoque más limpio es crear un Server Component JsonLd que renderice una etiqueta <script type="application/ld+json">.
Este componente debería aceptar props tipados que coincidan con los tipos de Schema.org (Article, FAQPage, Product, BreadcrumbList, Organization) y serializarlos en la etiqueta script. Como es un Server Component, el JSON-LD está presente en el HTML inicial que recibe Googlebot, sin necesidad de ejecución en el cliente.
Para etiquetas Open Graph, usa el campo openGraph en el export de tu Metadata API. Incluye:
og:titleyog:descriptionog:image(con dimensiones)og:url,og:typeyog:locale
Para Twitter Cards, usa el campo twitter. Estas etiquetas deben estar presentes en el <head> del HTML, lo cual gestiona la Metadata API automáticamente.
Un error común en aplicaciones Next.js es generar datos estructurados en el lado del cliente. Si usas un componente "use client" para obtener reseñas de productos y luego generar un bloque JSON-LD con la valoración agregada, el parseo inicial de HTML de Googlebot puede no incluir los datos estructurados. Genera siempre datos estructurados en Server Components o en `generateMetadata`. La herramienta Rich Results Test de Google te permite probar URLs específicas para verificar que tus datos estructurados son visibles para los rastreadores.
Los datos estructurados de breadcrumbs son especialmente valiosos para apps de Next.js con rutas anidadas. Si la estructura de tu app es /blog/category/post-slug, genera un schema BreadcrumbList con elementos para Inicio, Blog, la página de categoría y el post actual. Esto le da a Google información explícita de jerarquía de navegación y puede dar lugar a que se muestren breadcrumbs en los resultados de búsqueda en lugar de la URL en bruto.
Guía paso a paso
Audita tu estrategia de renderizado por ruta
Comprueba next.config.ts en busca de ajustes globales de output. Revisa cada page.tsx y clasifícalo: funciones dinámicas = SSR, export revalidate = ISR, generateStaticParams = pre-renderizado, "use client" con obtención de datos en useEffect = CSR (riesgo de indexación). Construye una hoja de cálculo con cada ruta, su estrategia y si el contenido crítico aparece en el HTML inicial.
Implementa la Metadata API en cada ruta
Para cada page.tsx y layout.tsx en tu App Router, añade un export estático de metadata o una función generateMetadata. Como mínimo, cada página necesita un title y description únicos.
- Para tu layout raíz (
app/layout.tsx), establece metadatos por defecto usando el campotitle.template(p. ej.,title: { template: "%s | TuApp", default: "TuApp" }) - Para rutas dinámicas como
/blog/[slug], implementagenerateMetadataque obtenga el contenido y devuelva metadatos específicos de la página - Añade
alternates.canonicala cada página para definir la URL canonical explícitamente - Si tu app soporta varios idiomas, rellena
alternates.languages
No establezcas metadatos en componentes "use client": usa siempre exports de metadata del lado del servidor.
Crea sitemap.ts y robots.ts
Crea app/sitemap.ts que exporte una función async por defecto que devuelva un array de entradas del sitemap. Consulta tu base de datos o CMS para todo el contenido dinámico (entradas de blog, páginas de producto, páginas de categoría) y genera una URL completa para cada uno.
Establece valores de prioridad:
- 1.0 para la página de inicio
- 0.8-0.9 para páginas de aterrizaje clave
- 0.5-0.7 para contenido regular
Incluye fechas lastModified para cada entrada.
Crea app/robots.ts que devuelva reglas que bloqueen /api/, /_next/data/, /admin/ y cualquier ruta autenticada, permitiendo todo lo demás y especificando la URL de tu sitemap.
Despliega y verifica que /sitemap.xml devuelve XML válido y /robots.txt devuelve directivas válidas visitándolas en tu navegador.
Pre-renderiza rutas dinámicas con generateStaticParams
Exporta generateStaticParams desde cada ruta dinámica para pre-renderizar rutas válidas en tiempo de build. Combínalo con dynamicParams: true y revalidate para que el contenido nuevo se renderice en el servidor en la primera petición y se cachee vía ISR. En el Pages Router, usa fallback: "blocking" en lugar de fallback: true para evitar servir estados de carga a Googlebot.
Saca el contenido crítico de los componentes de cliente
Revisa cada componente "use client" que muestra contenido que quieres indexar. Si el componente obtiene datos usando useEffect, useSWR o React Query y los renderiza en el cliente, Googlebot puede no ver ese contenido.
Patrón de refactor: mueve la obtención de datos a un Server Component padre y pasa los datos como props al componente cliente. El componente cliente puede seguir manejando la interactividad (handlers de clic, estado), pero el contenido inicial debería estar presente en el HTML renderizado en el servidor.
Prueba: desactiva JavaScript en tu navegador y carga cada página. Lo que ves sin JavaScript es aproximadamente lo que ve Googlebot en su parseo inicial de HTML.
Añade datos estructurados para resultados enriquecidos
Crea un Server Component reutilizable para datos estructurados JSON-LD. Añade los tipos de schema apropiados:
- Entradas de blog: schema
Articleconheadline,author,datePublished,dateModifiedeimage - Páginas de producto: schema
Productconname,description,priceyaggregateRating - Todas las páginas anidadas: schema
BreadcrumbListpara la jerarquía de navegación - Página de inicio: schema
Organization
Valida cada implementación de datos estructurados usando el Rich Results Test de Google introduciendo tus URLs en producción. Arregla cualquier error o advertencia antes de seguir.
Recuerda: todos los datos estructurados deben estar en Server Components para que aparezcan en el HTML inicial.
Envía URLs críticas vía IndexBolt y monitoriza
Envía tu página de inicio, páginas de aterrizaje clave y contenido de alta prioridad a través de IndexBolt. Para una app nueva, 20-50 URLs aceleran la comprensión de Google en días. Monitoriza en Inspección de URLs de Search Console: verifica que el fetch de la página muestre HTML completo, no estados de carga. Investiga cualquier ruta marcada como "Descubierta: actualmente sin indexar" en busca de problemas de renderizado.
Problemas habituales y cómo solucionarlos
Las páginas muestran contenido en blanco o spinners de carga a Googlebot
Causa: El contenido se obtiene dentro de un componente "use client" usando useEffect o una librería de obtención de datos del lado del cliente. El HTML inicial renderizado en el servidor contiene solo el estado de carga (un spinner, skeleton o div vacío). El parseo inicial de HTML de Googlebot no ve contenido, y su pasada de renderizado JavaScript secundaria puede fallar debido a autenticación de API, problemas de CORS o timeout de renderizado.
Solución: Mueve la obtención de datos a Server Components o usa generateStaticParams con generación estática. Pasa los datos como props a los componentes cliente que necesiten interactividad. Para el Pages Router, usa getStaticProps o getServerSideProps en lugar de obtención de datos del lado del cliente. Pruébalo viendo el código fuente de la página (no el DOM renderizado en DevTools): el código fuente debería contener el texto real de tu contenido.
Las rutas dinámicas devuelven 404 para páginas no incluidas en generateStaticParams
Causa: La ruta dinámica tiene establecido export const dynamicParams = false, lo que significa que cualquier slug no devuelto por generateStaticParams produce un 404. En el Pages Router, getStaticPaths con fallback: false se comporta de la misma manera. El contenido recién publicado que no estaba presente en tiempo de build es inalcanzable.
Solución: Establece dynamicParams a true (el valor por defecto) y añade un periodo revalidate para que las páginas recién generadas se cacheen vía ISR. En el Pages Router, cambia de fallback: false a fallback: "blocking". Luego asegúrate de que tu sitemap.ts consulte dinámicamente todo el contenido actual para que las páginas nuevas aparezcan en el sitemap incluso si no fueron pre-renderizadas en tiempo de build.
El sitemap no incluye las páginas generadas dinámicamente
Causa: El archivo sitemap.ts se escribió con una lista estática de URLs y no consulta la base de datos o el CMS para contenido dinámico. O bien el sitemap se generó en tiempo de build usando next-sitemap pero el build no se volvió a ejecutar después de publicar contenido nuevo. Las nuevas entradas de blog, páginas de producto o páginas de categoría faltan en el sitemap.
Solución: Reescribe sitemap.ts para que consulte dinámicamente tu fuente de contenido (base de datos, API de CMS headless o sistema de archivos) cada vez que se solicite. Para sitios basados en ISR, establece revalidate en la ruta del sitemap para que se regenere periódicamente. Si usas next-sitemap en el Pages Router, configura la generación de sitemap del lado del servidor o configura un cron job que dispare rebuilds cuando cambie el contenido.
Las redirecciones del middleware impiden que Googlebot acceda a páginas específicas de cada idioma
Causa: El middleware de detección de locale lee la cabecera Accept-Language o usa geolocalización por IP para redirigir a los visitantes a una ruta específica de locale (p. ej., /en-us/, /fr/). Googlebot rastrea principalmente desde IPs de EE.UU. con cabeceras en inglés, por lo que siempre es redirigido a la versión en inglés de EE.UU. Las páginas de otros locales nunca se rastrean ni indexan.
Solución: No redirijas a Googlebot basándote en geolocalización o Accept-Language. En su lugar, sirve el contenido del locale por defecto y confía en las etiquetas hreflang (establecidas vía alternates.languages en la Metadata API) para indicarle a Google las variantes de locale. En tu middleware, puedes comprobar el User-Agent en busca de Googlebot y saltarte las redirecciones de locale para él, o mejor, usa hreflang como señal principal de locale y solo usa redirecciones de middleware como conveniencia para usuarios reales.
Los archivos loading.tsx muestran contenido placeholder que se indexa
Causa: El App Router de Next.js usa loading.tsx para mostrar UI de carga instantánea vía React Suspense mientras se renderiza una página. Si la página usa SSR (renderizado dinámico), la petición inicial de Googlebot puede recibir el contenido de loading.tsx en lugar de la página real. Esto es especialmente probable en páginas con obtención de datos lenta.
Solución: Para páginas con contenido SEO crítico, prefiere la generación estática o ISR sobre el renderizado dinámico. Si el renderizado dinámico es necesario, asegúrate de que la obtención de datos se complete rápidamente (menos de 5 segundos) para que la respuesta en streaming entregue contenido real antes del timeout de Googlebot. Considera mover la obtención de datos pesada a componentes de cliente que mejoren la página después de que el contenido crítico renderizado en el servidor ya esté presente.
El componente Image de Next.js genera URLs que saturan el presupuesto de rastreo
Causa: El componente Image de Next.js optimiza imágenes a través de rutas /_next/image?url=...&w=...&q=.... Cada combinación de ancho y calidad genera una URL única. Si estas URLs no se bloquean en robots.txt, Googlebot puede gastar presupuesto de rastreo obteniendo endpoints de optimización de imágenes en lugar del contenido real de las páginas.
Solución: Añade Disallow: /_next/image a tu archivo robots.ts para evitar que Googlebot rastree las URLs de optimización de imágenes directamente. Las imágenes reales referenciadas en las etiquetas <img> de tus páginas seguirán siendo descubribles e indexables a través del HTML de tus páginas. Esto ahorra mucho presupuesto de rastreo en sitios con muchas imágenes.
Consejos pro
¿Has desplegado una nueva app de Next.js o añadido rutas dinámicas? Google puede tardar semanas en descubrir páginas renderizadas bajo demanda. Usa IndexBolt para empujar tus páginas recién construidas directamente a la cola de indexación de Google, algo especialmente crítico para rutas SSR e ISR que no tienen huella de URL en tiempo de build.
100 créditos gratis. Sin tarjeta de crédito. Resultados en menos de 24 horas.
Preguntas frecuentes
¿Googlebot ejecuta JavaScript en aplicaciones Next.js?+
Sí, Googlebot tiene un motor de renderizado de JavaScript basado en una versión reciente de Chromium. Sin embargo, el renderizado de JavaScript ocurre en una pasada de indexación secundaria que puede tener lugar horas o incluso días después del rastreo inicial de HTML. Esto significa que el contenido que solo aparece tras la ejecución de JavaScript se indexa con retraso, y la obtención de datos compleja en el cliente (especialmente a APIs autenticadas) puede fallar por completo en el entorno de renderizado de Google. Para una indexación fiable, asegúrate de que todo el contenido crítico esté presente en el HTML inicial renderizado en el servidor usando Server Components, getStaticProps o getServerSideProps.
¿Debería usar el App Router o el Pages Router para mejor SEO?+
El App Router tiene mejores herramientas SEO, incluyendo la Metadata API integrada, sitemap.ts, robots.ts y Server Components que renderizan el contenido en el servidor por defecto. El Pages Router funciona bien para SEO pero requiere más trabajo manual: necesitas el componente next/head para los metadatos, paquetes de terceros como next-sitemap para los sitemaps y getStaticProps/getServerSideProps para el renderizado en servidor. Para proyectos nuevos, el App Router es la elección clara. Para proyectos existentes con Pages Router, no hay necesidad urgente de migrar: céntrate en asegurarte de tener getStaticProps/getServerSideProps en su sitio y un sitemap funcional.
¿Cómo afecta el ISR a la indexación de Google?+
Incremental Static Regeneration es excelente para la indexación. Googlebot recibe HTML estático cacheado al instante (el tiempo de respuesta rápido mejora la eficiencia de rastreo), y el contenido se regenera en segundo plano para mantenerse fresco. La única consideración es el periodo de revalidación: si estableces revalidate en 3600 (una hora), los cambios de contenido pueden tardar hasta una hora en aparecer en la página cacheada. Para contenido sensible al tiempo, usa un periodo de revalidación más corto o dispara revalidación bajo demanda vía webhooks. Desde la perspectiva de Google, las páginas ISR se comportan de forma idéntica a las estáticas: son rápidas, totalmente renderizadas y fiables.
Mis páginas de Next.js aparecen como 'Descubierta: actualmente sin indexar' en Search Console. ¿Por qué?+
Este estado significa que Google encontró la URL (a través de tu sitemap o enlaces internos) pero todavía no la ha renderizado ni indexado. Para apps de Next.js, esto ocurre comúnmente cuando: (1) la página usa renderizado en cliente y el rastreo inicial de HTML de Googlebot no encontró contenido, así que la despriorizó; (2) la página tiene contenido fino que Google considera de bajo valor; (3) tu sitio es nuevo y Google todavía no ha asignado suficiente presupuesto de rastreo; o (4) la página tiene una etiqueta canonical apuntando a otro sitio. Usa la herramienta Inspección de URLs para obtener la página como Googlebot y examinar el HTML renderizado. Si está vacío o muestra un estado de carga, tienes un problema de renderizado que arreglar.
¿Cómo gestiono las URLs canonical en Next.js para páginas con parámetros de consulta?+
En la Metadata API del App Router, establece alternates: { canonical: "https://tudominio.com/page" } sin parámetros de consulta. Esto le dice a Google que la URL base es la versión canonical, independientemente de cualquier parámetro de tracking, paginación o filtro añadido a ella. Para páginas donde los parámetros de consulta crean contenido significativamente diferente (como resultados de búsqueda paginados), o bien genera URLs canonical únicas para cada página (alternates: { canonical: "https://tudominio.com/search?page=2" }) o usa una sola canonical apuntando a la página 1 y confía en los enlaces internos para que Google descubra las páginas siguientes.
¿Puedo usar IndexBolt con Next.js para acelerar la indexación de nuevas páginas?+
Por supuesto. IndexBolt es especialmente valioso para aplicaciones Next.js porque muchos sitios Next.js usan ISR o renderizado bajo demanda, lo que significa que las páginas nuevas no tienen URLs estáticas que Google descubra a través del rastreo tradicional. Tras publicar contenido nuevo, usa la API o el panel de IndexBolt para enviar las URLs directamente a la pipeline de indexación de Google. Esto es particularmente efectivo para páginas de producto de comercio electrónico generadas bajo demanda, nuevas entradas de blog en una configuración de CMS headless o páginas de aterrizaje desplegadas como parte del lanzamiento de una funcionalidad. El modo normal funciona para contenido rutinario; usa el modo Instantáneo para lanzamientos de producto o páginas sensibles al tiempo.