Una página que existe no es una página que se encuentra. Entre publicar una URL y verla ganar un clic hay tres hechos distintos —descubrimiento, rastreo e indexación— y un sitio bilingüe de Miami mete por ese tubo el doble de lo que alguien planeó.
Aquí casi todos los dueños lo descubren igual. El desarrollador confirma que la página está en línea, la analítica no muestra nada y alguien concluye que el contenido es malo. Casi nunca fue el contenido: Google no llegó a esa dirección, o llegó y no quiso conservarla.
Lo que sigue trata el presupuesto de rastreo y qué se lo come, los sitemaps como instrumento de descubrimiento y no como formalidad, la mecánica de envío del Indexing Hub y la cuenta que dice cuánto tardará un sitio de su tamaño. Por debajo corre la complicación local: un sitio bilingüe duplica cada dirección antes de escribir una sola página nueva.
Existir, ser hallada, ser rastreada, ser conservada
Son cuatro estados distintos y una URL puede quedarse semanas en cualquiera. Existir es que el servidor devuelva la página. Ser hallada es que Google conozca la dirección. Ser rastreada es que un bot la descargue. Ser conservada es que sobrevivió a la evaluación y puede aparecer en resultados. Solo el último produce tráfico.
También fallan distinto, y por eso «la página no posiciona» es un diagnóstico inútil. Una página que nadie enlaza y ningún sitemap lista puede no ser hallada jamás. Una hallada a once clics de la portada puede esperar meses. Una rastreada y juzgada casi idéntica a otra se descarta, y en un sitio bilingüe ese juicio cae más seguido de lo que el dueño supone.
| Estado | Qué significa | Causa típica del atasco |
|---|---|---|
| Existe | El servidor devuelve la página | En línea, pero enlazada desde ningún lado |
| Hallada | Google conoce la dirección | Ausente de todos los sitemaps |
| Rastreada | Un bot la descargó | Enterrada, o se acabó el presupuesto |
| Conservada | Sobrevivió a la evaluación | Juzgada delgada o duplicada de su par |
| Posicionada | Aparece por una consulta | Compite contra su propia segunda versión |
El presupuesto de rastreo y lo que se lo come en silencio
El presupuesto de rastreo es el techo práctico de cuánto de su sitio se descarga en un período. No es una cifra que le comuniquen, y en un restaurante de veinte páginas nunca importa. Empieza a pesar en cuanto un sitio genera más direcciones que páginas: casi cualquiera, y todos los bilingües.
- URL con parámetros y filtros. Una corredora de yates con filtros por eslora, año, astillero y precio produce miles de combinaciones rastreables a partir de cuarenta embarcaciones, y en cada una el bot puede gastar una visita.
- Cadenas de redirección. Cada salto es una descarga aparte. Una migración de dominio que dejó cadenas de tres pasos paga triple por cada dirección vieja que todavía se pide.
- Errores blandos. Páginas que devuelven código de éxito mientras muestran «no encontrado» o un resultado vacío parecen contenido real y se rastrean una y otra vez, porque nada le dice al bot que pare.
- Respuestas lentas. Un servidor que tarda dos segundos por página se visita menos que uno de doscientos milisegundos. La velocidad es un asunto de rastreo antes que de posicionamiento.
- Pares casi duplicados. Dos direcciones con contenido sustancialmente igual consumen una descarga cada una, y tarde o temprano una se descarta. Es la falla bilingüe en su forma más pura.
Nada de esto es exótico. Un contratista con galería de obras, una clínica con una página por tratamiento y otra por médico, o una agencia de carga con una página por ruta producen más URL de las que cualquiera calcularía a ojo. Sume un segundo idioma y la cuenta se duplica.
El sitio bilingüe duplica cada dirección desde el primer día
Este es el hecho estructural de hacer negocios aquí. Si una firma de Brickell o Doral tiene 400 páginas en inglés y hace el trabajo en español como corresponde, no tiene 400 páginas y unas cuantas más: tiene 800 direcciones, y los dos árboles compiten por el mismo presupuesto de rastreo, el mismo peso de enlazado interno y, si la configuración está mal, la misma consulta.
La duplicación en sí no es el problema: es la forma prevista de un sitio bilingüe, y en este mercado el árbol en español suele ser la mitad más valiosa y no un accesorio. El problema es cómo llega ese segundo árbol: tarde, a medias y armado por quien tuviera tiempo ese trimestre.
El patrón se repite tanto que se puede describir de antemano. El sitio en inglés sale primero porque la agencia que lo construyó trabaja en inglés. Dos años después alguien nota que la clientela lee sobre todo en español y arranca una traducción. Cubre la portada, los servicios principales y quizá una docena de artículos. Después se detiene, y queda medio árbol.
Cuatro formas en que se tuerce el árbol en español
Traducido hasta cierto punto
Existen veinte páginas de cien en español. El menú sigue listando las cien, así que enlaza direcciones que nunca se construyeron.
- Enlaces rotos o ausentes
- Presupuesto gastado en callejones
URL en español, texto en inglés
La dirección existe bajo la ruta en español pero sirve el texto en inglés cuando no se escribió la traducción. El bot ve dos direcciones con el mismo contenido.
- Señal de duplicado garantizada
- Puede ganar la copia más débil
hreflang apuntando al par equivocado
Cada página en español nombra como contraparte la portada en inglés y no a su gemela real, así que el emparejamiento no significa nada y suele ignorarse.
- Etiquetas no recíprocas
- Falta la autorreferencia
Las dos versiones tras la misma consulta
La búsqueda en español dentro de Miami devuelve páginas en inglés a menudo. Sin emparejamiento correcto sus dos versiones se alternan y ninguna se asienta.
- Posiciones inestables
- Peso de enlaces partido
La cuarta es propia de mercados bilingües y fácil de pasar por alto, porque el síntoma parece volatilidad común. Una semana aparece la página en inglés por la consulta en español, la siguiente la página en español, y la posición promedio en Search Console se ve inestable en lugar de rota.
| Síntoma | Qué ve el rastreador | Qué hacer |
|---|---|---|
| Página en español con texto en inglés | Dos direcciones, un contenido | Traducirla, o retirar la dirección |
| El menú enlaza páginas sin traducir | Callejones que gastan presupuesto | Ocultar el enlace hasta que exista |
| Todo hreflang apunta a la raíz | Un emparejamiento inservible | Emparejar cada página con su gemela |
| Las posiciones se alternan por idioma | Dos candidatas para una consulta | Corregir el par y revisar el enlazado |
| Las páginas en español no se rastrean | Sin camino de entrada ni sitemap | Dar al árbol su propio sitemap |
Un árbol bilingüe que un rastreador pueda leer
Las reglas no son complicadas; se saltan cuando el segundo idioma llega como ocurrencia tardía. Cada una se verifica sobre una muestra de diez páginas, la auditoría que conviene hacer antes de cualquier trabajo de indexación.
- Una dirección por página y por idioma. La página en inglés bajo su ruta, la española bajo el directorio de idioma, y ninguna tercera dirección sirviendo cualquiera de las dos.
- Emparejamiento recíproco, con autorreferencia. Cada versión se nombra a sí misma y a su contraparte. Si la inglesa nombra a la española, la española debe devolver la mención. Las etiquetas de una sola vía se descartan.
- Un canónico que apunte a sí mismo. Una página en español cuyo canónico nombra a la versión en inglés está pidiendo que la descarten, y es exactamente lo que ocurre.
- Los enlaces internos se quedan en su idioma. Un artículo en español enlaza servicios y artículos en español. Mezclarlos manda al rastreador de ida y vuelta y parte la señal.
- Nada de redirección automática por ubicación. Mandar por IP a la versión en español a todo visitante de Colombia significa que el bot solo verá un árbol. Ofrezca el cambio; no lo imponga.
Las páginas a medio traducir piden una decisión y no paciencia, y solo hay tres respuestas defendibles. Terminar la traducción, si la página importa. Mantener la dirección fuera del índice mientras el trabajo esté agendado. O eliminarla y apuntarla al padre del idioma, si nadie la va a escribir. Dejarla viva en inglés bajo una ruta en español es la única opción que cuesta dinero.
El sitemap hace un solo trabajo, y lo hace bien
Un sitemap no hace que Google indexe nada. Hace descubribles las direcciones, que es el primero de los cuatro estados y el que más falta en un sitio bilingüe donde el segundo árbol tiene pocos enlaces entrantes. Para ese trabajo es el instrumento más eficiente que hay.
La estructura importa más de lo que se supone. Un archivo plano con todas las URL funciona, pero no le dice nada cuando algo sale mal. Divida por idioma y luego por sección, con un índice arriba, y el reporte de envío se vuelve legible: se ve que el sitemap de servicios en español tiene un problema mientras el inglés está limpio. Esa es justo la forma que el Indexing Hub está hecho para interpretar.
Un índice para el dominio
Un único punto de entrada que nombra los dos índices de idioma y nada más. Esta es la dirección que se envía.
Un índice por idioma
Inglés y español reciben el suyo, para poder comparar los dos árboles línea por línea en vez de leerlos como una pila.
Un archivo por sección
Servicios, industrias, proyectos, artículos. Ahora la falla tiene domicilio: el archivo de servicios en español, no «el sitemap».
Un reporte accionable
Los conteos llegan por archivo, así que un árbol faltante o una sección rota se ve en el envío y no tres semanas después.
Envío por carga de archivo o por URL
Para sitios cuyo conteo de direcciones creció más allá de lo que alguien quiere pegar en un formulario.
- Dos vías de entrada. Cargue el archivo directamente, o entregue la URL de un sitemap ya publicado en el dominio.
- Lectura recursiva de tres niveles. Un índice que apunta a índices que apuntan a sitemaps se sigue hasta el fondo, que es lo que produce una estructura de idioma y sección.
- Hasta 1,000 sitemaps por trabajo. Suficiente para un portafolio bilingüe grande sin partir el envío en varias tandas.
Corren dos trabajos en simultáneo y hasta veinte esperan en cola: un diseño digno de notar antes que un límite contra el cual pelear. Una agencia con varios clientes de Miami puede enviar todo de una vez y dejar que la cola dosifique, en lugar de anotar qué envío corrió qué tarde.
Envío masivo, IndexNow y cómo se lee el resultado
El rastreador de URL trabaja con un presupuesto diario de 1,000 direcciones por cuenta y acepta hasta 10,000 en un solo lote. Las dos cifras no se contradicen: el lote es lo que usted entrega, el número diario es el ritmo al que sale. El envío corre por la API de IndexNow integrada en el panel, que notifica a GoogleBot y a BingBot.
Envío masivo con registro por dirección
Para quien necesita responder «¿esta dirección llegó a visitarse alguna vez?».
- Un registro por dirección. Visita del bot con marca de tiempo, estado y detalle del error cuando lo hay, y no una sola cifra para todo el lote.
- Contadores en vivo. Enviadas, halladas y fallidas se actualizan mientras corre el trabajo, así que una falla sistemática asoma temprano y no al final.
- Los dos bots cubiertos. IndexNow notifica a GoogleBot y a BingBot, algo que pesa más en un mercado donde parte de los compradores llega de afuera del país.
Un lote se lee por proporciones, no por totales. Fallidas cerca de cero indica direcciones sanas. Fallidas concentradas en una parte del árbol —todas las URL bajo una misma ruta, digamos— es falla estructural y no mala suerte. Y muchas halladas sin movimiento en Search Console dos semanas después significa que las páginas se alcanzaron y se juzgaron: pregunta de contenido, no técnica.
Conviene decirlo sin rodeos porque se gasta mucho dinero del lado equivocado de esa línea. Si las páginas se rastrean y se descartan, más envíos no cambian nada; la corrección está en la página. El lado de campañas y analítica del panel es donde ocurre ese trabajo, y la tarea del Hub termina en esa puerta.
Preguntas que salen en sitios bilingües
¿Los árboles en inglés y en español deben tener sitemaps separados?
Sí, en casi todos los casos. Un sitemap por idioma, dividido además por sección y referido desde un índice, le da un reporte legible en vez de una cifra suelta. La lectura recursiva sigue la estructura tres niveles hacia abajo, así que anidar no cuesta nada al enviar.
Tenemos URL en español que muestran texto en inglés. ¿Borrarlas o dejarlas?
Ninguna de las dos por tiempo indefinido. Decida por página: tradúzcala si importa, manténgala fuera del índice mientras la traducción esté agendada, o retire la dirección y apúntela al padre del idioma. Dejar el duplicado vivo es la única opción con costo garantizado.
¿Cuánto tarda en aparecer una URL enviada?
La visita del bot suele registrarse en días; aparecer en resultados es otro asunto y no tiene plazo garantizado. Tome el registro como prueba de que la dirección se alcanzó, y Search Console como prueba de que se conservó. Responden preguntas distintas.
¿Sirve reenviar la misma URL cada semana?
No, y gasta un presupuesto diario que un sitio bilingüe grande necesita en otro lado. Envíe después de un cambio real: página nueva, contenido reescrito a fondo, un emparejamiento corregido. Reenviar una dirección que no cambió no aporta.
¿Conviene mandar al visitante colombiano directo a la versión en español?
Ofrezca el cambio, no lo imponga. Una redirección por ubicación hace que el rastreador vea un solo árbol, y la investigación transfronteriza es exactamente el tráfico que un exportador, una clínica o un despacho de Miami no puede permitirse enrutar a ciegas.
Una cuenta de cierre
Tome un negocio mediano de Miami: 600 páginas en inglés y las mismas 600 bien construidas en español. Son 1,200 direcciones. Enviadas como un lote entran cómodas bajo el techo de 10,000 URL, y contra un presupuesto diario de 1,000 la corrida toma poco más de un día. Un portafolio de diez clientes así son 12,000 direcciones y cerca de doce días: eso es un plan, no una espera.
Ahora pase esas mismas 1,200 direcciones por las fallas de arriba. Si un tercio del árbol en español sirve texto en inglés, 200 de esas URL son casi duplicados que van a consumir presupuesto de rastreo y después se descartarán. Arreglar la estructura primero convierte 1,200 direcciones enviadas en 1,200 candidatas, en lugar de 1,000 candidatas y 200 recibos de trabajo perdido.
El resto es rutina. Las etiquetas de sitio filtran el portafolio a una propiedad, un sitio suelto se comparte con otro correo cuando el desarrollador de un cliente necesita entrar a un proyecto, y los procesos en segundo plano mantienen los contadores al día sin refrescar a mano. Las exportaciones llegan a 10,000 filas en CSV o JSON y a 250 en PDF, suficiente para entregar la lista de cada dirección fallida. Hay más recorridos en nuestro blog y la auditoría en sí está descrita en los servicios que operamos.
Donde la automatización se gana el lugar es en la repetición. AutoSEO, a $149 al mes por dominio, mantiene en marcha el trabajo de palabras clave y de enlaces mientras aterrizan las correcciones estructurales, y My SEO Stream recibe listas de URL por lotes, algo que le queda bien a un sitio bilingüe que produce dos listas por cada tarea. El primer movimiento medible suele llegar de cuatro a ocho semanas después de empezar, y en un sitio con el segundo idioma sin indexar esa ventana arranca cuando las páginas se vuelven hallables, no cuando se escribieron.
El cuello de botella es silencioso porque nada lo anuncia. No aparece un error ni salta una alerta; la página simplemente se queda ahí, existiendo. Para ver cuáles de sus direcciones están en cuál estado, conecte el dominio y corra un trabajo de sitemap en el Indexing Hub. En un sitio bilingüe de Miami el primer envío suele responder una pregunta que nadie había pensado en hacer: cuánto del árbol en español llegó Google a ver alguna vez.