Error 405 al revisar un enlace: compara HEAD y GET

No declares roto el enlace solo por el número

Tu navegador abre una página, pero una comprobación devuelve 405. La discrepancia merece una revisión, no borrar el enlace inmediatamente. El código significa que el método solicitado no está admitido para ese recurso según la respuesta recibida. No equivale a una confirmación de que el contenido exista, sea público o esté disponible para cada visitante. Conserva la dirección exacta y anota qué herramienta produjo el resultado.

En una consulta de Stack Overflow, cambiar una comprobación de GET a HEAD provocaba errores 405. Otra pregunta, en Reddit, describe falsos positivos al revisar enlaces desde un programa. Son problemas comunicados por personas, no pruebas de la causa de tu caso. Esta guía propone comparar peticiones y comprobar el contenido antes de decidir si corregir el enlace, el comprobador o la configuración del sitio.

Qué cambia entre HEAD y GET

GET solicita una representación del recurso; HEAD pide los metadatos que corresponderían a GET, sin el cuerpo de esa respuesta. MDN documenta esta diferencia. Pedir solo cabeceras puede ahorrar transferencia, pero no permite leer la página ni confirmar que contiene el documento esperado. Tampoco garantiza que una aplicación o intermediario gestione correctamente ambos métodos. Un método rechazado exige registrar cuál se utilizó.

RFC 9110 establece que una respuesta 405 debe incluir Allow con los métodos admitidos actualmente para el recurso. Mira esa cabecera si tu herramienta la muestra. Si falta, documenta su ausencia; no inventes su contenido ni supongas que permitir cualquier método resolvería el problema. El ejemplo de respuesta es ilustrativo, no una captura de un sitio real. Allow tampoco sustituye la prueba del método que necesitas.

HTTP/1.1 405 Method Not Allowed
Allow: GET

Compara peticiones que puedas interpretar

Si administras el sitio y sabes usar una terminal, compara HEAD y GET sobre la misma dirección pública de lectura. Los comandos muestran cabeceras; el segundo descarta el cuerpo después de recibirlo, por lo que puede descargar datos. Sustituye example.invalid por tu página autorizada; ese dominio es ficticio y no debe comprobarse como si fuera un servicio disponible. No pruebes acciones de compra, borrado o cierre de sesión.

Mantén iguales la URL y las condiciones que controles. Anota hora, método, estado y posible redirección. Los comandos no siguen redirecciones: si aparece una, revisa primero su destino y decide si corresponde repetir allí. No añadas credenciales ni copies cookies privadas a herramientas públicas. Un navegador con sesión iniciada y una petición anónima desde otra máquina no constituyen una comparación equivalente; registra esa diferencia antes de atribuir el fallo al método.

curl --head --max-time 20 "https://example.invalid/guide"
curl --silent --show-error --max-time 20 --dump-header - --output /dev/null "https://example.invalid/guide"

Interpreta el resultado sin saltar a conclusiones

Si observas HEAD 405 y GET 200 en condiciones comparables, puedes afirmar que esas dos peticiones recibieron respuestas diferentes. Aún falta abrir la página y comprobar el contenido. Si GET también recibe 405, no has demostrado un problema exclusivo de HEAD. Si devuelve 404, la prueba anterior de HEAD no acreditaba que existiera la página solicitada. Mantén cada observación separada de tu hipótesis.

No cambies un formulario de POST a GET para eliminar el mensaje de error. Puede alterar su funcionamiento y exponer datos en la dirección. Tampoco desactives controles de seguridad ni habilites métodos de escritura por comodidad. En un sitio propio, entrega los resultados a quien revise las rutas y las reglas del servidor. Si el sitio es ajeno, solicita un enlace público adecuado o informa del fallo con datos no sensibles.

Añade la comprobación de WikiURL

Pega la dirección pública completa en el comprobador de URL de WikiURL y guarda el estado HTTP y la dirección final detectada. Es una observación adicional desde el servidor del servicio. No presupongas que reproduce tu navegador, tu sesión o los comandos anteriores. La interfaz no ofrece una selección manual entre HEAD y GET; no le atribuyas una prueba comparativa que no presenta.

Abre después el destino real en un navegador y confirma que es la página prevista para su audiencia. Si el comprobador y el navegador discrepan, conserva ambos resultados y sus condiciones. Un 200 no certifica el contenido ni la seguridad; un 405 aislado no decide por sí solo retirar el enlace. El objetivo es reunir evidencia útil para corregir el componente concreto, no convertir una etiqueta en un diagnóstico completo.

Guarda una decisión verificable antes de compartir

Prepara un registro breve: URL, fecha, herramienta, método conocido o no observado, estado, destino final y contenido comprobado. Escribe pendiente cuando falte una prueba. Guarda las cabeceras necesarias sin tokens, cookies o datos personales. Si otra persona debe revisar el caso, envíale este resumen y la conducta esperada, no una conclusión que las observaciones todavía no sostienen.

Repite una comprobación proporcionada tras una corrección concreta y confirma el contenido antes de acortar la dirección o generar un QR con WikiURL. Esos formatos facilitan compartir, pero no cambian el método que admite el servidor ni reparan el recurso. Conserva el enlace de referencia junto al archivo publicado. Así podrás distinguir una diferencia entre clientes, un método rechazado y un destino realmente equivocado sin destruir una dirección válida por una única respuesta.