Parámetros de URL de Google Search: qué sigue funcionando en 2026

En algún momento alrededor de septiembre de 2025, varias herramientas SEO y scripts personalizados dejaron de funcionar sin hacer ruido. ¿La causa? Google dejó de respetar de forma fiable el parámetro num=100, que durante años había permitido a usuarios avanzados obtener 100 resultados por página. No hubo ningún aviso formal de depreciación: solo un portavoz diciendo a Search Engine Land que el parámetro “no contaba con soporte formal”. Más o menos al mismo tiempo, Google sumó más modos udm junto con los antiguos verticales tbm, anunció que los dominios por país irían redirigiendo poco a poco a google.com y comunicó que AI Overviews ya alcanzaban más de 2.500 millones de usuarios mensuales.

Si has estado creando URLs de búsqueda, haciendo seguimiento de rankings o automatizando investigación con los parámetros de Google, hay bastantes posibilidades de que alguno de tus flujos esté degradado ahora mismo sin que lo notes. En Thunderbit revisamos la documentación actual de Google, anuncios recientes de cambios, referencias obtenidas por ingeniería inversa y comprobaciones directas para separar los controles estables de los contextuales. El resultado es una referencia con fecha, pensada para probar antes de desplegar, sobre los parámetros de URL de Google Search que importan en 2026, incluyendo los mapeos tbm/udm, la fórmula de codificación uule para geotargeting a nivel de ciudad y los conflictos entre parámetros que pueden ahorrarte horas de depuración.

¿Qué son los parámetros de URL de Google Search?

Los parámetros de URL de Google Search son los pares clave=valor que aparecen después del ? en una URL de búsqueda de Google. Controlan desde qué estás buscando hasta qué resultados ves, pasando por si aparecen imágenes, noticias o los clásicos enlaces azules.

Una URL típica de Google Search se divide así:

https://www.google.com/search?q=best+crm+software&hl=en&gl=us&tbs=qdr:m

• URL base: https://www.google.com/search
• ? inicia la cadena de consulta
• q=best+crm+software es la consulta de búsqueda (los espacios se codifican como +)
• & separa cada parámetro
• hl=en configura el idioma de la interfaz en inglés
• gl=us indica a Google que muestre resultados como si estuvieras en EE. UU.
• tbs=qdr:m filtra para resultados del último mes

Conviene distinguir algo importante: los operadores de búsqueda como site:, filetype: e intitle: van dentro del valor de q=. Forman parte de tu consulta. En cambio, los parámetros de URL como gl, hl y tbs son claves separadas en la URL que controlan cómo Google procesa y muestra los resultados. Ambos importan y funcionan juntos, pero no son lo mismo.

Google nunca ha publicado una especificación única y versionada de estos parámetros. Algunos vienen del formulario de búsqueda avanzada, otros de la API de Custom Search, y otros se han reconstruido observando las propias URLs de Google. Eso significa que este artículo se basa en pruebas en vivo y comportamiento documentado, no en un contrato oficial de API.

Por qué los parámetros de URL de Google Search importan en 2026

Los parámetros de URL no son solo asunto de desarrolladores. Cualquiera que trabaje en SEO, marketing, ventas, operaciones o producto y necesite entender qué muestra Google para una consulta concreta, en un mercado concreto y en un momento concreto, tiene aquí una caja de herramientas.

Resumen rápido de quién se beneficia y cómo:

Caso de uso	Quién se beneficia	Parámetros clave
Seguimiento de rankings SEO entre países	Equipos de SEO y marketing	gl, hl, uule, pws
Monitorización de competidores por fecha	Equipos de estrategia y operaciones	tbs, q con site:
Seguimiento de anuncios en mercados concretos	Equipos de paid media	gl, hl, udm
Auditorías SEO locales (nivel ciudad)	Propietarios de negocios locales	uule, gl
Investigación de contenidos / seguimiento de tendencias	Equipos de contenidos	tbs (filtros de fecha), lr
Alimentar datos de búsqueda en apps de IA/LLM	Equipos de producto y datos	Varios parámetros + extracción estructurada

Tres grandes cambios hacen que 2026 sea muy distinto:

1. num=100 ya no es fiable. El viejo truco de resultados por página dejó de funcionar con regularidad en septiembre de 2025. Google no lo desactivó formalmente; un portavoz dijo que nunca había tenido soporte oficial.
2. Las redirecciones de ccTLD son una migración, no un cambio ya completado. Google anunció en abril de 2025 que los dominios con código de país (google.co.uk, google.de, etc.) irían redirigiendo gradualmente a google.com. Google no ha publicado un aviso de finalización, así que no asumas todavía que todos los locales se comportan igual.
3. AI Overviews cambió la SERP. Google informa que AI Overviews alcanza más de 2.500 millones de usuarios mensuales y más de 200 países y territorios. Los modos udm obtenidos por ingeniería inversa pueden cambiar la superficie de resultados en algunos contextos, pero no son un interruptor garantizado de AI Overview.

Si no has actualizado tus flujos para estos cambios, lo más probable es que estés obteniendo resultados degradados o engañosos sin darte cuenta.

Chuleta de parámetros de URL de Google Search (2026)

Antes de entrar en detalle, la tabla de referencia rápida de abajo es la lista más actualizada que he podido reunir. Guárdala en favoritos.

Parámetro	Qué hace	Valor de ejemplo	Estado
q	Consulta de búsqueda (admite operadores dentro)	q=best+crm+software	✅ Activo
hl	Idioma de la interfaz	hl=en, hl=ja	✅ Activo
gl	Contexto de país/mercado	gl=us, gl=jp	✅ Activo
lr	Restringe resultados a un idioma del contenido	lr=lang_en	✅ Activo
cr	Restringe resultados a un país de alojamiento	cr=countryUS	✅ Activo
start	Desplazamiento de paginación	start=10 (página 2)	✅ Activo
num	Resultados por página (antes)	num=100	⚠️ Sin soporte formal; poco fiable desde sept. 2025
udm	Modo de contenido contextual	udm=14 (web clásica)	⚠️ Reconstruido por ingeniería inversa; varía según el contexto
tbm	Vertical de búsqueda	tbm=isch (imágenes)	⚠️ Aún observado; probar junto con udm
tbs	Filtros de tiempo, orden y verbatim	tbs=qdr:w	✅ Activo
safe	Control de SafeSearch	safe=active	✅ Activo
filter	Filtrado de resultados duplicados	filter=0	✅ Activo (observado)
nfpr	Desactivar autocorrección	nfpr=1	✅ Activo (observado)
pws	Desactivar personalización	pws=0	✅ Activo
uule	Geotargeting a nivel ciudad/DMA	uule=w+CAIQICI...	✅ Activo (reconstruido por ingeniería inversa)
as_q, as_epq, as_eq, etc.	Campos del formulario de búsqueda avanzada	Varios	✅ Activo
as_sitesearch	Restringe a un dominio (Búsqueda avanzada)	as_sitesearch=example.com	✅ Activo
as_filetype	Restringe a un tipo de archivo (Búsqueda avanzada)	as_filetype=pdf	✅ Activo
ie, oe	Codificación de entrada/salida	ie=UTF-8	✅ Activo (rara vez necesario)
kgmid, si, ibp	Vista de entidad / función de Knowledge Graph	Varios	⚠️ Contextual (no para uso general)
ei, ved, sxsrf, sclient	Sesión/seguimiento/telemetría	Varios	🔒 Internos (ignorar)
gbv	Vista HTML básica (antes)	gbv=1	❌ Poco fiable en 2026

Elimina ei, ved, sxsrf y sclient de cualquier URL que guardes o compartas. Son estado de sesión y telemetría que Google añade automáticamente: no sirven para construir URLs de búsqueda.

Parámetros clave de Google Search que siguen funcionando

Los he probado en vivo a mediados de 2026. Son los que usarás con más frecuencia.

q — Tu consulta de búsqueda

El parámetro q contiene los términos de búsqueda. Los espacios se codifican como + o %20. Aquí es donde viven los operadores de búsqueda documentados por Google: van dentro del valor de q, no como parámetros separados.

Algunos ejemplos:

• Frase exacta: q=%22google+search+url+parameters%22
• Restringido a un sitio: q=site%3Aexample.com+pricing
• Tipo de archivo: q=filetype%3Apdf+annual+report+2026
• Combinado: q=site%3Acompetitor.com+intitle%3Apricing+after%3A2026%2F01%2F01

Codifica siempre toda la consulta en URL. Las comillas, los dos puntos y las barras inclinadas necesitan codificación correcta para no romper la URL.

hl — Idioma de la interfaz

hl controla el idioma de la interfaz de Google (botones, etiquetas, encabezados de “People also ask”) e influye en qué resultados prioriza Google. Usa códigos ISO 639-1 como en, fr, de, ja, o etiquetas BCP 47 como en-gb o pt-br.

hl no obliga a que todos los documentos de resultados estén en ese idioma. Es una señal potente, pero Google puede seguir mostrando resultados en otros idiomas si son muy relevantes. Para restringir el idioma del contenido, usa lr.

gl — País / geolocalización

gl simula desde qué país estás buscando, usando códigos ISO 3166-1 alpha-2 (us, gb, jp, de). Con las ccTLD redirigiendo poco a poco a google.com, gl pasa a ser la forma principal de obtener resultados específicos por país.

La misma consulta con distintos valores de gl puede devolver resultados, fragmentos destacados y packs locales completamente diferentes. Por ejemplo, q=best+bank&gl=us y q=best+bank&gl=jp te mostrarán bancos muy distintos.

Consejo: combina siempre gl con hl para obtener resultados localizados con precisión. Usar gl=jp con hl=en te da resultados del mercado japonés en una interfaz en inglés, algo útil para auditorías SEO internacionales.

lr y cr — Restricción por idioma y por país

Estas dos se confunden constantemente. La diferencia importa:

• lr=lang_en restringe los resultados a páginas escritas en inglés (idioma del contenido)
• cr=countryUS restringe los resultados a páginas alojadas en Estados Unidos (ubicación del servidor / asociación con el país)
• gl=us simula que buscas desde Estados Unidos (afecta ranking, resultados locales y anuncios)

Tanto lr como cr están disponibles en el formulario de búsqueda avanzada. Ten cuidado al combinarlos: lr=lang_en + cr=countryJP significa “solo páginas en inglés alojadas en Japón”, un conjunto muy reducido. Más sobre esto en la sección de conflictos.

start — Paginación

start=10 pide resultados a partir de la posición 11 (página 2), start=20 la página 3, y así sucesivamente. Como num=100 ya no es fiable, incrementar start de 10 en 10 es la opción más segura, aunque Google todavía puede reescribir o limitar la paginación.

El viejo truco num=100&start=0 para sacar una página completa de 100 resultados ya no funciona. Si tus scripts aún incluyen num, elimínalo: se ignora en silencio.

pws — Desactivar personalización

pws=0 le pide a Google que desactive la personalización basada en la cuenta. Esto es esencial para el seguimiento de rankings SEO, donde quieres resultados que no estén sesgados por tu historial de búsquedas, clics anteriores o preferencias de cuenta.

Ojo: pws=0 reduce la personalización, pero no elimina todos los factores contextuales. Google afirma que los resultados pueden seguir variando por hora, ubicación, idioma y dispositivo. No existe una SERP de Google realmente “neutral”.

safe y filter — SafeSearch y filtrado de duplicados

• safe=active activa SafeSearch; safe=off lo desactiva. Ten en cuenta que la configuración de la cuenta, las políticas de administrador, la red o las leyes regionales pueden anular este parámetro.
• filter=0 desactiva el filtrado de resultados duplicados de Google. Es útil cuando quieres ver todos los resultados que tiene Google, incluidos los casi duplicados que normalmente agruparía.

nfpr — Desactivar autocorrección

nfpr=1 evita que Google reescriba tu consulta de forma forzada cuando cree que has escrito algo mal. Es útil para seguir términos de marca con ortografía poco habitual, jerga técnica o consultas intencionadamente mal escritas que usan competidores.

Ten en cuenta que nfpr=1 solo suprime la reescritura forzada. Para un control más amplio — desactivar expansión de sinónimos, cambios ortográficos y otras modificaciones automáticas — usa tbs=li:1 (modo verbatim), que explico más abajo en la sección tbs.

La migración de tbm a udm: qué cambió y qué usar ahora

Este es uno de los mayores cambios de parámetros de los últimos años, y también uno de los más fáciles de exagerar.

tbm ha sido durante más de una década una forma habitual de cambiar entre los verticales de búsqueda de Google — imágenes, noticias, vídeo, compras. Google también ha introducido un sistema numérico udm con modos superpuestos y adicionales. Como Google no ha publicado un registro estable para consumidores, trátalo como un mapeo contextual y no como un reemplazo limpio y completo.

Tabla completa de mapeo de tbm a udm

Los mapeos de abajo combinan comportamiento observado en la interfaz y comprobaciones en vivo fechadas el 12 de agosto de 2026. Varios valores se eliminaron o reescribieron en solicitudes anónimas, así que cada fila debe probarse en la cuenta, región y cliente donde vaya a usarse:

Parámetro antiguo	Valor antiguo	Parámetro nuevo	Valor nuevo	Estado
tbm=lcl	Lugares/Local	udm=1	Lugares/Local	⚠️ Contextual
tbm=isch	Imágenes	udm=2	Imágenes	⚠️ Contextual
tbm=vid	Vídeos	udm=7	Vídeos	⚠️ Contextual
tbm=nws	Noticias	udm=12	Noticias	⚠️ Contextual
—	—	udm=14	Web clásica (sin AI Overview)	🆕 Nuevo, sin equivalente tbm
—	—	udm=18	Foros	🆕 Nuevo, sin equivalente tbm
tbm=shop	Compras	udm=28	Compras	⚠️ Contextual
tbm=bks	Libros	udm=36	Libros	⚠️ Contextual
—	—	udm=39	Vídeos cortos	🆕 Nuevo, sin equivalente tbm
—	—	udm=50	Modo AI Overview	🆕 Nuevo, sin equivalente tbm

Google no ha publicado un registro estable de udm; esa es una advertencia clave. Estos valores se han reconstruido por ingeniería inversa observando el comportamiento de la interfaz de Google. La aceptación de la URL varía según la cuenta, la región, el cliente, las cookies y el grupo experimental. En mis pruebas, algunos valores de udm se eliminaban en solicitudes HTTP anónimas pero funcionaban bien en sesiones de navegador interactivo. No asumas que cada valor funciona universalmente.

Qué hace udm=14 (y por qué encanta a los SEO)

udm=14 se ha convertido en algo así como un favorito de culto dentro de la comunidad SEO. Android Central lo describió como una forma de pedir una superficie de resultados web clásica sin AI Overviews. En muchas sesiones produce una SERP tradicional de enlaces azules, pero no es una garantía oficial ni universal.

¿Por qué importa esto? Si haces seguimiento de rankings o auditorías SEO, AI Overviews puede empujar los resultados orgánicos por debajo del primer pliegue y dificultar la evaluación de posiciones. udm=14 puede darte una vista más limpia cuando Google lo respeta.

Dicho esto, udm=14 no está garantizado en todos los contextos. En comprobaciones en vivo del 12 de agosto de 2026, Google a veces eliminaba o reescribía valores udm según el contexto de la solicitud. El resultado variará según la sesión, la cuenta, la región, el cliente y el grupo experimental.

udm=50 se ha observado en contextos de AI Mode / resultados de IA, pero no debe describirse como una forma garantizada de forzar un AI Overview para cualquier consulta.

Qué hacer: actualizar tus flujos de tbm a udm

Mi recomendación:

• Nuevas implementaciones: trata udm como una entrada experimental/contextual y construye alternativas de respaldo.
• Flujos existentes: da soporte y prueba tanto tbm como udm donde corresponda, en lugar de asumir que la migración ya está completada.
• Nunca combines ambos: cuando tbm y udm aparecen a la vez en una URL, el comportamiento es impredecible. En mis pruebas, Google a veces eliminó ambos y devolvió una consulta simple. Más sobre esto en la sección de conflictos.

Sintaxis completa de tbs: rangos de fecha personalizados, ordenar por fecha y verbatim

tbs es uno de los parámetros más potentes del conjunto de URL de Google Search, y la mayoría de las guías solo arañan la superficie. Gestiona filtros de tiempo, ordenación por fecha, modo verbatim y más, todo dentro de un único valor separado por comas.

Filtros de tiempo estándar

Valor de tbs	Significado	Fragmento de URL de ejemplo
qdr:h	Última hora	&tbs=qdr:h
qdr:d	Últimas 24 horas	&tbs=qdr:d
qdr:w	Última semana	&tbs=qdr:w
qdr:m	Último mes	&tbs=qdr:m
qdr:y	Último año	&tbs=qdr:y

Estos son los básicos que cubren la mayoría de guías. Pero tbs puede hacer mucho más.

Rangos de fecha personalizados

¿Necesitas resultados de una ventana temporal concreta? Usa la sintaxis cdr:1,cd_min:MM/DD/YYYY,cd_max:MM/DD/YYYY:

&tbs=cdr:1,cd_min:01/01/2026,cd_max:06/01/2026

Esto filtra los resultados a los que Google asocia fechas entre el 1 de enero y el 1 de junio de 2026. Es muy útil para investigación competitiva — por ejemplo, “¿qué publicaron los competidores sobre precios en el primer trimestre de 2026?”. Solo recuerda codificar toda la cadena en URL, porque dos puntos y barras necesitan codificación.

Un apunte práctico: la asociación de fechas de Google no siempre es exacta. La fecha que aparece en los resultados es la mejor estimación de Google, no necesariamente la fecha real de publicación. Verifica siempre las fechas en la página de destino.

Ordenar por fecha y modo verbatim

Aquí es donde la guía entra en terreno que no cubren otros artículos.

sbd:1 ordena los resultados por fecha (más recientes primero). Por sí solo es útil, pero no sorprendente. El truco es que puedes combinarlo con filtros de rango temporal en un solo valor tbs:

&tbs=qdr:m,sbd:1

Esto devuelve resultados del último mes, ordenados por fecha — de más recientes a más antiguos. Es la forma más rápida de encontrar lo que acaba de publicarse sobre un tema. Yo uso esta combinación constantemente cuando monitorizo contenido de la competencia.

li:1 activa el modo verbatim — el equivalente en URL a hacer clic en la herramienta “Verbatim” de Google en la interfaz de búsqueda. El modo verbatim desactiva autocorrección, expansión de sinónimos, cambios ortográficos y otras modificaciones automáticas de la consulta.

La diferencia entre li:1 y nfpr=1 está en el alcance:

• nfpr=1: solo suprime la reescritura forzada de ortografía/consulta (por ejemplo, evita que Google cambie “teh” por “the”)
• tbs=li:1: desactiva todas las modificaciones automáticas — ortografía, sinónimos, términos relacionados y ajustes de personalización

Incluso puedes encadenar varios valores tbs. Por ejemplo, tbs=qdr:m,sbd:1,li:1 te da resultados del último mes, ordenados por fecha, con coincidencia verbatim. En mis pruebas, esta combinación funciona, aunque recomiendo verificarla con tus consultas concretas, ya que tbs es una sintaxis no documentada.

Cómo construir un código uule para geotargeting a nivel ciudad

Si gl es un zoom a nivel país, uule es un microscopio a nivel ciudad. Para SEO local — comprobar cómo posiciona tu negocio en Denver frente a Dallas, o qué ve un buscador en el distrito de Shibuya en Tokio — gl por sí solo no es lo bastante preciso.

Ningún artículo de primer nivel explica realmente cómo construir un código uule: mencionan que existe y pasan a otra cosa. A continuación va el desglose completo.

Cuándo usar gl vs. uule vs. cr

Parámetro	Granularidad	Caso de uso típico	¿Requiere codificación?
gl=us	Nivel país	Simulación rápida de país	No
cr=countryUS	Nivel país (restricción)	Filtrar por país de alojamiento	No
uule=w+CAIQICI...	Nivel ciudad/DMA	Comprobación de ranking SEO local	Sí

Algoritmo de codificación de uule (paso a paso)

El parámetro uule usa una señal de ubicación con nombre codificada. Su construcción se ha reconstruido por ingeniería inversa, no la documenta oficialmente Google, pero la comunidad SEO la ha validado ampliamente.

La forma más segura es codificar un pequeño payload de Protocol Buffers en lugar de confiar en el atajo que suele copiarse (y que puede fallar con caracteres no ASCII). Este es el proceso:

1. Obtén el nombre canónico de ubicación de Google. Google publica objetivos geográficos con nombres canónicos a través de los datos de segmentación geográfica de la API de Google Ads. Ejemplo: New York,New York,United States
2. Codifica el nombre como bytes UTF-8.
3. Construye un pequeño payload protobuf con el nombre y su longitud en bytes.
4. Codifica el payload en base64url y antepone w+.

Aquí tienes un fragmento de Python que lo hace:

import base64

def encode_varint(value: int) -> bytes:
    out = bytearray()
    while True:
        byte = value & 0x7F
        value >>= 7
        if value:
            out.append(byte | 0x80)
        else:
            out.append(byte)
            return bytes(out)

def build_uule(canonical_name: str) -> str:
    name = canonical_name.encode("utf-8")
    payload = b"\x08\x02\x10\x20\x12" + encode_varint(len(name)) + name
    encoded = base64.urlsafe_b64encode(payload).decode().rstrip("=")
    return "w+" + encoded

# Ejemplo
print(build_uule("New York,New York,United States"))
# Salida: w+CAIQICIeTmV3IFlvcmssTmV3IFlvcmssVW5pdGVkIFN0YXRlcw

Cuando lo pongas en una URL, asegúrate de que el + literal de w+ quede codificado correctamente como %2B por tu biblioteca de URLs. La mayoría de implementaciones de URLSearchParams o urllib.parse.urlencode lo hacen automáticamente.

Un uule correctamente construido sigue siendo solo una señal de ubicación más. No sustituye la IP, la configuración de la cuenta, el dispositivo o el grupo experimental. Úsalo para comprobaciones direccionales de SEO local, no como garantía de rankings exactos por ciudad.

Cuando los parámetros de URL de Google Search entran en conflicto en silencio

Las combinaciones de parámetros pueden fallar en silencio: Google puede ignorar una entrada, reescribir la URL o devolver una superficie distinta. Las comprobaciones de conflicto de abajo merecen añadirse a cualquier flujo de trabajo con enlaces de búsqueda.

Ningún artículo de la competencia cubre las interacciones entre parámetros. Pero si estás construyendo URLs de búsqueda con varios parámetros — y probablemente lo estés haciendo — necesitas saber qué combinaciones conviven bien y cuáles se pisan.

gl + uule: ¿cuál manda?

Cuando ambos están presentes, uule ofrece una señal de ubicación más específica que gl. Si configuras gl=uk y un uule que apunte a Tokio, obtendrás resultados influenciados por Tokio, no por el Reino Unido.

Recomendación: si usas uule, omite gl por completo o fija gl al país que contiene la ciudad de tu uule. No envíes señales contradictorias.

tbm + udm: no uses ambos

En mis pruebas, cuando tbm y udm están presentes en la misma URL, Google a veces elimina ambos y devuelve una consulta web normal. El comportamiento no es consistente entre sesiones y cuentas.

Recomendación: usa solo udm en implementaciones nuevas. Si tienes que soportar flujos heredados, usa uno u otro, nunca los dos.

lr + cr: el doble filtro puede dejarte sin resultados

Esta es una trampa sutil. lr=lang_en restringe a contenido en inglés. cr=countryJP restringe a páginas alojadas en Japón. Si combinas ambos, estás pidiendo “páginas en inglés alojadas en Japón”, un subconjunto muy pequeño de la web.

Recomendación: usa uno u otro salvo que necesites específicamente la intersección. Si los combinas, espera muchos menos resultados.

num + start: paginación rota

Los scripts antiguos que usan num=100&start=0 ahora devuelven en silencio solo unos 10 resultados. El parámetro num ya no se respeta, pero no lanza error: simplemente se ignora.

Recomendación: elimina num de todas las URLs. Paginación con start en incrementos de 10 y deduplicación de resultados entre páginas.

Referencia rápida de conflictos

Combinación	Qué pasa	Recomendación
gl + uule	uule aporta una señal más específica	Alinea país y ciudad, o elimina gl
tbm + udm	Impredecible: pueden eliminarse ambos	Usa solo udm
lr + cr	Restricción muy agresiva, a menudo casi sin resultados	Usa uno u otro
num + start	num se ignora, solo se devuelven ~10 resultados	Elimina num, pagina con start
nfpr=1 + tbs=li:1	Controles relacionados pero no idénticos	Prueba tu consulta concreta
hl + lr	Idioma de interfaz ≠ restricción de idioma del contenido	Úsalos con intención; hl no filtra contenido

De los parámetros de URL de Google Search a la extracción de datos estructurados

A estas alturas ya tienes una URL de Google Search precisa: consulta correcta, país correcto, rango de fechas correcto, resultados web clásicos. El siguiente paso es sacar datos estructurados de esos resultados.

Tanto si estás creando un rastreador de rankings, monitorizando competidores o alimentando datos de búsqueda en un flujo de investigación, ver los resultados correctos es solo la mitad del trabajo. Necesitas títulos, URLs, fragmentos, posiciones y fechas en una hoja de cálculo o base de datos.

Construir una URL de búsqueda de Google dirigida (uniendo todo)

Ejemplo completo que combina varios parámetros:

https://www.google.com/search?q=site%3Acompetitor.com+intitle%3Apricing&hl=en&gl=us&tbs=qdr:m,sbd:1&udm=14&pws=0

Desglose:

• q=site%3Acompetitor.com+intitle%3Apricing — páginas de competitor.com con “pricing” en el título
• hl=en — interfaz en inglés
• gl=us — contexto de mercado estadounidense
• tbs=qdr:m,sbd:1 — último mes, ordenado por fecha
• udm=14 — resultados web clásicos (sin AI Overviews)
• pws=0 — personalización desactivada

Puedes construirlo programáticamente con curl:

curl -L -G 'https://www.google.com/search' \
  --data-urlencode 'q=site:competitor.com intitle:pricing' \
  --data-urlencode 'hl=en' \
  --data-urlencode 'gl=us' \
  --data-urlencode 'tbs=qdr:m,sbd:1' \
  --data-urlencode 'udm=14' \
  --data-urlencode 'pws=0' \
  -H 'User-Agent: Mozilla/5.0'

O con Python:

import requests

params = {
    "q": "site:competitor.com intitle:pricing",
    "hl": "en",
    "gl": "us",
    "tbs": "qdr:m,sbd:1",
    "udm": "14",
    "pws": "0",
}

response = requests.get(
    "https://www.google.com/search",
    params=params,
    headers={"User-Agent": "Mozilla/5.0"},
    timeout=20,
)
print(response.url)

Las solicitudes HTTP anónimas a Google suelen devolver shells de JavaScript sin resultados renderizados por el servidor, o avisos de tráfico inusual, que es precisamente donde la extracción basada en navegador tiene ventaja.

Extraer datos de SERP sin escribir un parser

Analizar el HTML de Google es frágil. La estructura del DOM cambia con frecuencia, los nombres de clase están ofuscados y lo que ves en el navegador no siempre coincide con lo que recibes en una respuesta HTTP en bruto.

Un enfoque más simple para no desarrolladores: abre tu URL de búsqueda cuidadosamente construida en Chrome y usa una herramienta de extracción basada en navegador para sacar datos estructurados de la página visible. En Thunderbit, construimos nuestra extensión de Chrome precisamente para este tipo de flujo: puedes usar AI Suggest Fields para identificar columnas como título del resultado, URL de destino, texto del snippet y posición visible, y luego extraerlas a una hoja de cálculo sin escribir un parser.

No es la única opción. Los enfoques basados en código también funcionan, sobre todo si necesitas extracción a gran escala o repetitiva. Pero para investigación ad hoc, auditorías y análisis competitivo puntual, la extracción basada en navegador evita por completo la fragilidad del parsing de HTML.

Cuándo usar una API oficial en su lugar

Aviso de uso responsable, y es importante.

Los Términos del Servicio de Google prohíben el acceso automatizado que eluda medidas de protección, y Google Search Help clasifica explícitamente los scrapers de búsqueda y el software que envía consultas automatizadas para determinar rankings como tráfico automatizado. Ejecutar un scraper de Google a escala de producción te expone a bloqueos de IP, CAPTCHAs y posibles problemas legales.

Para necesidades de datos de búsqueda a gran volumen y en producción, la mejor vía es una API oficial. La API Custom Search JSON de Google deja de admitir nuevos clientes: los usuarios actuales tienen hasta el 1 de enero de 2027 para migrar, con 100 consultas gratuitas al día y luego $5 por 1.000 consultas. Google recomienda Vertex AI Search para búsquedas sobre sitios controlados de aquí en adelante.

Para sitios que son tuyos, la Search Analytics API de Search Console es la fuente de primera parte para clics, impresiones, CTR y posición media: sin necesidad de scraping.

Piensa en el conocimiento de los parámetros de URL como una herramienta de diagnóstico e investigación: excelente para crear enlaces de búsqueda precisos, hacer auditorías manuales y entender qué muestra Google. No sustituye a las APIs oficiales a escala.

Operadores de búsqueda de Google: los parámetros dentro de tu consulta

Los operadores de búsqueda viven dentro del parámetro q=, pero son compañeros esenciales de los parámetros de URL. La tabla de abajo cubre los que Google documenta actualmente y algunos que siguen funcionando en la práctica:

Operador	Qué hace	Ejemplo
site:	Restringe a un dominio	q=site:example.com+SEO
filetype:	Restringe a un tipo de archivo	q=filetype:pdf+annual+report
intitle:	La palabra debe aparecer en el título	q=intitle:pricing+SaaS
inurl:	La palabra debe aparecer en la URL	q=inurl:blog+marketing
-	Excluye un término	q=apple+-fruit
""	Coincidencia exacta de frase	q=%22google+search+url+parameters%22
OR	Uno u otro término	q=scraping+OR+crawling
before:	Resultados anteriores a una fecha	q=AI+before:2026-01-01
after:	Resultados posteriores a una fecha	q=AI+after:2025-06-01
related:	Sitios similares	q=related:hubspot.com

El verdadero poder viene de combinar operadores dentro de q con parámetros de URL fuera de él:

q=site:competitor.com+intitle:pricing+after:2026/01/01&tbs=sbd:1&gl=us&udm=14

Esto encuentra páginas de competitor.com con “pricing” en el título, publicadas después de enero de 2026, ordenadas por fecha, en el mercado estadounidense y con resultados web clásicos. Es una consulta de inteligencia competitiva muy precisa, construida íntegramente con parámetros de URL y operadores.

Google dice que los resultados de site: no están garantizados como completos: no trates una consulta site: como un inventario exhaustivo de páginas indexadas.

Uso responsable: términos del servicio de Google y límites de tasa

Contexto breve pero importante.

Los Términos del Servicio de Google prohíben el acceso abusivo y eludir medidas de protección. Google Search Help menciona específicamente los scrapers de búsqueda y el software automatizado de ranking como ejemplos de tráfico automatizado. Violar estas condiciones puede causar bloqueos de IP, CAPTCHAs, restricciones de cuenta y potenciales acciones legales.

El conocimiento de los parámetros de URL se aprovecha mejor para: construir manualmente URLs de búsqueda precisas, crear enlaces de búsqueda marcables para tu equipo, ejecutar auditorías pequeñas en un navegador y entender cómo funciona la interfaz de búsqueda de Google. Para trabajo automatizado a escala de producción, usa las APIs oficiales de Google o un proveedor externo autorizado de datos de búsqueda como Brave Search API.

En Thunderbit, nuestra extensión de navegador está pensada para extracción iniciada por el usuario y visible en página, no para consultas automatizadas masivas a Google. Esa es una distinción importante.

Conclusiones clave: tu kit de parámetros de URL de Google Search para 2026

La versión resumida:

• Usa gl + hl para señales de localización y no dependas solo de los ccTLD durante la migración de redirecciones de Google
• Prueba tanto udm como tbm cuando corresponda: ninguno es una API estable y versionada para consumidores
• udm=14 puede pedir resultados web clásicos sin AI Overviews, pero Google puede eliminarlo o reescribirlo
• Usa uule para geotargeting a nivel ciudad con la fórmula de codificación protobuf de arriba
• Domina tbs para filtrado preciso por fecha (cdr:1,cd_min:...,cd_max:...), ordenación por fecha (sbd:1) y búsqueda verbatim (li:1)
• Ten cuidado con los conflictos entre parámetros: gl frente a uule, tbm frente a udm, lr frente a cr
• num=100 no es fiable y nunca tuvo soporte formal: usa start en incrementos de 10 como opción más segura
• Para datos estructurados de SERP, usa herramientas basadas en navegador como Thunderbit para trabajo ad hoc, o APIs oficiales para producción
• Respeta los Términos del Servicio de Google: los parámetros de URL son una herramienta de investigación, no una licencia para scrapear

Google sigue cambiando parámetros sin aviso. Mantendré esta referencia actualizada a medida que evolucione: guárdala y vuelve a consultarla.

Saber más

• Las 9 mejores APIs SEO para 2026 (con datos reales de coste por solicitud)
• Cómo dominar el scraping de motores de búsqueda: guía completa
• Las 27 mejores herramientas para analizar y monitorizar rankings de sitios web
• Cómo usar la paginación de Web Scraper para una extracción eficiente
• ¿Qué es la automatización de búsqueda? Beneficios, herramientas y estrategias

Preguntas frecuentes

¿Qué hace udm=14 en una URL de búsqueda de Google?

udm=14 puede pedir una superficie de resultados web clásica sin AI Overviews, por eso es popular entre los profesionales SEO. Está reconstruido por ingeniería inversa, no es un contrato oficial documentado de Google, y Google puede eliminarlo o reescribirlo según la sesión, la cuenta, la región, el cliente y el grupo experimental.

¿Sigue funcionando el parámetro num en 2026?

No confíes en él. Google dejó de respetar de forma fiable num=100 en septiembre de 2025, y un portavoz dijo que el parámetro nunca tuvo soporte formal. Usa start en incrementos de 10 como opción de paginación más segura, y verifica el número de resultados devueltos porque Google todavía puede reescribir o limitar la respuesta.

¿Cómo simulo una búsqueda de Google desde una ciudad concreta?

Usa el parámetro uule con un nombre de ciudad codificado. La sección de codificación anterior incluye el algoritmo basado en protobuf y un ejemplo en Python. Necesitarás el nombre canónico de ubicación de Google (disponible en los datos de segmentación geográfica de Google Ads), que codificas en un valor uule como uule=w+CAIQICIeNew+York,New+York,United+States.

¿Cuál es la diferencia entre gl, lr y cr?

Estos tres parámetros controlan aspectos distintos del targeting geográfico y lingüístico. gl simula tu ubicación de búsqueda a nivel país (afecta al ranking y a los resultados locales). lr restringe los resultados a páginas escritas en un idioma específico del contenido. cr restringe los resultados a páginas alojadas en un país concreto. Se pueden combinar, pero las combinaciones contradictorias (como lr=lang_en + cr=countryJP) reducirán muchísimo los resultados.

¿Puedo combinar varios valores tbs en una sola URL?

Sí: sepáralos con comas dentro de un único parámetro tbs. Por ejemplo, tbs=qdr:m,sbd:1 filtra al último mes y ordena por fecha (más recientes primero). También puedes añadir li:1 para modo verbatim: tbs=qdr:m,sbd:1,li:1. La sintaxis de tbs no está documentada, así que prueba tus combinaciones concretas para confirmar que funcionan como esperas.