TL;DR: Si tu sitio tiene menos de 10.000 páginas, el crawl budget casi seguro no es tu problema. Deja de optimizarlo. Pero si gestionas una tienda online con 500.000 páginas de producto, un sitio de clasificados con parámetros de URL infinitos o cualquier cosa con navegación facetada, el crawl budget está matando tu indexación en silencio. Esta guía cubre cómo diagnosticar si realmente tienes un problema de crawl budget y cómo solucionarlo. La respuesta suele ser aburrida: servidores más rápidos, URLs más limpias, mejor robots.txt.
Tu crawl budget real es el menor de estos dos valores. Si Google quiere rastrear 50.000 de tus páginas hoy (alta demanda), pero tu servidor solo aguanta 5.000 peticiones sin degradarse (límite de velocidad bajo), obtienes 5.000. Si tu servidor aguanta 100.000 peticiones pero a Google solo le interesan 2.000 de tus páginas (baja demanda), obtienes 2.000.
Esta es la parte que la mayoría de guías explica mal. Tratan el crawl budget como un depósito fijo que necesitas "ahorrar" bloqueando páginas poco importantes. En realidad, es dinámico, cambia a diario, y para la mayoría de sitios no es el cuello de botella en absoluto.
Necesito decir esto con claridad porque he visto a agencias vender optimización de crawl budget a sitios con 200 páginas.
Si tu sitio tiene menos de unas 10.000 URLs únicas, optimizar el crawl budget es casi con total seguridad una pérdida de tiempo.
Gary Illyes lo ha dicho él mismo, varias veces, incluyendo en Google I/O y en Twitter. Su planteamiento exacto: "Si tu sitio tiene unos pocos miles de URLs, la mayor parte del tiempo se rastreará de forma eficiente." Martin Splitt, Developer Advocate de Google, lo confirmó en un episodio de sus sesiones de JavaScript SEO cuando dijo que el crawl budget solo empieza a ser una preocupación real "cuando llegas a las decenas de miles de páginas o más."
Google rastrea miles de millones de páginas al día. Tu blog de WordPress con 500 páginas es un error de redondeo. Google lo rastreará entero en cuestión de días después de cualquier cambio, sin que hagas nada especial.
Donde el crawl budget realmente importa:
Si nada de lo anterior te describe, salta a la sección de FAQ al final y sigue con tu vida. Lo digo en serio. Invierte tu tiempo en calidad de contenido y enlazado interno. Sigo pensando que esto es algo que el 90% de la gente que hace "optimización de crawl budget" debería escuchar: tu problema probablemente está en otro sitio completamente distinto.
2. Comprueba tu brecha de indexación. Compara el número de páginas en tu sitemap con el número de páginas indexadas en el informe "Páginas" de GSC. Si tienes 100.000 URLs en tu sitemap pero solo 40.000 indexadas, algo está consumiendo tu crawl budget antes de que llegue a las páginas que importan.
3. Revisa los logs del servidor. Este es el diagnóstico real. GSC te da datos agregados. Los logs del servidor te dan la verdad: cada petición que hizo Googlebot, cuando, a que URL y que respuesta obtuvo. Si ves que Googlebot gasta el 60% de su rastreo en páginas de archivo paginadas o URLs con filtros, ese es tu problema, en blanco y negro.
Voy a ser honesto sobre una limitación: no estoy seguro de que el informe de estadísticas de rastreo de GSC sea siempre preciso. Hemos visto discrepancias entre lo que reporta GSC y lo que muestran los logs de servidor de nuestros clientes. A veces discrepancias significativas, del 30-40%. No se si es un problema de muestreo por parte de Google, un artefacto de caché o algo distinto. Así que siempre recomiendo verificar con logs del servidor si lo que está en juego es importante.
| Señal diagnóstica | Saludable | Advertencia | Crítico |
|---|---|---|---|
| Nueva página indexada en | 1-3 días | 1-2 semanas | 4+ semanas o nunca |
| Solicitudes de rastreo en GSC/día vs total de páginas | > 50% de páginas rastreadas por semana | 10-50% por semana | < 10% por semana |
| Tiempo de respuesta medio del servidor | < 200ms | 200-500ms | > 500ms |
| % de rastreo en URLs no indexables | < 10% | 10-30% | > 30% |
| Cadenas de redirección en el rastreo | Ninguna | < 5% de las solicitudes | > 5% tienen cadenas |
| Tasa de errores 5xx durante el rastreo | 0% | < 1% | > 1% |
Nota: Estos umbrales son directrices basadas en experiencia, extraidos de patrones en los datos de clientes de SEOJuice, no cifras oficiales publicadas por Google. Tu caso puede variar dependiendo del tamano del sitio, nicho y arquitectura del servidor.
Si la mayoría de tus señales están en la columna "Saludable", no tienes un problema de crawl budget. Ve a optimizar otra cosa.
Este es el factor de crawl budget con mayor impacto y al que menos atención se le presta. Todo el mundo quiere hablar de robots.txt y sitemaps. Nadie quiere hablar de por qué su servidor tarda 1,2 segundos en responder a una simple petición HTML.
Googlebot es educado. Monitoriza el tiempo de respuesta de tu servidor en tiempo real. Si tu servidor empieza a ralentizarse, Googlebot reduce su velocidad de rastreo para no sobrecargarlo. Este es el límite de velocidad de rastreo en acción. Un servidor que responde en 100ms será rastreado de forma dramáticamente más intensa que uno que responde en 800ms.
"Si el sitio es realmente rápido, Googlebot podrá usar más conexiones y rastrear el sitio más rápido. Si el sitio se ralentiza o responde con errores de servidor, reducirá la velocidad y rastreará menos."
— Gary Illyes, Senior Search Analyst, Google (Google Developers Blog)
Esa es una cita directa del post oficial sobre crawl budget. "Realmente rápido" para Google significa un time to first byte (TTFB) por debajo de 200ms. No tiempo de carga de la página — TTFB. El tiempo que tarda tu servidor en empezar a enviar la respuesta HTML.
Mejoras rápidas para el tiempo de respuesta del servidor:
En el sitio de un cliente de SEOJuice (una tienda de muebles online, con aproximadamente 80.000 páginas de producto), vimos como su tasa de rastreo en GSC bajaba de 15.000 solicitudes/día a 3.000 en dos semanas. Sin cambios en contenido ni estructura. La causa: su proveedor de hosting los migró a un nuevo cluster de servidores y el TTFB pasó de 180ms a 900ms. Una vez arreglaron el hosting, la tasa de rastreo se recuperó en cuatro días. Sin cambios en robots.txt. Sin actualizaciones de sitemap. Solo servidores más rápidos.
Los parámetros de URL son la fuente más común de desperdicio de rastreo. Y el problema es insidioso porque a menudo no sabes que está ocurriendo.
Piensa en una tienda online con filtros. Un usuario navega por zapatos y selecciona: talla 42, color negro, marca Nike, ordenado por precio, página 2. Eso genera una URL como:
/zapatos?talla=42&color=negro&marca=nike&sort=price&page=2Ahora multiplica eso por cada combinación posible. 8 tallas, 12 colores, 40 marcas, 4 opciones de ordenación, 50 páginas de resultados. Eso son 8 x 12 x 40 x 4 x 50 = 768.000 URLs. De una sola página de categoría. Y el contenido en la mayoría de esas páginas se solapa significativamente: zapatos Nike negros talla 42 ordenados por precio son básicamente los mismos productos que zapatos Nike negros talla 42 ordenados por novedades.
Googlebot no lo sabe. Ve 768.000 URLs únicas y empieza a rastrearlas. Tus páginas de producto reales — las que deberían posicionar — esperan en una cola detrás de cientos de miles de variaciones filtradas que nadie va a buscar nunca.
Esto es lo que la gente quiere decir cuando habla de "navegación facetada creando trampas de rastreo." No es que Google se quede atrapado en un bucle infinito (aunque puede pasar con ciertas configuraciónes de paginación). Es que Google asigna su crawl budget limitado a URLs que no aportan valor único.
Quiero ser preciso sobre algo: la herramienta de parámetros de URL en Google Search Console fue deprecada y eliminada en 2022. Google solia permitirte indicar qué parámetros ignorar. Esa opción ya no existe. Ahora tienes tres herramientas para manejar esto:
Cada una tiene sus compromisos. Cubrire robots.txt y canonicals en sus propias secciones más abajo.
Tu robots.txt es el primer archivo que Googlebot comprueba antes de rastrear tu sitio. También es el archivo más malinterpretado del SEO. La gente o lo deja vacio (perdiendo una oportunidad) o se pasa de la raya (bloqueando cosas que no debería).
El principio clave: bloquea lo que desperdicia crawl budget, no lo que es "poco importante." Hay una diferencia. Una página "poco importante" podría necesitar estar indexada. Una página que desperdicia crawl budget es una que no aporta valor único a la búsqueda y existe en miles de variaciones por parámetros.
# Bloquear parámetros de navegación facetada
User-agent: *
Disallow: /*?sort=
Disallow: /*?color=
Disallow: /*?size=
Disallow: /*&sort=
Disallow: /*&color=
Disallow: /*&size=
# Bloquear resultados de búsqueda interna
Disallow: /search?
Disallow: /search/
# Bloquear URLs basadas en sesion
Disallow: /*?sessionid=
Disallow: /*?ref=
# Bloquear páginas de admin, carrito y cuenta
Disallow: /admin/
Disallow: /cart/
Disallow: /my-account/
Disallow: /checkout/
# Bloquear versiones de impresión y PDF
Disallow: /*?print=
Disallow: /*?format=pdf
# NO bloquear CSS, JS ni imágenes
# Googlebot los necesita para renderizar tus páginas
Allow: /*.css
Allow: /*.js
Allow: /*.jpg
Allow: /*.png
Allow: /*.webp
Sitemap: https://example.com/sitemap.xmlErrores criticos que he visto:
/products/ porque quiere bloquear /products?filter= y accidentalmente desindexe todo su catálogo.Ese último punto merece repetirse porque confunde incluso a SEOs con experiencia. Robots.txt bloquea el rastreo. No bloquea la indexación. Si quieres impedir la indexación, usa <meta name="robots" content="noindex"> o una cabecera HTTP X-Robots-Tag. Pero recuerda: para que Google vea una etiqueta noindex, primero tiene que rastrear la página. Así que si bloqueas el rastreo con robots.txt Y además añades noindex, Google nunca verá la etiqueta noindex. Esto crea una paradoja que ha confundido a la gente durante años.
Un sitemap no garantiza la indexación. Ni siquiera garantiza el rastreo. Lo que hace es darle a Google una pista sobre que URLs existen, cuando se modificaron por última vez y (discutiblemente) lo importantes que son unas respecto a otras.
Los errores que la gente comete con los sitemaps casi siempre tienen que ver con incluir demasiado, no demasiado poco.
Qué incluir en tu sitemap:
<lastmod> precisas: no la fecha actual, no la misma fecha en todas las páginas, sino la fecha real de la última modificaciónQué excluir de tu sitemap:
He visto sitemaps con 500.000 URLs donde solo 80.000 eran realmente indexables. Las otras 420.000 eran redirecciones, páginas con noindex, variaciones de parámetros y URLs rotas. Ese sitemap no está ayudando a Google, lo esta mandando a una búsqueda del tesoro donde el 84% del mapa esta equivocado.
Martin Splitt ha llamado a <lastmod> "una de las etiquetas más abusadas en los sitemaps" porque muchas plataformas CMS la establecen con la fecha actual en todas las páginas. Cuando todas las páginas dicen "acabo de ser modificada," Google aprende a ignorar la señal por completo. Si tu CMS no registra las fechas de modificación reales, arregla eso antes de preocuparte por cualquier otra cosa relaciónada con sitemaps.
Le dedico una sección propia a la navegación facetada porque es la intersección entre crawl budget, contenido duplicado y arquitectura técnica, y hacerlo mal puede hundir el SEO de un sitio en silencio durante meses.
El problema: la navegación facetada (filtros en ecommerce, clasificados, bolsas de empleo) genera combinaciones de URLs de forma exponencial. Ya vimos las matemáticas arriba. Pero la solución no es tan simple como "bloquear todo con robots.txt" porque algunas páginas facetadas tienen valor de búsqueda genuino.
Piénsalo: "zapatillas running Nike talla 42" es una búsqueda real que una persona real escribe en Google. Una página facetada que coincida con esa consulta podría posicionar para ella. Bloquear todas las URLs facetadas significa que pierdes esa oportunidad.
El enfoque que recomiendo (y lo que implementamos para los clientes de SEOJuice que tienen este problema):
| Tipo de faceta | Ejemplo | Valor de búsqueda | Enfoque recomendado |
|---|---|---|---|
| Categoría + Marca | /zapatos/nike/ | Alto — la gente busca marca+categoría | Indexar, incluir en sitemap, usar URL limpia |
| Categoría + 1 filtro | /zapatos?color=negro | Medio — depende del volumen de búsqueda | Comprueba el volumen de búsqueda. Indexar si >100 búsquedas mensuales, canonical al padre en caso contrario |
| Categoría + 2+ filtros | /zapatos?color=negro&talla=42 | Bajo — demasiado específico para la mayoría de búsquedas | Canonical al filtro único más relevante o a la categoría padre |
| Variaciones de ordenación | /zapatos?sort=price-asc | Ninguno — nadie busca "zapatos ordenados por precio" | Bloquear con robots.txt o noindex |
| Páginas de paginación profundas | /zapatos?page=47 | Ninguno después de la página 2-3 | Noindex después de la página 3-5, mantener rastreable |
| Parámetros de sesion/tracking | /zapatos?utm_source=email | Ninguno | Bloquear con robots.txt, eliminar a nivel de servidor |
La implementación de la etiqueta canonical para páginas con múltiples filtros se ve así:
<!-- En /zapatos?color=negro&talla=42&sort=price -->
<link rel="canonical" href="https://example.com/zapatos?color=negro" />
<!-- En /zapatos?sort=price -->
<link rel="canonical" href="https://example.com/zapatos" />
<!-- En /zapatos (la página de categoría limpia) -->
<link rel="canonical" href="https://example.com/zapatos" />Un error que he cometido y que no he resuelto del todo: que hacer con páginas facetadas que han acumulado backlinks. Un cliente tenia miles de enlaces externos apuntando a URLs filtradas. Canonicalizarlas hacia la página padre debería transmitir la autoridad hacia arriba — suena bien en teoria.
En la práctica, vimos una caida del 15% en los rankings de la página padre después de implementar los canonicals. Sigo sin saber por que. Mi mejor hipotesis es que la consolidación repentina de miles de señales confundio la evaluación de Google, pero eso es especulación. Revertimos los canonicals en las páginas filtradas con más enlaces y las dejamos indexables. Es un compromiso con el que no estoy del todo cómodo.
Versión corta: rel="next" y rel="prev" están deprecados. Google confirmó en 2019 que llevaban años sin usar esa señal. ¿Entonces, qué haces en su lugar?
Tres opciones, ordenadas por mi preferencia:
Opción 1: Carga progresiva o scroll infinito con pushState. Este es el enfoque más limpio para sitios nuevos. Los usuarios ven una sola URL. Google rastrea el contenido completo. Sin URLs de paginación que desperdicien crawl budget. Pero requiere JavaScript, lo que introduce sus propios costes de crawl budget (más sobre esto abajo).
Opción 2: Paginación tradicional con noindex en página 2+. Mantén las URLs paginadas rastreables (para que Google pueda descubrir los productos/artículos enlazados desde ellas) pero aplica noindex para que Google no intente indexar páginas de plantilla idénticas. El canonical en cada página paginada debe ser auto-referenciado: no pongas canonical de todas las páginas hacia la página 1, porque el contenido es diferente.
Opción 3: Página "ver todo." Si tu contenido paginado tiene menos de ~200 elementos en total, considera una sola página que muestre todo y que canonicalice la serie paginada. Google históricamente ha preferido las páginas "ver todo." La desventaja: tiempo de carga. Si tu página "ver todo" tarda 8 segundos en cargar, perjudica más de lo que ayuda.
<!-- Página 2 del archivo del blog -->
<meta name="robots" content="noindex, follow">
<link rel="canonical" href="https://example.com/blog/page/2" />
<!-- Importante: usa "noindex, follow" — no "noindex, nofollow"
Quieres que Google siga los enlaces en las páginas paginadas
para descubrir las páginas de contenido real -->Fíjate en la directiva follow. Esto es crucial. No quieres la página paginada en el índice, pero absolutamente quieres que Google siga los enlaces para encontrar tu contenido real. Usar nofollow aquí dejaria huérfano cada artículo o producto enlazado únicamente desde la página 2+ de tu archivo.
Esta sección es relevante para cualquiera que ejecute un sitio con mucho JavaScript (React, Vue, Angular, Next.js sin SSR adecuado). Si tu sitio es HTML renderizado en servidor de forma tradicional, salta adelante.
Google rastrea en dos oleadas. Primera oleada: descarga y procesa el HTML crudo. Segunda oleada: renderiza la página con un navegador Chromium headless para ejecutar el JavaScript y ver el contenido final. La segunda oleada ocurre después, a veces horas más tarde, a veces días.
Martin Splitt lo ha explicado ampliamente en sus sesiones de JavaScript SEO. La idea clave: renderizar es costoso para Google. Requiere más recursos que una simple petición HTML. Google tiene que levantar una instancia de Chromium, ejecutar tu JavaScript, esperar a que se resuelvan las llamadas API y luego procesar el DOM renderizado. Esto significa que las páginas que dependen de JavaScript se rastrean de forma menos eficiente que las páginas renderizadas en servidor.
El impacto en el crawl budget:
La solución: server-side rendering (SSR) o generación estática (SSG). Next.js, Nuxt, SvelteKit — todos lo soportan. Si no puedes hacer SSR completo, usa renderizado dinámico: sirve HTML pre-renderizado a Googlebot y la experiencia JS completa a los usuarios. Google técnicamente lo desaconseja, pero a principios de 2026 funciona en la práctica. Hemos cubierto los desafíos específicos de las SPA en nuestra guía de mejores prácticas SEO para SPA.
Que buscar en tus logs:
Herramientas: Screaming Frog Log Analyzer es la herramienta dedicada más popular. También puedes analizar logs con herramientas de línea de comandos (filtrar por el user agent de Googlebot con grep, procesarlo con awk). Para monitorización continua, la funcionalidad de analítica de rastreo de SEOJuice procesa los logs del servidor automáticamente y alerta sobre problemas de crawl budget.
Un ejemplo real de nuestros datos: un cliente tenia un sitio WordPress con ~25.000 posts publicados. Buen contenido, tráfico decente. Pero sus logs de servidor mostraban que Googlebot gastaba el 40% de su crawl budget en endpoints /wp-json/ y URLs /feed/. Esas no son páginas que nadie busca. Añadiendo dos líneas al robots.txt se liberó ese 40% para páginas de contenido real. En tres semanas, su tasa de rastreo en páginas de artículos aumentó un 60%, y vieron 12 páginas nuevas indexadas que llevaban meses en el purgatorio de "Descubierta — actualmente no indexada."
# Ahorro de crawl budget específico para WordPress
User-agent: *
Disallow: /wp-json/
Disallow: /feed/
Disallow: /comments/feed/
Disallow: /author/*/feed/
Disallow: /category/*/feed/
Disallow: /tag/*/feed/
Disallow: /?replytocom=
Disallow: /trackback/Los enlaces internos son la señal más fuerte que controlas para indicar a Google qué páginas importan. No las meta etiquetas. No los valores de prioridad del sitemap (que Google ignora de todos modos). Los enlaces internos.
Cada enlace es un voto. Una página enlazada desde tu homepage, tu navegación y otras 50 páginas se rastreará con más frecuencia que una página enlazada desde una sola página de archivo a tres clics de profundidad. Esto es distribución básica de PageRank, y es cómo Googlebot decide dónde gastar su crawl budget.
La implicación práctica: si hay páginas que no se indexan y están a más de 3 clics de tu homepage, añadir enlaces internos desde páginas bien conectadas aumenta su frecuencia de rastreo. Lo hemos visto de forma consistente: páginas que pasan de 0-1 enlaces internos a más de 5 reciben su primera visita de Googlebot en menos de 48 horas, incluso en sitios grandes donde las páginas nuevas normalmente esperan semanas.
Por eso construimos el enlazado interno automático en SEOJuice. Gestionar manualmente los enlaces internos en más de 10.000 páginas es imposible. Pero el beneficio en prioridad de rastreo lo convierte en una de las actividades de SEO técnico con mayor ROI.
Una arquitectura plana (cada página accesible en 3 clics o menos) es mejor para el crawl budget que jerarquías profundas. Pero "plana" no significa "enlazar todo con todo." Significa enlazado estratégico — clusters temáticos, páginas hub, enlaces contextuales — que crea rutas de rastreo claras hacia tus páginas más importantes.
Quiero ser específico sobre lo que realmente hacemos, en lugar de usar lenguaje de marketing vago.
SEOJuice rastrea el comportamiento de rastreo a través de tres fuentes: estadísticas de rastreo de GSC (a través de la API de Search Console), nuestros propios datos de rastreo (rastreamos los sitios de los clientes para construir el grafo de enlaces internos), y opcionalmente, integración de logs del servidor.
Lo que mostramos:
Todavía no hacemos análisis completo de archivos de log dentro del producto (parsear formatos de log de servidor arbitrarios a escala es un desafío de ingeniería que no he resuelto a mi satisfacción). Pero los datos de GSC más nuestro propio rastreador proporcionan a la mayoría de sitios información suficiente para identificar y corregir problemas de crawl budget sin tocar un archivo de log.
Si has leído hasta aquí y has determinado que realmente tienes un problema de crawl budget, esto es lo que debes arreglar, por orden de impacto:
Los pasos 1-3 resuelven el problema en la mayoría de sitios que realmente necesitan optimización de crawl budget. Los pasos 4-9 son para el resto: sitios con arquitecturas complejas donde lo básico no es suficiente.
No. El crawl budget afecta a si tus páginas se rastrean e indexan, no a cómo posicionan una vez indexadas. Pero una página que nunca se rastrea nunca se indexa, y una página que nunca se indexa no puede posicionar. Así que el crawl budget es un prerrequisito, no un factor de ranking. Optimizarlo no mejorará los rankings de páginas ya indexadas — ayuda a las páginas que directamente no se están indexando.
Casi nunca. Los ajustes de velocidad de rastreo en GSC te permiten reducir la velocidad de rastreo de Googlebot, no aumentarla. La única razón para usarlo es si Googlebot está literalmente sobrecargando tu servidor. Si tu servidor aguanta el tráfico, déjalo como está. He visto a gente reducirlo pensando que "concentraría" a Google en las páginas importantes. No funciona así: Google simplemente rastrea menos de todo.
Páginas populares que se actualizan frecuentemente: varias veces al día. Páginas estáticas sin cambios durante meses: cada pocas semanas. La media es aproximadamente cada 1-2 semanas por página, pero varía enormemente. Los sitios de noticias se rastrean en cuestión de minutos. Una página "Acerca de" que rara vez se actualiza puede pasar un mes entre visitas. La etiqueta <lastmod> puede indicar que una página cambió, pero solo si la usas con precisión — Google la ignora si siempre está puesta con la fecha de hoy.
Puedes aumentar tu límite de velocidad de rastreo (servidor más rápido) y reducir el desperdicio de rastreo (para que más presupuesto vaya a las páginas importantes). Pero no puedes indicarle directamente a Google que te rastree más. La demanda de rastreo es una decisión de Google basada en el valor percibido del contenido. El mejor enfoque indirecto: publica frecuentemente, construye backlinks, haz contenido genuinamente útil. Los sitios de alto valor se rastrean de forma más agresiva, automáticamente.
Sí. Google sigue rastreando la página para ver la etiqueta noindex. 100.000 páginas con noindex significan 100.000 peticiones al crawl budget (aunque con menor frecuencia que las páginas indexadas). Si esas páginas realmente nunca necesitan indexarse, robots.txt es más eficiente en términos de rastreo — pero el bloqueo con robots.txt impide que Google vea cualquier cosa en la página, incluidos los enlaces. Usa noindex+follow cuando quieras que se descubran los enlaces pero no se indexe la página. Usa robots.txt cuando no quieras que la página se rastree en absoluto.
Este artículo forma parte de nuestra serie de SEO técnico. Si estas trabajando en problemas de crawl budget, estas guías relaciónadas te ayudarán:
Si gestionas un sitio grande y quieres monitorización automatizada del crawl budget, SEOJuice rastrea el desperdicio de rastreo, la velocidad de indexación y el tiempo de respuesta del servidor en todas tus páginas. No sustituirá el análisis de logs para arquitecturas complejas, pero detecta la mayoría de problemas de crawl budget que importan — de forma continua, no solo cuando alguien se acuerda de hacer una auditoría. Pruébalo gratis y descubre adónde se está yendo tu crawl budget en cuestión de minutos.
no credit card required
No related articles found.