This page has been robot translated, sorry for typos if any. Original content here.

Redirections dans htaccess et Scripts (301/302)

Редиректы в htaccess (301/302)

La 301e erreur (301 Permament Redirect) renvoyée lorsque l'accès à une adresse de page spécifique signifie que le site a été déplacé définitivement vers une nouvelle adresse, également spécifiée dans l'en-tête HTTP. Les utilisateurs et les robots de recherche qui passent par le navigateur seront redirigés vers la nouvelle adresse, tandis que pour les moteurs de recherche, toutes les propriétés de l'ancienne adresse (page) seront transférées vers la nouvelle URL.

Rediriger 301 (déplacé définitivement) est le meilleur moyen de conserver le classement du site dans les moteurs de recherche lorsque vous le déplacez vers un nouveau domaine ou changez le système de gestion de contenu. Lorsque la redirection 301, les anciennes et nouvelles adresses seront collées ensemble: les paramètres comme PageRank et TCI, ainsi que le poids de la page et le poids de référence de l'ancienne adresse seront transmis à la nouvelle URL.

Voici les règles les plus utilisées pour configurer le fichier .htaccess pour la redirection 301.

Внимание Dans les règles: % {QUERY_STRING} - indique le fragment de l'URL après le point d'interrogation (définition des valeurs des paramètres CGI).

Внимание Le fonctionnement de telle ou telle règle pour une redirection est déterminé par le fait que l'URL de la page relève ou non de cette règle.

Внимание Pour la signification de certaines notations (^, $, NC, etc.), voir le rappel au bas de la page .

Внимание Toutes les règles sont exécutées dans l'ordre direct de leur suite dans le fichier .htaccess et la règle écrite plus tard, et seront exécutées plus tard.

Внимание Il est préférable de poster toutes les règles après deux lignes:

  Options + SuivezSymLinks
 RewriteEngine On 

301 redirection d'un domaine sans WWW vers un domaine avec un préfixe WWW (le miroir principal est un domaine avec www)

  RewriteCond% {HTTP_HOST} ^ site \ .ru $ [NC]
 RewriteRule ^ (. *) $ Http://www.site.ru/$1 [R = 301, L] 

D'un domaine avec un préfixe WWW sans (le miroir principal est un domaine sans www)

  RewriteCond% {HTTP_HOST} ^ www.site \ .ru $ [NC]
 RewriteRule ^ (. *) $ Http://site.ru/$1 [R = 301, L] 

Redirection standard d'une page statique à une autre

  Redirection 301 /was.php http://www.site.ru/new.php 

Dans ce cas, la nouvelle adresse doit être complètement spécifiée avec http et nom de domaine.

Dans certains cas, la redirection via RewriteRule est utile

  RewriteRule ^ dir / rep-new / $ 1 [R = 301, L] 

Redirection 301 pour la page avec les paramètres GET

Dites, l'adresse de la page est: http: //www.site.ru/dir/index.php? IBLOCK_ID = 1 & SECTION_ID = 111 puis pour configurer 301 redirections vers une nouvelle adresse, vous devez utiliser la règle suivante:

  RewriteCond% {QUERY_STRING} ^ IBLOCK_ID = 1 & SECTION_ID = 111 $ [NC]
 RewriteRule ^ dir / index \ .php $ / nouveau / sef /?  [R = 301, L] 

Si un (ou plusieurs) des paramètres GET n'est pas spécifié (ou), ou peut avoir une valeur arbitraire (dans notre exemple, c'est SECTION_ID ), vous pouvez utiliser le code suivant:

  RewriteCond% {QUERY_STRING} ^ IBLOCK_ID = 1 & SECTION_ID = (. *) $ [NC]
 RewriteRule ^ dir / index \ .php $ / nouveau / sef /?  [R = 301, L] 

301 redirige uniquement les adresses site.ru/index.php (sans les paramètres GET) vers le miroir du site principal.

  RewriteCond% {REQUEST_URI} /index.php
 RewriteCond% {QUERY_STRING} ^ \ z
 RewriteRule ^ (. *) $ Http://site.ru/?  [R = 301, L] 

301 redirection de toutes les adresses avec les paramètres index.php et GET vers les pages uniquement avec les paramètres GET (couper à url index.php)

Exemple: tapez site.ru/index.php?n=1 sur site.ru/?n=1

  RewriteCond% {REQUEST_URI} /index.php
 RewriteRule ^ (. *) $ Http://site.ru/ [R = 301, L] 

301 rediriger l'URL avec les paramètres GET (URL dynamique) vers statique

1 variante (adresse simple avec paramètre GET)

  RewriteCond% {QUERY_STRING} ^ id = 229
 RewriteRule ^. * $ / Supermodel /?  [R = 301, L] 

2 option (à partir de la page et du paramètre GET)

  RewriteCond% {REQUEST_URI} / test /
 RewriteCond% {QUERY_STRING} ^ id = 229
 RewriteRule ^. * $ / Supermodel /?  [R = 301, L] 

Redirection 301 pour un fichier particulier, pas un dossier entier

Si vous souhaitez configurer la redirection uniquement pour l'adresse http://www.site.ru/dir/ , mais en même temps la page http://www.site.ru/dir/index.php?IBLOCK_ID=1 est ouverte à l'ancienne adresse, vous devez Utilisez le caractère spécial $ dans la règle.

  RewriteRule ^ dir / $ http://www.site.ru/new-dir/ [R = 301, L] 

Toutes les pages du même domaine sur la page d'accueil d'un autre domaine

  RewriteCond% {REQUEST_URI} (. *)
 RewriteRule ^ (. *) $ Http://site.ru/ [L, R = 301] 

Chaque page d'un domaine est à la même adresse d'une autre URL

  RewriteCond% {REQUEST_URI} (. *)
 RewriteRule ^ (. *) $ Http://site.ru/$1 [L, R = 301] 

Qu'en est-il des domaines dans la zone RF?

Pour les domaines de la zone RF, toutes les mêmes règles s'appliquent, mais seuls tous les symboles cyrilliques doivent être remplacés par un code alternatif (c'est en latin). En particulier, la zone elle-même. pf est transformé en. xn - p1ai .

Redirection 301 d'un domaine vers un domaine

  RewriteCond% {HTTP_HOST} ^ ancien site \ .ru $ [NC]
 RewriteRule ^ (. *) $ Http://www.site.ru/$1 [R = 301, L] 

301 redirection pour un domaine dans la zone RF

  RewriteCond% {HTTP_HOST} ^ xn -... \. Xn - p1ai $ [NC]
 RewriteRule ^ (. *) $ Http://www.site.ru/$1 [R = 301, L] 

Définir la redirection vers les dossiers slash à la fin / (ajouter une barre oblique à la fin)

  RewriteCond% {REQUEST_FILENAME}! -f
 RewriteCond% {REQUEST_URI}! \ .. {1.10} $
 RewriteCond% {REQUEST_URI}! (. *) / $
 RewriteRule ^ (. *) $ Http://www.site.ru/$1/ [L, R = 301] 

Redirection 301 à partir de pages avec une barre oblique sans barre oblique (site entier)

  RewriteCond% {REQUEST_URI}! \?
 RewriteCond% {REQUEST_URI}! \ &
 RewriteCond% {REQUEST_URI}! \ =
 RewriteCond% {REQUEST_URI}! \.
 RewriteCond% {REQUEST_URI}! [^ \ /] $
 RewriteRule ^ (. *) \ / $ / $ 1 [R = 301, L] 

Configurez la redirection vers les dossiers sans barre oblique (supprimez la barre oblique à la fin)

  RewriteCond% {REQUEST_FILENAME}! -d
 RewriteCond% {REQUEST_URI} ^ (. +) / $
 RewriteRule ^ (. +) / $ Http://www.site.ru/$1 [R = 301, L] 

301 redirection à partir de pages sans barre oblique sur la barre oblique (souvent dans les systèmes CMS installés automatiquement)

  RewriteCond% {REQUEST_URI}! \?
 RewriteCond% {REQUEST_URI}! \ &
 RewriteCond% {REQUEST_URI}! \ =
 RewriteCond% {REQUEST_URI}! \.
 RewriteCond% {REQUEST_URI}! \ / $
 RewriteRule ^ (. * [^ \ /]) $ / $ 1 / [R = 301, L] 

Un (et pas deux consécutifs!) 301 redirections sans www et avec une barre oblique à la fin de l'adresse de la page

  RewriteCond% {REQUEST_URI}! \?
 RewriteCond% {REQUEST_URI}! \ &
 RewriteCond% {REQUEST_URI}! \ =
 RewriteCond% {REQUEST_URI}! \.
 RewriteCond% {REQUEST_URI}! \ / $
 RewriteCond% {HTTP_HOST} ^ www \. (. *) $
 RewriteRule ^ (. *) $ Http: //% 1 / $ 1 / [L, R = 301]
 
 RewriteCond% {REQUEST_URI}! \?
 RewriteCond% {REQUEST_URI}! \ &
 RewriteCond% {REQUEST_URI}! \ =
 RewriteCond% {REQUEST_URI}! \.
 RewriteCond% {REQUEST_URI}! [^ \ /] $
 RewriteCond% {HTTP_HOST} ^ www \. (. *) $
 RewriteRule ^ (. *) $ Http: //% 1 / $ 1 [L, R = 301]
 
 RewriteCond% {REQUEST_URI}! \?
 RewriteCond% {REQUEST_URI}! \ &
 RewriteCond% {REQUEST_URI}! \ =
 RewriteCond% {REQUEST_URI}! \.
 RewriteCond% {REQUEST_URI}! \ / $
 RewriteCond% {HTTP_HOST} ^ ([^ www]. *) $
 RewriteRule ^ (. *) $ Http: //% 1 / $ 1 / [L, R = 301] 

Un (et non deux consécutifs!) 301 redirige vers www et avec une barre oblique à la fin de l'adresse de la page

  RewriteCond% {REQUEST_URI}! \?
 RewriteCond% {REQUEST_URI}! \ &
 RewriteCond% {REQUEST_URI}! \ =
 RewriteCond% {REQUEST_URI}! \.
 RewriteCond% {REQUEST_URI}! \ / $
 RewriteCond% {HTTP_HOST} ^ www \. (. *) $
 RewriteRule ^ (. *) $ Http: //www.%1/$1/ [L, R = 301]
 
 RewriteCond% {REQUEST_URI}! \?
 RewriteCond% {REQUEST_URI}! \ &
 RewriteCond% {REQUEST_URI}! \ =
 RewriteCond% {REQUEST_URI}! \.
 RewriteCond% {REQUEST_URI}! \ / $
 RewriteCond% {HTTP_HOST} ^ ([^ www]. *) $
 RewriteRule ^ (. *) $ Http: //www.%1/$1/ [L, R = 301]
 
 RewriteCond% {REQUEST_URI}! \?
 RewriteCond% {REQUEST_URI}! \ &
 RewriteCond% {REQUEST_URI}! \ =
 RewriteCond% {REQUEST_URI}! \.
 RewriteCond% {REQUEST_URI}! [^ \ /] $
 RewriteCond% {HTTP_HOST} ^ ([^ www]. *) $
 RewriteRule ^ (. *) $ Http: //www.%1/$1 [L, R = 301] 

Un (et non deux consécutifs!) 301 redirige vers www et sans barre oblique à la fin de l'adresse de la page

  RewriteCond% {REQUEST_URI} ^ \ / $
 RewriteCond% {HTTP_HOST} ^ ([^ www]. *) $
 RewriteRule ^ (. *) $ Http: //www.%1/$1 [L, R = 301]
 
 RewriteCond% {REQUEST_URI}! \?
 RewriteCond% {REQUEST_URI}! \ &
 RewriteCond% {REQUEST_URI}! \ =
 RewriteCond% {REQUEST_URI}! \.
 RewriteCond% {REQUEST_URI} \ / $
 RewriteCond% {HTTP_HOST} ^ www \. (. *) $
 RewriteRule ^ (. *) \ / $ Http: //www.%1/$1 [L, R = 301]
 
 RewriteCond% {REQUEST_URI}! \?
 RewriteCond% {REQUEST_URI}! \ &
 RewriteCond% {REQUEST_URI}! \ =
 RewriteCond% {REQUEST_URI}! \.
 RewriteCond% {REQUEST_URI}! \ / $
 RewriteCond% {HTTP_HOST} ^ ([^ www]. *) $
 RewriteRule ^ (. *) $ Http: //www.%1/$1 [L, R = 301]
 
 RewriteCond% {REQUEST_URI}! \?
 RewriteCond% {REQUEST_URI}! \ &
 RewriteCond% {REQUEST_URI}! \ =
 RewriteCond% {REQUEST_URI}! \.
 RewriteCond% {REQUEST_URI} \ / $
 RewriteCond% {HTTP_HOST} ^ ([^ www]. *) $
 RewriteRule ^ (. *) \ / $ Http: //www.%1/$1 [L, R = 301] 

Un (et pas deux consécutifs!) 301 redirections sans www et sans barre oblique à la fin de l'adresse de la page

  RewriteCond% {REQUEST_URI} ^ \ / $
 RewriteCond% {HTTP_HOST} ^ www \. (. *) $
 RewriteRule ^ (. *) $ Http: //% 1 / $ 1 [L, R = 301]
 
 RewriteCond% {REQUEST_URI}! \?
 RewriteCond% {REQUEST_URI}! \ &
 RewriteCond% {REQUEST_URI}! \ =
 RewriteCond% {REQUEST_URI}! \.
 RewriteCond% {REQUEST_URI} \ / $ 
 RewriteCond% {HTTP_HOST} ^ www \. (. *) $
 RewriteRule ^ (. *) \ / $ Http: //% 1 / $ 1 [L, R = 301]
 
 RewriteCond% {REQUEST_URI}! \?
 RewriteCond% {REQUEST_URI}! \ &
 RewriteCond% {REQUEST_URI}! \ =
 RewriteCond% {REQUEST_URI}! \.
 RewriteCond% {REQUEST_URI}! \ / $
 RewriteCond% {HTTP_HOST} ^ www \. (. *) $
 RewriteRule ^ (. *) $ Http: //% 1 / $ 1 [L, R = 301]
 
 RewriteCond% {REQUEST_URI}! \?
 RewriteCond% {REQUEST_URI}! \ &
 RewriteCond% {REQUEST_URI}! \ =
 RewriteCond% {REQUEST_URI}! \.
 RewriteCond% {REQUEST_URI} \ / $
 RewriteCond% {HTTP_HOST} ^ ([^ www]. *) $
 RewriteRule ^ (. *) \ / $ Http: //% 1 / $ 1 [L, R = 301] 

301 redirection de domaine à dossier sur un autre domaine

  RewriteCond% {HTTP_HOST} ^ si-te \ .ru $ [NC]
 RewriteRule ^ (. *) $ Http://www.site.ru/si-te/ [R = 301, L] 

Rediriger à partir de tous les fichiers de domaine, à l'exception du dossier administrateur bitrix

  RewriteRule ^ bitrix / / bitrix / admin / [L, R = 301]
 RewriteRule ^ (. *) $ Http://www.newsite.ru/new/ [L, R = 301] 

Redirigez tous les fichiers d'un dossier dans un fichier spécifié

  RewriteRule ^ dir (. *) $ /new-file.php [L, R = 301] 

Rediriger des fichiers à partir d'un dossier spécifié sauf pour un fichier spécifique

  RewriteRule ^ dir / no-file.html /no-file-new.html [L, R = 301]
 RewriteRule ^ dir (. *) $ /all.php [L, R = 301] 

Changer les pages de l'extension html à l'extension php

  RedirectMatch 301 (. *) \. Html $ http: //www.new-site.ru$1.php 

Spécification du type de la page d'index (php, html, htm et autres)

Spécifie l'ordre dans lequel les types de fichiers d'index sont chargés dans la racine du répertoire.

  DirectoryIndex index.html index.php index.htm index.shtml 

Rediriger depuis la page d'index php vers le dossier lui-même (root)

  RewriteCond% {THE_REQUEST} ^ [AZ] {3,9} \ / index \ .php \ HTTP /
 RewriteRule ^ index \ .php $ http://www.site.ru/ [R = 301, L] 

Rediriger d'un sous-domaine vers un domaine secondaire de deuxième niveau

  RewriteCond% {HTTP_HOST} ^ test.site.ru $ [NC]
 RewriteRule ^ (. *) $ Http: //site.ru% {REQUEST_URI} [R = 301, NC, L, QSA] 

Rediriger pour un fichier donné dans différents répertoires (dossiers)

Le code vous permet de mettre une redirection 301 de tous les dossiers du formulaire http://site.ru/***/uniqe-file.html vers un fichier dans la racine /unique-fichier.html. C'est utile lorsque vous modifiez le site et que vous modifiez les liens.

  RewriteRule [^ abc] /unique-fichier.html /unique-fichier.html [R = 301, L] 

Si vous voulez créer une copie CNC d'une page dynamique, vous pouvez également l'implémenter en utilisant .htaccess

Le code vous permet de créer une copie de la page avec l'adresse relative /studio/news/detail.php?ID=230354&PAGEN_2=11 at / testovyi / test /.

  RewriteRule ^ testovyi / test /? $ /studio/news/detail.php?ID=230354&PAGEN_2=11 [NC, L] 

Spécification du chemin d'accès au fichier d'erreur 404 à l'aide de .htaccess

Attention, il est important que le code de réponse du serveur pour l'erreur 404 soit exactement 404. Le chemin d'accès au fichier est indiqué par la ligne suivante:

  ErrorDocument 404 /404-for-me.php 

Redirections sur le serveur Apache

Внимание Pour les sites qui n'utilisent pas le serveur Apache, des redirections 301 similaires sont facilement configurées en utilisant PHP.

  <? php
 header ("HTTP / 1.1 301 déplacé définitivement");
 header ("Lieu: http://www.site.ru/dir/");
 sortie ();
 ?> 

Внимание Ajuster de manière optimale toutes les redirections à la page de fin immédiatement (sans redirections intermédiaires, en une seule étape), cela améliore leur perception de la part des moteurs de recherche et des utilisateurs.

Si vous souhaitez configurer une redirection uniquement pour certains USER_AGENT et non pour tous les utilisateurs

  RewriteCond% {HTTP_USER_AGENT} (iPad | ipad | iphone | iPhone | ipod | iPod | android | midp | j2me | symbian | séries | 60 | symbos | windows | mobiles | windows | ce | ppc | smartphone | blackberry | mtk | bada | windows \ phone) [NC]
 RewriteRule (. *) Http://mobile.site.ru/ [L, R = 301] 

Si vous souhaitez configurer une redirection pour tous les robots de recherche (voir la liste de leurs USER_AGENT'ov)

  RewriteCond% {HTTP_USER_AGENT}! (Accouna | ia_archiver | antabot | demander \ jeeves | baidu | dcpbot | eltaindexer | feedfetcher | gamespy | gigabot | googlebot | gsa-crawler | grub-client | gulper | slurp | mihalisme | msnbot | mondeindexer | ooyyo | pagebull | scooter | w3c_validator | jigsaw | webalta | yahoofeedseeker | yahoo! \ slurp | mmcrawler | yandexbot | yandeximages | yandexvideo | yandexmedia | yandexblogs | yandexaddurl | yandexfavicons | yandexdirect | yandexmetrika | yandexcatalog | yandexnews | yandeximageresizer) [NC]
 RewriteRule (. *) Http://no-search.site.ru/ [L, R = 301] 

Quelques exemples simples

  Expédition à partir de www.site.ru/component/content/?view=featured à www.site.ru/
 RewriteCond% {QUERY_STRING} ^ view = en vedette $ [NC]
 RewriteRule ^ composant / contenu /? $ /?  [R = 301, L] 
  Expédition de www.site.ru/index.php?idc=4&marea=6 à www.site.ru/
 RewriteCond% {QUERY_STRING} ^ idc = 4 & marea = 6 $ [NC]
 RewriteRule ^ index \ .php $ /?  [R = 301, L] 

Supprimer tous les paramètres GET après le point d'interrogation (?)

  RewriteRule (. *) $ 1?  [R = 301, L]
 Positionnement après: RewriteBase / 

La page principale de site.ru est toujours pleine son double à site.ru/index.php

  Rediriger 301 /index.php http://site.ru/ 

Ou

  RewriteCond% {THE_REQUEST} ^ [AZ] {3,9} \ / index \ .php \ HTTP /
 RewriteRule ^ index \ .php $ http://site.ru/ [R = 301, L] 

Si votre site a plusieurs noms, mais que vous souhaitez que les utilisateurs voient toujours le nom du site principal dans la barre d'adresse, utilisez les lignes suivantes immédiatement après l'opération RewriteEngine:

  RewriteCond% {HTTP_HOST}! ^ Site.ru $
 RewriteRule ^ (. *) Http://site.ru/$1 [R = 301, L] 

301 rediriger vers la fin .html (pour ceux qui ont ce suffixe inclus), rediriger depuis site.ru/article et site.ru/article/ vers site.ru/article.html

  RewriteCond% {REQUEST_URI} (. * / [^ /.] +) ($ | \?)
 RewriteRule. *% 1.html [R = 301, L]
 RewriteRule ^ (. *) / $ /$1.html [R = 301, L] 

Ou

  REDIRECTMATCH 301 (. * / [^ /.] +) ($ | \?) $ Http: //site.ru$1.html 

Rediriger avec .html sans .html, c'est-à-dire. avec site.ru/article.html sur site.ru/article (pour ceux qui ont d'abord inclus .html, puis ont décidé de s'en débarrasser)

  RewriteBase /
 RewriteRule (. *) \. Html $ $ 1 [R = 301, L] 

Ou

  REDIRECTMATCH 301 (. *) \. Html $ http: //site.ru$1 

Rediriger des pages avec des paramètres, par exemple, depuis site.ru/blog?limitstart=0 sur site.ru/blog

  RewriteCond% {QUERY_STRING} ^ limitstart = 0
 RewriteRule ^ blog http://site.ru/blog?  [R = 301, L] 

Que toutes les pages de l'ancienne section sont redirigées vers les mêmes pages que la nouvelle section, par exemple site.ru/blog/raznoe/article sur site.ru/blog/article

  RewriteRule ^ blog / raznoe /(.*)$ http://site.ru/blog/$1 [R = permanent, L] 

Redirection 301 à partir de l'adresse sans barre oblique sur la barre oblique, c'est-à-dire depuis site.ru/article sur site.ru/article/

  RewriteCond% {REQUEST_URI} (. * / [^ /.] +) ($ | \?)
 RewriteRule. *% 1 / [R = 301, L] 

Rediriger avec une barre oblique sans fin, c'est-à-dire de site.ru/article/ sur site.ru/article

  RewriteRule ^ (. *) / $ / $ 1 [R = 301, L] 

Une autre option est de savoir comment se débarrasser de la barre oblique à la fin

  RewriteCond% {REQUEST_FILENAME}! -d
 RewriteRule ^ (. +) / $ / $ 1 [R = 301, L] 

Possibilité de se débarrasser des barres obliques pour les pages avec des paramètres, par exemple des pages avec pagination site.ru/categoriya?start=5/

  RewriteCond% {QUERY_STRING} ^ début = (\ d +) /
 RewriteRule ^ (. *) / $ 1? Start =% 1 [R = 301, L] 

D'abord oublié d'inclure le référencement dans les paramètres globaux, puis inclus, en conséquence - dans l'index beaucoup de documents avec / index.php dans l'adresse.

Par le même principe, vous pouvez vous débarrasser de toute imbrication, par exemple rediriger avec site.ru/catalog sur site.ru/catalog (/ ru / est supprimé).

  RewriteRule ^ index.php /(.*)$ http://mysite.ru/$1 [R = permanent, L] 

Refuser l'accès aux bad bots

  SetEnvIfNoCase User-Agent "^ Baiduspider" bad_bot
 SetEnvIfNoCase Utilisateur-Agent "^ MSNBot" bad_bot
 SetEnvIfNoCase User-Agent "^ Baiduspider" bad_bot
 SetEnvIfNoCase User-Agent "^ Ezooms" bad_bot
 # continuez la liste vous-même, spécifiez l'agent utilisateur du mauvais agent
 Ordre Autoriser, Refuser
 Permettre à tous
 Refuser d'env = bad_bot 

Ou robots.txt donne, sur le reste 404 (pour l'agent de l'agent - Baiduspider et Ezooms)

  RewriteCond% {HTTP_USER_AGENT} \ b (Baiduspider | Ezooms) \ b [NC]
 RewriteCond% {REQUEST_URI}! ^ / Robots \ .txt [NC]
 RewriteRule. * - [R = 404] 

Diverses autres façons de rediriger

Ci-dessous sont donnés des règles de paramètres différents similaires pour les redirections 301.

Rediriger avec un script (envoyer les en-têtes)

Les requêtes peuvent également être redirigées à l'aide de scripts, en envoyant aux en-têtes les en-têtes nécessaires.

  HTTP / 1.1 301 déplacé définitivement
 Lieu: http://www.newdomain.ru/newdir/newpage.htm 

Redirection JavaScript

C'est là qu'il n'y a pas de limite à la créativité et la possibilité de «s'enliser». Les variantes de redirection JavaScript sont souvent implémentées en utilisant la fonction setTimeout ('function', delay) .

Par exemple, faites automatiquement un clic sur le bouton "Envoyer" du formulaire "formulaire de recherche" en 0.1 secondes après avoir chargé le code:

  setTimeout ('document.forms ["formulaire de recherche"]. Submit.click ()', 100); 

Vous pouvez accrocher n'importe quelle action sur le bouton "Envoyer", par exemple, ouvrez une nouvelle URL dans cette fenêtre. En passant, ces redirections sont plus fréquentes lors de l'arrangement de Dorvey (DorWay) - le navigateur de l'utilisateur sera redirigé vers une autre page, et le robot de recherche qui ne comprend pas JavaScript indexera cette page inaccessible à l'utilisateur. Sur cela, le Dorveyschiki place le texte, bourré de mots-clés "nécessaires".

Juste rediriger vers une autre page - insérer après le <body> code JavaScript:

  location = "http://www.new.domain.ru"; 

ou

  document.location.href = "http://www.new.domain.ru"; 

ou

  window.location.reload ("http://www.new.domain.ru"); 

ou

  document.location.replace ("http://www.new.domain.ru"); 

Dans ce dernier cas, il ne sera plus possible de revenir à la page qui a effectué la redirection, car L'adresse de la page est supprimée de l'historique (ce qui est souvent requis).

Si vous avez besoin d'un délai dans le temps, vous pouvez organiser location = "http://www.new.domain.ru"; sous la forme d'une fonction et l'insérer dans setTimeout ('function ()', delay_in_miles); .

La façon dont les différents moteurs de recherche peuvent se rapporter à une telle redirection reste sur leur «conscience», donc pour les fins décrites ici, il est préférable de ne pas les utiliser. La plupart des navigateurs effectuent cette redirection comme prévu, tandis que l'utilisateur peut afficher des informations supplémentaires expliquant pourquoi il est déplacé vers une autre adresse.

Comme le transfert d'un PR d'un ancien site (page) vers un nouveau site (pages) peut prendre plusieurs semaines ou plusieurs mois, ne détruisez pas l'ancien nom de domaine, site ou page jusqu'à ce qu'il se produise.

Redirection PHP

  <? php
 header ("HTTP / 1.1 301 déplacé définitivement");
 header ("Emplacement: http://www.newdomain.ru/newdir/newpage.htm");
 sortie ();
 ?> 

Redirection ASP

  <% @ Language = VBScript%>
 <% 
 Response.Status = "301 déplacé définitivement"
 Response.AddHeader "Location", "http://www.new-url.com"
 response.end
 %> 

Redirection ASP.NET

  <script runat = "serveur">
 vide privé Page_Load (expéditeur d'objet, System.EventArgs e)
 {
 Response.Status = "301 déplacé de façon permanente";
 Response.AddHeader ("Location", "http://www.new-url.com");
 }
 </ script> 

ColdFusion redirection

  <.cfheader statuscode = "301" statustext = "Déplacé de façon permanente">
 <.cfheader name = "Location" value = "http://www.new-url.com"> 

JSP (Java) redirection

  <%
 response.setStatus (301);
 response.setHeader ("Emplacement", "http://www.new-url.com/");
 response.setHeader ("Connexion", "fermer");
 %> 

CGI PERL

  $ q = nouveau CGI;
 print $ q-> redirect ("http://www.new-url.com/"); 

Ruby sur Rails

  def old_action
 headers ["Status"] = "301 déplacé définitivement"
 redirect_to "http://www.new-url.com/"
 finir

Implémentation d'une redirection dans nginx

  if ($ host = 'www.domaine.com') {
 réécrire ^ (. *) $ http: //domain.com$1 permanent;
 } 

Mémo pour les symboles et les symboles utilisés

La ligne RewriteCond est la condition pour l'exécution de la règle RewriteRule. Si la condition est remplie, la redirection est déclenchée.

Les règles peuvent être spécifiées en utilisant des expressions régulières.

Caractères spéciaux utilisés dans les règles et leurs significations.

  • ^ - caractère spécial du début de la ligne;
  • $ - caractère spécial de la fin de la ligne;
  • !! - caractère spécial de la négation;
  • . - un point remplace tout caractère, mais un seul;
  • () - groupement;
  • \ - "blindage" barre oblique, le caractère suivant après il est considéré comme ordinaire, et non un caractère spécial.

Les modificateurs sont utilisés après les caractères spéciaux normaux ou leurs groupes et permettent d'étendre les capacités des modèles pour le déclenchement des règles.

  • ? - le symbole est répété 0 ou 1 fois;
  • + - se répète de 1 à 65536 fois;
  • * - Répète de 0 à 65536 fois.

Drapeaux, spécifiez supplémentaires. options pour la règle utilisée. Liste entre crochets séparés par une virgule, disons [NC] ou [R = 301, L].

  • NC - l'indicateur NoCase, qui désactive le contrôle de cas lorsque la règle est déclenchée.
  • R - le drapeau de redirection, produit un processus pour arrêter de changer l'URL et renvoie le résultat. La valeur la plus courante est R = 301, mais d'autres sont possibles pour les redirections temporaires (302, MOVED TEMPORARY).
  • L - le dernier drapeau, arrête la formation de l'URL et la ligne est considérée comme définitive.

Syntaxe pour les expressions régulières

. - Le point remplace un caractère arbitraire.

[abc] - indique une liste de caractères correspondant aux lettres a, b ou c.

[^ abc] - une liste de caractères qui ne sont pas dans la plage spécifiée. Correspond à n'importe quel caractère sauf a, b ou c.

* - signifie que le caractère précédent peut être répété (0 fois ou plus).

[abc] * - la commande trouvera des caractères consécutifs d'un ensemble donné.

[^ abc] * - exactement le contraire.

. * - remplace absolument tout jeu de caractères. ". *" - trouvera toutes les sous-chaînes entre les guillemets.

^ - le début de la ligne (s'il est utilisé au début de l'expression).

$ Indique la fin de la ligne.

\ w est une lettre, un nombre ou un trait de soulignement _.

\ d - remplace n'importe quel chiffre.

\ D - se substitue à n'importe quel caractère, mais pas à un chiffre.

[0-9] - remplace n'importe quel chiffre.

[az] est une lettre de a à z (tout le jeu de caractères latins) en minuscules.

[AZ] - n'importe quelle lettre de A à Z dans le registre UPPER.

[a-zA-Z] est n'importe quelle lettre de a à Z dans n'importe quel registre.

[aZ] est le même.

Tout à propos de la redirection

Avertissement: Les matériaux pour cet article proviennent des vastes étendues d'Internet (RUnet et BOURGEONET) et de l'expérience personnelle. Certains points semblent controversés et sont actuellement testés dans la pratique, de sorte que l'information de l'article sera complétée et affinée.
** En relation avec le nombre croissant de messages concernant Google 302 Pagejacking , utilisez la redirection 301, et non 302 - cette rubrique est toujours en cours de développement.

D'où vient ce www?

Sur Internet, vous pouvez trouver beaucoup de recommandations comment "unir" domain.ru et www.domain.ru. Mais à part comment le faire, il serait utile de comprendre un peu aussi pourquoi. Cela pourrait aider à choisir la solution appropriée à partir de la variété proposée.

Tout d'abord, il est important de comprendre que www.domain.ru est techniquement le même que sub.domain.ru , bien que cet état de fait existe pour une raison complètement différente.

Il y a dix ou douze ans, le World Wide Web n'était qu'une petite partie d'Internet, et le PC le plus rapide était basé sur 386 jetons. Ils n'étaient pas très rapides et ne pouvaient pas gérer la majeure partie de la charge, il était donc nécessaire de mettre différentes "parties" d'Internet sur des machines séparées.

Par exemple, le serveur Apache était hébergé sur un ordinateur, le serveur de messagerie sur l'autre et le serveur FTP sur un autre. Chacun des ordinateurs a répondu à une adresse IP différente, mais au même nom de domaine. À l'intérieur de ce nom de domaine, les ordinateurs se différencient par le service qu'ils fournissent (ce qu'on appelait alors le «nom de la machine»). Ainsi, les noms des serveurs sur Internet ont commencé avec le «nom de la machine» pour le service fourni: www.domain.ru , mail.domain.ru et ftp.domain.ru . ("Anciens" de l'Internet, se rappellent probablement aussi un tel service archaïque, comme gopher.domain.ru , dans les options IE il est resté encore).

Bien sûr, les ordinateurs d'aujourd'hui sont beaucoup plus puissants, et nous pouvons mettre toutes les différentes parties de nos services Internet dans la même "boîte" (le principe de "deux en un" a été appliqué bien avant l'apparition massive des "pellicules" en Russie :) .

En effet, nous installons souvent plusieurs centaines de domaines, chacun avec son propre ensemble de services (http, ftp, mail ...), sur le même serveur. Par conséquent, à l'heure actuelle, le préfixe www est "antiquités" et peut être ignoré. Le problème est que de nombreux logiciels et de grands répertoires (par exemple, Yahoo) remplacent automatiquement www.domain.ru , même si vous tapez domain.com , plus à cela nous avons plusieurs milliards de personnes qui impriment automatiquement www avant tout nom domaine.

Cette excursion dans l'histoire, au moins pour moi, semble intéressante, mais la seule chose importante est que techniquement www.domain.ru - tout comme sub.domain.ru - sont considérés comme des objets complètement différents concernant domain.ru , mais pour les raisons indiquées ci-dessus, habituellement www.domain.ru et domain.ru devraient normalement montrer la même page, contrairement à sub.domain.ru .

L'utilisateur (Surfer) ou le moteur de recherche (spider), en demandant la page, recevra le même code de réponse 200 OK et ne pourra pas différencier les domaines de www et sans.

Création d'un alias pour www

Si quelqu'un crie "Yuri!" dans une pièce bondée, il va probablement attirer mon attention. Si quelqu'un crie "Savilov!" dans la même pièce, je vais répondre à cela aussi. Parce que ces deux noms, bien que complètement différents, désignent généralement la même personne. En simplifiant un peu, on peut dire que "Yuri" est essentiellement un pseudonyme (alias) pour "Savile". Si quelqu'un dans cette pièce s'approche et m'appelle comme "Oleg", je vais probablement regarder autour de moi, trouver "Oleg", et lui montrer que c'est ce que quelqu'un cherche (si ce quelqu'un, pas si jolie personne, donc je peux mentir :) . "Yuri" et "Oleg" sont deux noms différents qui pointent vers deux personnes différentes, donc je dois rediriger la demande de la personne vers l'endroit où elle répondra en fonction de sa demande. Sur 99,9% de toutes les configurations de serveur, domain.ru et www.domain.ru indiquent exactement le même espace disque. Tout le monde est juste un alias pour un autre. L'utilisation de la redirection pour indiquer le même endroit sur le disque a la même signification que lorsque quelqu'un m'appelle "Yuri" et je réponds: "Non, vous avez besoin de Savilov, c'est moi."

Alias et Redirect ne sont pas les mêmes, bien qu'il soit souvent possible de les remplacer par un autre. La création d'un alias est généralement réalisée à deux niveaux. Au niveau du système de noms de domaine (DNS), nous devrions toujours créer une entrée pour tout le monde, généralement un CNAME pour tout le monde, ou peut-être un CNAME pour le primaire et une entrée pour le secondaire. Si le domaine en question est sur une adresse IP statique, c'est tout ce que nous devons faire pour créer un pseudo. La plupart d'entre nous, cependant, partagent une adresse IP avec d'autres domaines, nous devons donc aller au-delà du niveau du système de noms de domaine (DNS) au niveau du serveur réseau pour compléter la configuration des alias. Utiliser Apache, par exemple, pour créer un point d'entrée dans le fichier de configuration hpptd.conf

 ServerName domain.ru
 DocumentRoot / home / domaine / www
 ServerAlias ​​www.domain.ru

Naturellement, vous devez d'abord associer une version www à une version www via un enregistrement dans le serveur DNS comme:

Pour un domaine de premier niveau:

  EN 192.xxx.xxx.xxx
 www EN 192.xxx.xxx.xxx 

Pour les informations de sous-domaine dans le domaine de premier niveau:

  info IN A 192.xxx.xxx.xxx
 www.info CNAME info 

C'est tout ce qui doit être fait. Surfer ou Spider, aller soit à domain.com ou à www.domain.ru obtiendra exactement les mêmes pages. Notre problème, cependant, est que l'URL demandée ne change pas, et la page demandée répondra avec 200 OK, indépendamment du fait que nous accédions au domaine avec ou sans www . Si pour Surfer cela est généralement indifférent, alors cela ne peut pas être dit par rapport au serveur de recherche (Spider), qui devrait, au moins initialement, traiter à la fois domain.com et www.domain.ru comme des objets séparés, même avec que nous savons qu'ils sont des pseudonymes. Google - le premier serveur de recherche, qui a commencé à appliquer des filtres doubles complexes et la logique nécessaire pour éventuellement "fusionner" domain.ru et www.domain.ru en un seul objet. Malheureusement, il y a un peu d'accent dans cette phrase sur le mot «finalement». Si vous utilisez les alias du système DNS (Domain Name System) ou ServerAlias, Google reconnaîtra finalement domain.com et www.domain.com comme un objet unique et n'affichera qu'un seul site dans le SERP. Malheureusement, cela prend habituellement plusieurs mois, et si vous changez fréquemment le contenu du site, alors comme Spider indexe domain.ru/page.htm et www.domain.ru/page.htm à des moments différents - il recevra un contenu différent des pages de www et sans). Alors ces quelques mois peuvent s'étirer pendant un an ou plus.

Pourquoi est-il nécessaire de "s'unir" domain.ru et www.domain.ru?

Beaucoup de sites "sérieux" utilisent uniquement le domaine avec le préfixe www (par exemple, la plupart des sites avec PR 10. Si vous essayez de contacter w3.org ou adobe.com, vous verrez que votre navigateur sera immédiatement redirigé vers le site avec www . pas seulement un alias, parce que l'emplacement de votre navigation est réellement changé en un nouveau domaine avec www Je crois que Google traite normalement ceci, non seulement parce que les sites «sérieux» le font, mais Google le fait (si vous ne le croyez pas, tapez google.com dans le navigateur.) Fait intéressant, la plupart des "graves" sa ytov utilise Redirect 302. Seul un petit nombre, comme w3.org, renvoie un code d'état 301. Apparemment, Google traite les redirections 301 et 302 de manière égale.

La seule raison pour laquelle Google estime que le site devrait être avec le préfixe www : vous pouvez comparer requête de recherche Google "museau" site narod.ru - la différence sera palpable - sans le préfixe www, Google inclura dans la sortie de tous les sous-domaines. Mais, puisqu'il existe des précédents, lorsqu'un site sans www a un PR supérieur à un site sans www, alors Google ne discrimine pas tout dans tout.

Par conséquent, au lieu de s'appuyer sur des alias et des filtres de moteurs de recherche (Spiders), quelqu'un a eu une brillante idée de rediriger un alias vers un autre alias, qui se redirige essentiellement vers lui-même. C'est une de ces choses qui est fait essentiellement parce que les moteurs de recherche existent et devraient, par conséquent, aider à éviter la division des backlinks. Cependant, il peut y avoir d'autres raisons qui nécessitent une redirection obligatoire: puisque techniquement http://mysite.ru/ et http://www.mysite.ru/ sont des sites VARIOUS , les sessions PHP ne peuvent pas être transférées de l'une à l'autre. C'est une autre raison pour réécrire l'URL dans le navigateur en la redirigeant vers l'alias, surtout si vous n'avez qu'un seul certificat SSL pour le domaine www.mysite.ru ...

Options de redirection technique

Essayons maintenant de répondre à la question de savoir pourquoi les recommandations de redirection suggèrent souvent mod_rewrite et RedirectMatch dans le fichier .htaccess (qui nécessitent certaines ressources de la machine pour les exécuter), et moins souvent une solution plus simple. Pourquoi ne pouvons-nous pas éliminer toutes les expressions régulières complexes et simplement ajouter la ligne "Redirect 301 / http://www.domain.com" (pour la version de hpptd.conf ci-dessus) à notre .htaccess ? Puisque domain.com et www.domain.ru sont des alias et pointent vers le même répertoire, toutes les directives .htaccess dans ce répertoire seront appliquées aux DEUX domaines. Simple Forwarding, sur certaines plateformes de serveurs conduira dans un «cercle vicieux» et, en dernière analyse, s'effondrera. Essayons un peu de changer la configuration du serveur:

 ServerName domain.ru
 DocumentRoot / home / domaine / www
 ServerName www.domain.ru
 DocumentRoot / home / wwwdomain / www

Remarque: dans cette configuration, domain.ru et www.domain.ru pointent vers des dossiers différents sur le serveur et donc pas d'alias. Nous pouvons maintenant placer le fichier .htaccess dans le dossier / home / wwwdomain / www , sans affecter quoi que ce soit dans le dossier / home / domain / www et utiliser la commande Redirect plus simple pour atteindre l'objectif. Le problème est résolu, mais, malheureusement, nous gaspillons un peu d'espace disque, donc vous ne voyez pas souvent cette configuration. Cependant, cette configuration vous donne une autre option:

 ServerName domain.ru
 DocumentRoot / home / domaine / www
 ServerName www.domain.ru
 Redirection 301 / http://domain.ru/

Nous configurons toujours domain.ru et www.domain.ru en tant qu'objets distincts (pas d'alias), mais au lieu de définir DocumentRoot pour le second objet, nous insérons une simple redirection . Nous évitons les contradictions d'essayer de rediriger un pseudonyme sans le créer. L'inconvénient de cette méthode est qu'elle nécessite plus de travail pour l'administrateur hôte. Il est nécessaire de définir deux blocs d'enregistrements au lieu d'un, mais plus important encore, il est nécessaire de supporter les deux blocs "à l'unisson". L'avantage est que chaque requête de page séparée faite à votre domaine entraîne une opération de lecture pour .htaccess et l'analyse du fichier. Maintenant, ajoutez toutes les expressions régulières qui seront appliquées pour chaque demande de page individuelle, puis multipliez tout cela par 200 à 500 autres domaines vivant sur le serveur.

La redirection placée dans httpd.conf ne nécessite pas de RegExp et, plus important encore, n'est lue et analysée qu'une fois lors du démarrage du serveur Apache. Ceci, à mon avis, est la solution la plus élégante , car Cela évite la création d'alias et minimise la charge sur le serveur.

Reste à clarifier la question: qu'est-ce qui est plus intelligent que Redirect 301 ou 302 ? Comme indiqué ci-dessus, de nombreux sites "sérieux" utilisent tranquillement Redirect 302 pour "rejoindre" le domaine avec www et sans et Google l'accepte tout aussi calmement. Mais pas le fait que le reste des moteurs de recherche fera la même chose. Cependant, RFC n'a pas été annulé: le code "301" signifie que la page a été déplacée de façon permanente - "déplacé en permanence" , le code "302" est temporairement déplacé temporairement , donc l'utilisation du code dépend du but de déplacement de la page. Il faut également comprendre que de nombreux navigateurs, en recevant la réponse "301 - déplacé en permanence" , peuvent automatiquement reconfigurer les signets vers une nouvelle page. De même, pas le fait que, le même Google, sera en temps opportun le transfert de PR à la page 302 redirigé, en le considérant comme "temporaire", jusqu'à ce qu'il "masque" les deux sites.

Rediriger pour divers SE (moteurs de recherche):

En général, la redirection est perçue différemment par différents moteurs de recherche. Si vous souhaitez utiliser une redirection pour "fusionner" une version www d'un site avec une version non-www, vous devez garder à l'esprit les remarques suivantes.

Si sur votre site des liens sont installés à la fois sur www et sur partie comme sur www, alors vous êtes probablement intéressé à "combiner" le poids des liens aux deux versions du site en termes de tIC / PR et de classement de référence.

Rediriger pour Yandex

Le fait est que Yandex unit les liens pour les sites qu'il considère comme des miroirs, et une redirection avec site.ru sur www.site.ru exclura l'accès de Yandex à site.ru et, par conséquent, il ne sera pas considéré comme un miroir avec toutes les conséquences qui en découlent. Pour coller Yandex, les deux noms de sites doivent être accessibles (réponse " 200 OK ") et avoir le même contenu.

De plus, vous devez définir le miroir de site principal dans la directive Host dans le fichier Robots.txt, par exemple:

  Utilisateur-agent: *
 
Disallow:

Utilisateur-agent: Yandex
Disallow:
Hôte www.info.data-com.ru

* Il est plus compétent de faire des directives Host dans une section séparée seulement pour le robot Yandex (il y a des informations que Google ignore la section dans laquelle des directives qui lui sont incompréhensibles sont rencontrées, ou cela ne fonctionne pas correctement);
** Selon la norme robots.txt, au moins une directive "Disallow:" doit exister dans chaque section de "User-agent:", donc dans l'exemple il y a une directive "empty" qui n'interdit rien. Pour votre cas, écrivez vos propres limites, le cas échéant.

Rediriger pour Google

Google comprend Redirect, au moins cela peut être jugé à partir d'un article récent de Vanessa Fox sur le blog officiel de Google Sitemaps. Afin de ne pas perdre ce texte intéressant, je le cite complètement:

Inside Google Sitemaps: Plus d'informations sur la modification des noms de domaine
En savoir plus sur la modification des noms de domaine
27/01/2006 09:27:00
Publié par Vanessa Fox, Google Engineering

Récemment, quelqu'un m'a demandé de passer d'un domaine à un autre. Il avait lu que Google recommande d'utiliser une redirection 301
laisser aller Google. Il se demandait si Google suivrait
le 301 au nouveau site, voir qu'il est contenu dans le même contenu que les pages déjà indexées de l'ancien site, et
pense que c'était du contenu en double (et par conséquent ne l'indexe pas). Il se demandait si une redirection 302 serait une meilleure option.

La redirection était exactement ce qu'il devait faire. Une redirection 302 indique à Googlebot que le déménagement est temporaire
et que Google devrait continuer à indexer l'ancien domaine. Une redirection 301 indique à Googlebot que le déménagement est permanent et que
Google devrait commencer à indexer le nouveau domaine à la place. Googlebot ne verra pas le nouveau site comme contenu en double, mais comme déplacé
contenu Et c'est exactement ce que veut quelqu'un qui change de domaine.

Il s'est également demandé combien de temps cela prendrait pour que le nouveau site apparaisse dans les résultats de recherche Google. Il pensait qu'un nouveau site
pourrait prendre plus de temps à indexer que les nouvelles pages d'un site existant. Je lui ai dit que s'il a remarqué qu'il a fallu du temps pour un nouveau
site à indexer, c'est généralement parce qu'il a fallu du temps à Googlebot pour en savoir plus sur le nouveau site. Googlebot apprend à propos de
nouvelles pages à explorer par Sitemaps. Si Google connaît déjà un site,
c'est sur la même page.

Je lui ai dit qu'en utilisant un 301 pour rediriger Googlebot de l'ancien domaine vers le nouveau et en soumettant un sitemap pour
le nouveau domaine, Googlebot pourrait apprendre beaucoup plus rapidement sur le nouveau domaine. Il
il pourrait mettre à jour leurs liens.

Les processus d'exploration et d'indexation sont complètement automatisés, donc je ne pouvais pas lui dire exactement quand le domaine commencerait
apparaissant dans les résultats. Mais laisser savoir à Google sur le site (en utilisant une redirection 301 et un sitemap) est une première importante
étape dans ce processus.

Voici la traduction des parties les plus significatives de ce texte:

Récemment, quelqu'un m'a demandé de passer d'un domaine à un autre. Il a lu que Google recommande d'utiliser Redirect 301 pour informer Googlebot du déménagement, mais il n'était pas sûr de le faire.

Je lui ai dit que Rediriger 301, c'est exactement ce qu'il devrait faire. La redirection 302 indique à Googlebot que le transfert est temporaire et que Google devrait continuer à indexer l'ancien domaine. La redirection 301 indique à Guglebot que le transfert est permanent et que Google devrait commencer à indexer le nouveau domaine. Googlebot rassamtrivat nouveau domaine pas comme contenu en double, mais comme contenu déplacé.
. . .
Guglebot apprend de nouvelles pages pour l'indexation par des liens d'autres pages et de sitemaps.
. . .

Voici un autre extrait du Centre d'aide Google sur le thème Rediriger 301:

Mon URL est modifiée, alors comment puis-je faire en sorte que Google indexe mon nouveau site?

Bien que nous ne puissions pas modifier manuellement votre URL dans nos résultats de recherche, vous pouvez prendre des mesures pour vous assurer de votre transition
est lisse.
Tout d'abord, vous pouvez rediriger les utilisateurs vers votre nouveau site. Si vos anciennes URL redirigent vers votre nouveau site via HTTP 301 (permanent)
redirections, notre robot d'exploration découvrira les nouvelles URL.
. . .
Les listes Google sont basées sur notre capacité à vous trouver à partir de liens sur d'autres sites. Pour préserver votre rang, vous aurez envie
pour dire aux autres qui vous lient de votre changement d'adresse. Une façon de trouver un échantillon de sites liés au vôtre est de
effectuer une recherche de lien.

Voici la traduction de ce fragment: -

"Bien que nous ne puissions pas modifier manuellement votre URL dans nos résultats de recherche, vous pouvez prendre des mesures pour faciliter la transition.Vous pouvez d'abord rediriger les utilisateurs vers votre nouveau domaine.Si vos anciennes URL sont redirigées vers votre nouveau domaine , en utilisant HTTP 301, notre araignée découvrira de nouvelles URL ";

"Les listes de problèmes de Google sont en partie basées sur la possibilité de trouver le site à partir de liens provenant d'autres sites. Pour garder votre note, vous voulez dire à ceux qui vous réfèrent de changer votre adresse."

Et, enfin, une autre pièce importante du "Centre d'aide Google" sur ce sujet:

Pourquoi mon site a-t-il deux listes différentes dans Google: http://site.com et http://www.site.com?

Si votre site apparaît sous deux listes différentes dans nos résultats de recherche, nous vous suggérons de consolider ces listes afin que nous puissions
déterminer plus précisément le PageRank de votre site. La façon la plus simple de le faire est de rediriger votre URL http vers votre URL www en utilisant
une redirection 301. Cela devrait résoudre la situation après que notre robot d'exploration a découvert le changement.
. . .
Veuillez noter: en utilisant un fichier robots.txt et notre système de suppression automatique d'URL pour supprimer seulement la version http ou www de votre
le site ne fonctionnera pas. Cela supprimera les deux versions pendant 180 jours et nous ne pourrons pas ajouter manuellement votre site à notre index.

d'où il suit que Google doit fusionner les sites PR dans une redirection 301.

Notez la note sur le dernier fragment. Vous ne pouvez pas supprimer séparément une version non-www ou une version-www de l'index Google. Les deux versions seront supprimées immédiatement pendant 180 jours.

Postface

Pour vérifier le collage du site par Yandex et la "fusion" des TIC, une autre méthode a été appliquée (elle a été lancée sur ce site depuis mars 2006). Le site répond au nom avec www et sans www. Les pages du site vérifient le HTTP_USER_AGENT demandant la page, et s'il s'agit d'un robot Yandex, alors les deux réponses au nom du site (avec ou sans www) reçoivent la réponse "200 OK" et la page elle-même. Pour tous les autres, le site est uniquement disponible sous www.info.data-com.ru, lorsque vous accédez à info.data-com.ru, Redirect 301 se trouve sur www.info.data-com.ru. La même technologie a construit une méthode de dissimulation - quand les moteurs de recherche montrent une page de contenu, et les utilisateurs - une autre. Cloaking est puni par les moteurs de recherche en excluant le site de leur index et par conséquent - de l'émission.

Pour vérifier l'association de Google PR par Redirect 301, cela a été installé sur ce site depuis Février 2006, et si RP www.info.data-com.ru et info.data-com.ru sont alignés - ce fait peut être considéré comme confirmé. (liens vers www.info.data-com.ru et info.data-com.ru sont environ 50 à 50).

** Si vous décidez d'utiliser une redirection pour votre site - faites la redirection 301, et non 302. Au moins jusqu'à ce que la situation avec Google 302 Pagejacking devient clair - cet article est encore en développement.