-SEO no anti-spoofing externo enlace de redirección: Código de estado?

Question

He leído varios documentos sobre los méritos de los diferentes códigos de estado HTTP redirigir, pero those've todo ha estado muy centrada en SEO. ahora tengo un problema donde motores de búsqueda no tienen en cuenta, debido a que la sección del sitio en cuestión no es visible públicamente.

Sin embargo, nosotros queremos que nuestra web sea lo más preciso / útiles con los meta-datos como sea posible, especialmente por razones de accesibilidad.

Ahora, nuestra aplicación tiene enlaces externos proporcionados por terceros y las envía a través de una página de anti-spoofing con un descargo de responsabilidad. Desde esta página de redirección puede efectivamente también ser embebido a través de una llamada Ajax en ciertas constelaciones, también queremos despojar a los parámetros de consulta del árbitro (por razones de privacidad, el sitio de destino no tiene por qué enterarse de qué página interna que el usuario estaba encendido antes) .

Para ello, el botón de confirmación desencadena un script del lado del servidor que a su vez vuelve a dirigir (en lugar de abrir la página para el usuario).

Tanto en cuanto a porqué nuestra página de descargo de responsabilidad contra la suplantación de identidad termina desencadenando una redirección.

La pregunta es:

¿Se efectivamente hace ninguna diferencia lo que el código de estado que utilizo? ¿Los navegadores no típicas (por ejemplo, los lectores de pantalla) se preocupan? Si es así, ¿cuál es la mejor práctica para este tipo de redirecciones? El más semánticamente sonido, si así lo hará? Todos ellos parecen diferentes grados de sincero a mí.

Estoy pensando en un 302 - pero ya que no tiene sentido tratar de marcar la página (que está protegida con un token MERC), por lo que es probable que haya ningún daño en un 301, o bien, ¿verdad? Así que me pregunto si hay una razón para que yo prefiero el uno sobre el otro.

Answer 1

Hmm. Aquí está la lista 301 suena bien (el énfasis es mío):.

  

El recurso solicitado se le ha asignado un nuevo URI permanente y cualquier versión futura referencias a este recurso es conveniente utilizar una de las URIs devuelto . Los clientes con capacidades de edición de enlace debe referencias al Request-URI de enlace volver automáticamente a una o más de las nuevas referencias devueltos por el servidor, siempre que sea posible.

302 no encaja n mi opinión:

  

El recurso solicitado reside temporalmente bajo una diferente URI

Sin embargo, mi favorito es 303 see other:

  

La respuesta a la petición puede encontrarse en una diferente URI y debe ser recuperada usando un método GET en ese recurso . Este método existe principalmente para permitir la salida de una secuencia de comandos activado-POST para redirigir el agente de usuario a un recurso seleccionado. El nuevo URI no es un sustituto de referencia para el recurso solicitado originalmente.

Pero eso podría ser tan raro (nunca he visto que se usa en la naturaleza) que algunos clientes no pueden entender que - lo que haría que su deseo de discutible la máxima compatibilidad. 301 es probablemente la opción más cercana.