Por qué tu enlace pierde datos: corrige parámetros y fragmentos

Una página que abre no siempre recibe lo que esperabas

Has preparado un enlace a una búsqueda de café y té. La página abre, pero los resultados no corresponden a tu intención. Antes de culpar al servidor o al acortador, revisa la dirección exacta que has compartido. En nuestro ejemplo ficticio, q=cafe&te no representa un único valor cafe&te en la interpretación habitual de parámetros de formulario: el signo & separa entradas. Además, #precios marca un fragmento. Sustituye example.invalid por una página tuya que admita la consulta antes de probar una dirección real.

Separa el diagnóstico en tres preguntas: qué página quieres abrir, qué datos debe recibir y qué parte quieres mostrar después. Copia la URL del enlace, no solo la etiqueta visible del botón. Guarda una versión de referencia antes de editar. Esta guía propone revisar los componentes y después comprobar el resultado con WikiURL; no promete que cualquier sitio reconozca el nombre q ni que una respuesta correcta equivalga a resultados de búsqueda correctos.

https://example.invalid/buscar?q=cafe&te#precios

Si el ampersand es parte del texto, no lo uses como separador

Para buscar literalmente cafe & te, el ampersand pertenece al valor de q. Al construir parámetros con URLSearchParams, proporciona el texto sin codificar; la serialización representará ese carácter como %26. MDN explica que esta interfaz aplica la codificación de formularios al convertir los parámetros en texto y representa los espacios con +. Eso no significa que debas sustituir todos los ampersands de una URL: algunos separan parámetros de forma intencionada.

El ejemplo JavaScript crea la dirección desde una base, asigna el valor de búsqueda y añade el fragmento por separado. Puedes ejecutarlo localmente en un entorno JavaScript para observar el resultado, sin enviar la búsqueda al dominio ficticio. Si no programas, utiliza el enlace que genere tu propia página de búsqueda en lugar de concatenar texto manualmente. Compara el valor esperado con el resultado que muestra el sitio; ver %26 en el enlace no basta para saber cómo interpreta los datos una aplicación concreta.

const url = new URL("https://example.invalid/buscar");
url.searchParams.set("q", "cafe & te");
url.hash = "precios";
console.log(url.href);
// https://example.invalid/buscar?q=cafe+%26+te#precios

El fragmento no es un parámetro que recibe el servidor

MDN documenta que el fragmento situado después de # se procesa en el cliente y no se envía al servidor al solicitar el recurso. Una página puede usarlo para llegar a una sección, como precios, o para otro comportamiento de su aplicación. Por tanto, si pones q=cafe#te, te no completa el valor que recibe el servidor en esa petición. Si el símbolo # debe formar parte del texto de búsqueda, su representación dentro del valor será %23, como ilustra la tercera dirección.

Comprueba ambos efectos por separado: que la búsqueda muestre los resultados previstos y que el fragmento llegue al lugar deseado. La sección debe existir o la aplicación debe reconocer ese fragmento. Un comprobador que consulta la web desde el servidor no confirma por sí solo que el navegador se desplace a una sección. Tampoco borres todos los fragmentos como solución universal; puedes eliminar precisamente la parte del enlace que el destinatario necesitaba.

https://example.invalid/buscar?q=cafe%23te#precios

Codifica el valor una vez, no la dirección entera

El estándar RFC 3986 distingue los caracteres que delimitan componentes de los datos y advierte contra codificar o decodificar repetidamente la misma cadena. Si entregas cafe%26te como texto ya codificado a una función que espera un valor sin codificar, el porcentaje puede convertirse en %25 y aparecer %2526. En ese caso has añadido una capa: no has conservado automáticamente la búsqueda deseada. Las dos líneas del ejemplo permiten reconocer ese cambio.

La corrección depende del origen del dato. Si parte de texto humano, pásalo sin codificar a la interfaz que construye parámetros. Si parte de una URL completa ya válida, no la trates como un único valor para volver a codificarla entera. Documenta qué recibe cada función o formulario. Evita arreglos globales de buscar y reemplazar sobre %, & o #: podrías modificar delimitadores correctos, parámetros necesarios o rutas que no pretendías cambiar.

q=cafe%26te
q=cafe%2526te

Utiliza WikiURL para revisar la respuesta, y el navegador para el contenido

Cuando tengas una dirección pública real, pégala en el comprobador de URL de WikiURL. Revisa el estado HTTP y el destino final que devuelve. La implementación consulta desde el servidor y sigue redirecciones: esa revisión ayuda a localizar un destino inesperado. No pegues enlaces de administración, contraseñas ni direcciones con datos privados. Para nuestros ejemplos, no intentes comprobar example.invalid; está reservado aquí como destino ficticio.

Abre también la versión real en tu navegador y revisa la búsqueda y la sección. Una respuesta satisfactoria puede cargar la página sin aplicar el filtro esperado. Si hay una redirección, compara sus parámetros con la referencia y observa el fragmento en el navegador. El comprobador no interpreta por ti la lógica de la aplicación, ni certifica seguridad, ni prueba que una cuenta de usuario tenga permiso para ver el contenido. El objetivo es unir evidencia de la respuesta con una revisión funcional.

Prueba la copia que recibirá otra persona

Pega el enlace final en el canal donde lo compartirás y abre esa copia antes de distribuirla ampliamente. Comprueba que no hayas incluido un punto final de la frase, perdido una parte al copiar o usado el texto visible como si fuera el destino. Haz la prueba sin depender de tu sesión de administrador cuando el contenido deba ser público. Si lo conviertes en QR, comprueba también la dirección que muestra el escaneo, además de revisar el archivo de origen.

Conserva un pequeño registro: dirección original, valor de búsqueda esperado, fragmento previsto, URL compartida y resultado observado. Si falla, vuelve al componente concreto y repite la prueba después de corregirlo. Publica solo la versión comprobada. Así distingues un problema de construcción de parámetros, una redirección que cambia el destino y un comportamiento del navegador, sin convertir un enlace que abre en una garantía de que conserva todos los datos que querías enviar.