WordPress-ის 301 რედირექტები და პერმალინკის შეცვლა

თუ WordPress-ის პერმალინკების სტრუქტურას შეცვლი, ყველა ძველი URL შეწყვეტს მუშაობას, სანამ ვინმე მას 301 რედირექტით ახალ მისამართზე არ გადაიყვანს. ზოგადად WordPress ამას თავისით არ გააკეთებს: ის მხოლოდ იმას გადაამისამართებს, რასაც თვითონ გამოიანგარიშებს, მაგალითად შეცვლილ slug-ს ან ?p=123 ტიპის მისამართს, დანარჩენზე კი 404-ს აბრუნებს. უსაფრთხო თანმიმდევრობა მოკლეა. ამოიღე მიმდინარე URL-ების სია, შეცვალე სტრუქტურა, დაამატე ერთი წესი, რომელიც ძველ შაბლონს ახალზე გადაიყვანს, შეამოწმე curl -I-ით და მხოლოდ ამის შემდეგ ენდე. სტატიის დანარჩენი ნაწილი ეხება სტატუს კოდებს, Apache-ის სტილის .htaccess-ის და nginx-ის წესებს და რამდენიმე მიზეზს, რომლებზეც თითქმის ყველა რედირექტის ციკლი მოდის.

რა არის 301 და როდის გამოვიყენოთ სხვა#

რედირექტი ჩვეულებრივი HTTP პასუხია სტატუს კოდით და Location ჰედერით. ბრაუზერი ან საძიებო რობოტი ჰედერს კითხულობს და ახალ მისამართს ითხოვს. სტატუს კოდი ეუბნება, რამდენ ხანს დაიმახსოვროს პასუხი.

პერმალინკებისთვის სწორი პასუხი 301-ია. ის საძიებო სისტემებს ეუბნება, რომ ძველი URL-ის წონა ახალზე გადაიტანონ, ბრაუზერები კი მას ქეშში ინახავენ. სწორედ ქეშია საშიში ნაწილი: არასწორი 301 მნახველების ბრაუზერებში რჩება მას შემდეგაც, რაც სერვერს გამოასწორებ, ამ ბრაუზერებამდე კი ვერ მიხვალ. ამიტომ ყოველი ახალი წესი ჯერ 302-ად დაწერე, შეამოწმე და ერთი სიტყვა 301-ად შეცვალე, როცა სწორია. სტატია www-სა და მთავარ დომენს შორის გადამისამართებაზე იგივეს ამბობს ჰოსტის რედირექტზე და ქვემოთ ყველაფერი იმას ვარაუდობს, რომ იცი, როგორ უნდა მუშაობდეს ეს ფენა.

301 ასევე ძველი მისამართის მუდმივი იჯარა არ არის. წესი შეინახე მინიმუმ ერთი წელი, უკეთესად კი იმდენ ხანს, რამდენსაც საიტი არსებობს. ძველი ბმულები სხვის საიტებზე და სხვის სანიშნეებში არ ვადაგასდება მაშინ, როცა შენი საძიებო ინდექსი განახლდება.

რას გადაამისამართებს WordPress თავისით და რას არა#

WordPress-ს ორი ჩაშენებული ქცევა აქვს, რომლებიც რედირექტს ჰგავს, და უნდა იცოდე, სად მთავრდება.

პირველი კანონიკური გადამისამართებაა (redirect_canonical()). თუ ვინმე /?p=123-ს ითხოვს და 123-ე ჩანაწერს ლამაზი პერმალინკი აქვს, WordPress მას 301-ით ლამაზზე გაგზავნის. ის ასევე ამატებს ან აშორებს ბოლო დახრილ ხაზს შენი სტრუქტურის მიხედვით და home პარამეტრში მითითებულ ჰოსტზე გადაამისამართებს. ამიტომ აქვს მნიშვნელობა, რომელი ფენაა რედირექტების პატრონი, და ამიტომ არის ორი ფენის ჭიდილი ციკლების ჩვეულებრივი დასაწყისი.

მეორე ძველი slug-ების მექანიზმია. როცა რედაქტორში ჩანაწერის slug-ს ცვლი, WordPress წინა slug-ს ჩანაწერის მეტამონაცემებში (_wp_old_slug) ინახავს და მისგან გადაამისამართებს. მას ასევე აქვს 404-ის სარეზერვო ვარიანტი, რომელიც ჩანაწერს URL-ის ბოლო ნაწილით ხვდება, ამიტომ /2023/04/my-post/ ზოგჯერ შენი წესის გარეშეც /my-post/-ზე მოხვდება.

მიგრაცია ამაზე ნუ დააფუძნებ. გამოცნობა მუშაობს მხოლოდ უნიკალური slug-ის დროს, მხოლოდ ჩანაწერებისთვის და მხოლოდ მაშინ, როცა WordPress-ი გადაწყვეტს ცდას. ის არაფერს აკეთებს კატეგორიის ბაზისთვის, გვერდების იერარქიის ცვლილებებისთვის, მორგებული ჩანაწერის ტიპებისთვის, მიმაგრებების მისამართებისთვის და იქ, სადაც თვით slug შეიცვალა. აღიქვი ის ბონუსად ერთი დავიწყებული URL-ისთვის და არა გეგმად.

სანამ პერმალინკის პარამეტრს შეეხები#

პერმალინკები არის Settings-ში, შემდეგ Permalinks-ში. არჩევანია Plain (/?p=123), Day and name, Month and name, Numeric, Post name და Custom Structure. ყველა აგებულია ისეთი ტეგებისგან, როგორიცაა %year%, %monthnum%, %postname% და %category%. Post name (/%postname%/) არის ის, რასაც უმეტესი საიტი ბოლოს აირჩევს: მოკლე, წასაკითხი და თარიღების გარეშე, რომლებიც კარგ სტატიას ძველად აჩენს.

პარამეტრის შეცვლა მყისიერია და მთელ საიტზე მოქმედებს. ძველ URL-ებს სახელს არ ცვლის, უბრალოდ აღარ აგენერირებს, ამიტომ წინასწარ მოემზადე.

1. გააკეთე backup. ფაილებიც და მონაცემთა ბაზაც. თვით პერმალინკის შეცვლა ცოტა რამეს ეხება, მაგრამ შემდეგ .htaccess-ს ან სერვერის კონფიგურაციას შეცვლი, ასლის სტანდარტს კი სტატია backup-ზე, რომელიც ნამდვილად აღდგება განსაზღვრავს.
2. ჩაიწერე ყველა მიმდინარე URL. ამ სიას ცვლილების შემდეგ შეამოწმებ. WP-CLI-ით:

$ wp post list --post_type=post,page --post_status=publish \    --fields=ID,post_name,url --format=csv > old-urls.csv$ wc -l old-urls.csv

1. შეამოწმე მიმდინარე სტრუქტურა, რომ ზუსტად იცოდე, რას ანაცვლებ:

$ wp option get permalink_structure/%year%/%monthnum%/%postname%/

1. გაარკვიე, რომელი საძიებო შედეგებია მნიშვნელოვანი. გახსენი Search Console ან შენი ანალიტიკა და ჩაინიშნე ათიდან ოცამდე URL, რომლებიც ტრაფიკს მოაქვს. სწორედ ისინი შეამოწმე ხელით.

თუ shell-ზე წვდომა არ გაქვს, რაც პანელიან ჰოსტინგზე ჩვეულებრივი სიტუაციაა, WP-CLI გამოტოვე და სია plugin-ით ამოიღე ან საიტის რუკიდან გადაიწერე. პრინციპი იგივეა: ძველი სია ფაილში გქონდეს ცვლილებამდე, რადგან მერე WordPress-ს ვეღარ ჰკითხავ, რა იყო ძველი URL-ები.

სტრუქტურის შეცვლა#

ცვლილება შეასრულე Settings-ში, შემდეგ Permalinks-ში, აირჩიე ახალი სტრუქტურა და შეინახე. WP-CLI-ში იგივე ასე გამოიყურება:

$ wp rewrite structure '/%postname%/'$ wp rewrite flush$ wp rewrite list | head

გვერდის შენახვა გადაწერის წესებს თავიდან აგენერირებს. სერვერზე, რომელიც .htaccess-ს კითხულობს, ეს ამ ფაილში WordPress-ის ბლოკსაც გადაწერს, თუ ფაილი ჩაწერადია. თუ არა, WordPress ბლოკს გაჩვენებს, რომ თავად ჩასვა.

ერთი გაფრთხილება: თუ მორგებული ჩანაწერის ტიპი ან WooCommerce მაღაზია გაქვს, მათი ბაზის პარამეტრები ცალკე შეამოწმე. მათ საკუთარი slug-ები აქვთ და შენმა საერთო წესმა ისინი არ უნდა შთანთქას.

წესი, რომელიც ძველს ახალს უკავშირებს#

მიზანი ერთი წესია, რომელიც იმ ნაწილს იჭერს, რომლის შენახვაც გინდა, და დანარჩენს აგდებს. /2024/05/my-post/-დან /my-post/-ზე გადასასვლელად შაბლონი ასე იკითხება: „ოთხი ციფრი, დახრილი ხაზი, ორი ციფრი, დახრილი ხაზი, slug“.

Apache-ის სტილის სერვერებზე რედირექტი .htaccess-ში იწერება # BEGIN WordPress ბლოკის ზემოთ, რადგან WordPress-ის საკუთარი წესი ყველაფერს, რაც ფაილი არ არის, index.php-ზე აგზავნის და სხვაგვარად ის პირველი მივიდოდა:

<IfModule mod_rewrite.c>RewriteEngine OnRewriteRule ^[0-9]{4}/[0-9]{2}/([^/]+)/?$ /$1/ [R=302,L]</IfModule># BEGIN WordPress<IfModule mod_rewrite.c>RewriteEngine OnRewriteBase /RewriteRule ^index\.php$ - [L]RewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteRule . /index.php [L]</IfModule># END WordPress

წამყვანი დახრილი ხაზი შაბლონში განზრახ არ არის: .htaccess-ში წესი გზას დირექტორიის პრეფიქსის გარეშე ხედავს. სერვერის მთავარ კონფიგურაციაში იგივე წესს დასაწყისში ^/ სჭირდება. წესი RewriteRule ფორმით შეინახე. Redirect-ის ან RedirectMatch-ის (ეს Apache-ის სხვა მოდულია) RewriteRule-თან შერევა ერთ ფაილში მოდულების რიგზე დამოკიდებულ შედეგს იძლევა, რაც ადამიანებს აკვირვებს.

nginx-ში იგივე საქმეს location ასრულებს რეგულარული გამოსახულებით. ფიგურული ფრჩხილები შაბლონს ბრჭყალებში ჩასმას მოითხოვს:

location ~ "^/[0-9]{4}/[0-9]{2}/([^/]+)/?$" {    return 302 /$1/;}

ჩასვი ის server ბლოკში, არსებული location /-ის გვერდით, რომელშიც try_files $uri $uri/ /index.php?$args; წერია. რეგულარული location-ები პრეფიქსის უბრალო დამთხვევამდე მოწმდება, ამიტომ ის იმარჯვებს. შემოწმების შემდეგ 302 301-ად შეცვალე; nginx-ში rewrite ... permanent; იგივეს აკეთებს, რასაც return 301, return კი უფრო მარტივი და სასურველი ფორმაა.

არცერთი ეს წესი ჩაწერილი სახით სრული არ არის და ხარვეზების ცოდნა ღირს:

• თარიღის არქივები ჩანაწერები არ არის. /2024/05/-ს slug არ აქვს და არ ემთხვევა, რაც სწორია. მაგრამ /2024/05/feed/-ს ჩანაწერის ფორმა აქვს და /feed/-ზე გადაიგზავნებოდა. დაამატე გამონაკლისი feed-ისთვის, page-ისთვის და შენი საიტის სხვა დაჯავშნილი სიტყვებისთვის, ან ისინი პირველად ჩამოთვალე და დამუშავება გააჩერე.
• მშობლიანი გვერდები. გვერდი /services/hosting/-ზე თარიღის შაბლონს არ ერგება, ამიტომ ეს წესი მას არ ეხება და თუ მხოლოდ ჩანაწერების სტრუქტურას ცვლი, ის კვლავ მუშაობს.
• კატეგორიის ბაზები. /category/news/-ის /news/-ზე გადატანა ცალკე წესია და მასში შეცდომა ადვილია, რადგან გვერდების slug-ებს ეჯახება. სანამ ამას გააკეთებ, კონფლიქტები შეამოწმე.
• მოთხოვნის სტრიქონები. ორივე ზემოთ მოცემული წესი გადამისამართებულ მოთხოვნაზე მოთხოვნის სტრიქონს აგდებს, რაც პერმალინკის გადატანისას თითქმის ყოველთვის სასურველია. თუ გინდა, ?utm_ პარამეტრები გადარჩეს, ეს პირდაპირ თქვი: [R=301,L,QSA] Apache-ში; nginx-ის return მოთხოვნას არ აბამს, სანამ $is_args$args არ დაამატებ.

ბევრი ცალკეული URL: რუკები და Redirection plugin#

შაბლონი მუშაობს, როცა ცვლილება სისტემურია. არ მუშაობს, როცა თვით slug-ები შეიცვალა ან ოცი ძველი სტატია ხუთად გააერთიანე. ამას აშკარა სია სჭირდება, თითო სტრიქონზე ერთი ძველი და ერთი ახალი გზა.

რამდენიმე ათეულისთვის უბრალო წესები საკმარისია. ასობით მისამართისთვის nginx-ში სუფთა პასუხი map-ია: ის http ბლოკში ცხოვრობს და მუდმივ დროში ეძებს.

map $request_uri $moved_to {    default                      "";    /old-hosting-guide/          /guides/hosting/;    /2023/11/vps-vs-shared/      /vps-vs-shared-hosting/;}server {    # inside the existing server block    if ($moved_to) {        return 301 $moved_to;    }}

nginx-ში if შეზღუდულია და ეს ერთ-ერთი იშვიათი უსაფრთხო გამოყენებაა, რადგან მხოლოდ return-ს შეიცავს. Apache-ში არსებობს RewriteMap, მაგრამ ის მხოლოდ სერვერის მთავარ კონფიგურაციაშია დაშვებული და არასდროს .htaccess-ში. გაზიარებული ტიპის ჰოსტინგზე მასზე წვდომა არ გექნება, ამიტომ პრაქტიკული არჩევანია ბევრი RewriteRule სტრიქონი ან plugin.

ყველაზე გავრცელებული plugin Redirection-ია: ის სიას მონაცემთა ბაზაში ინახავს, 404-ებს ჟურნალში წერს, რომ დავიწყებული URL-ები იპოვო, და CSV-ის იმპორტი შეუძლია. ის PHP-ის შიგნით მუშაობს, ამიტომ ყოველი გადამისამართებული მოთხოვნა WordPress-ის სრულ ჩატვირთვად ჯდება, სერვერული წესი კი მიკროწამებში პასუხობს. რამდენიმე ათასი რედირექტისთვის ეს მისაღებია; მაღალი დატვირთვის საიტზე plugin URL-ების საპოვნელად გამოიყენე და შემდეგ წესები სერვერზე გადაიტანე. მასალა WordPress-ის სიჩქარესა და ქეშირებაზე განმარტავს, რატომ არის WordPress-ის სრული ჩატვირთვა ყოველ მოთხოვნაზე ძვირი ნაწილი.

.htaccess თუ nginx: რომელზე ხარ?#

ეს მნიშვნელოვანია, რადგან ისინი სხვადასხვაგვარად მუშაობენ, შენი ჰოსტინგის ვებსერვერი კი არ უნდა ივარაუდო.

• Apache .htaccess-ს კითხულობს ყოველ მოთხოვნაზე, ყველა დირექტორიაში, რომელზეც გზა გადის. ეს ცენტრალურ კონფიგურაციაზე ნელია, მაგრამ წესების შეცვლა გადატვირთვის გარეშე შეიძლება და მათ plugin-საც შეუძლია შეცვლა. მუშაობს მხოლოდ მაშინ, თუ სერვერი ამას იძლევა (AllowOverride), რასაც ჰოსტინგების უმეტესობა აკეთებს.
• LiteSpeed და OpenLiteSpeed .htaccess-საც კითხულობენ, გავრცელებული დირექტივებისთვის თავსებადი სინტაქსით.
• nginx-ს .htaccess არ აქვს. წესები სერვერის კონფიგურაციაში ცხოვრობს და ცვლილებებს reload სჭირდება. ფაილს .htaccess, რომელიც WordPress-ის საქაღალდეშია nginx-ის სერვერზე, არაფერი კითხულობს, და ეს არის კლასიკური მიზეზი ფრაზისა „ჩემი რედირექტი არაფერს აკეთებს“.

გასარკვევად პასუხის ჰედერები ნახე:

$ curl -sI https://example.com/ | grep -i '^server'server: nginx

ეს ჰედერი შეიძლება დაიმალოს ან შეიცვალოს, ამიტომ არარსებული ან ზოგადი მნიშვნელობა პასუხი არ არის. მეორე ნიშანი ფაილ-მენეჯერია: თუ საიტის ძირში არის .htaccess, რომელიც WordPress-მა პერმალინკების შენახვისას გადაწერა, ვიღაც მას კითხულობს. თუ პერმალინკების შენახვა შეტყობინებას გამოიტანს, რომ WordPress-მა .htaccess ვერ განაახლა, ან სერვერი მას უგულებელყოფს, ან ფაილი მხოლოდ წასაკითხია.

RE:NODE-ის პანელი აქ არაფერს გეტყვის და ეს სტატია არ იხვედრებს. შეხედე შენი საიტის რეალურ Server ჰედერს და იმას, რაც შენი ფაილების ძირშია ფაილ-მენეჯერში, და მიჰყევი იმ განყოფილებას, რომელიც ერგება. თუ ვებსერვერის კონფიგურაცია შენ არ გეკუთვნის შესაცვლელად, პასუხია: .htaccess-ის გზა, თუ სერვერი მას კითხულობს; Redirection plugin, თუ არა; და მხარდაჭერის მოთხოვნა, თუ გჭირდება სერვერული წესი, რომლის დაწერაც თავად არ შეგიძლია.

რედირექტების ციკლები: მიზეზები ალბათობის მიხედვით#

ERR_TOO_MANY_REDIRECTS Chrome-ში, „The page isn't redirecting properly“ Firefox-ში. ციკლი ნიშნავს, რომ ორი რამ ვერ თანხმდება, რომელია კანონიკური URL, და თითოეული მნახველს მეორის ვერსიაზე აგზავნის. იპოვე უთანხმოება და ერთი მხარე მოაცილე.

ჯერ ჯაჭვი ნახე, ნუ გამოიცნობ. curl ნაგულისხმევად არაფერს მიჰყვება, ამიტომ უთხარი, რომ მიჰყვეს, და გადახტომების რაოდენობა შეზღუდე:

$ curl -sIL --max-redirs 8 https://example.com/some-post/ \    | grep -i -E '^(HTTP|location)'

Location სტრიქონები თანმიმდევრობით წაიკითხე. ციკლი ორ ერთსა და იმავე მისამართს აჩვენებს, რომლებიც ენაცვლებიან. შემდეგ დანახული ამ მიზეზებს შეადარე.

HTTPS პროქსის უკან. ყველაზე გავრცელებული მიზეზი თანამედროვე ჰოსტინგზე. TLS მთავრდება reverse proxy-ზე, რომელიც ვებსერვერს უბრალო HTTP-ს გადასცემს. წესი ან plugin http://-ს ხედავს, https://-ზე გადაამისამართებს, პროქსი TLS-ს ისევ იცილებს და ციკლი მეორდება. გამოსავალია WordPress-მა ენდოს ჰედერს, რომელსაც პროქსი აყენებს; wp-config.php-ში ეს ასე გამოიყურება და ჩასმა იმ ხაზის ზემოთ უნდა მოხდეს, რომელიც რედაქტირების შეწყვეტას ამბობს:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )    && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {    $_SERVER['HTTPS'] = 'on';}

სანამ ამას დაეყრდნობი, დარწმუნდი, რომ შენი პროქსი ნამდვილად აგზავნის X-Forwarded-Proto-ს; RE:NODE-ზე პროქსის სლოტი აღწერილია როგორც მნახველის მისამართის X-Forwarded-For-ში გადამცემი, ამიტომ პროტოკოლის ჰედერი გადაამოწმე და ნუ ივარაუდებ. სტატია იმაზე, რას აკეთებს reverse proxy, ამ ჰედერებს განმარტავს, ხოლო მასალა HTTPS-სა და Let's Encrypt-ზე გიჩვენებს, სად ზის სერტიფიკატი.

საიტის მისამართი წესს არ ემთხვევა. siteurl და home მონაცემთა ბაზაში http://example.com-ს ამბობენ, სერვერული წესი კი https://www.example.com-ს აიძულებს. WordPress ერთი მიმართულებით გადაამისამართებს, სერვერი მეორით. ნახე, რა არის შენახული:

$ wp option get home$ wp option get siteurl

თუ ადმინ-პანელამდე ვერ მიხვალ, ორივე მნიშვნელობა wp-config.php-ში დააფიქსირე, რომელიც ბაზის მნიშვნელობებს გადაფარავს, სანამ სწორად არ გამოასწორებ:

define( 'WP_HOME',    'https://example.com' );define( 'WP_SITEURL', 'https://example.com' );

ბოლო დახრილი ხაზის ჭიდილი. WordPress ლამაზ ბმულებს ბოლოში დახრილ ხაზს ამატებს. სერვერული წესი ან plugin, რომელიც მას აშორებს, /post/-ს /post-ზე გაგზავნის და WordPress მაშინვე უკან დააბრუნებს. აირჩიე დახრილი ხაზი. WordPress-ის საკუთარი კონვენცია მისი დატოვებაა, ამიტომ წესი, რომელიც მას ჭრის, მოაშორე.

რედირექტის ორი ფენა. უსაფრთხოების plugin-ს, ქეშირების plugin-ს, რედირექტების plugin-ს, ფაილს .htaccess-სა და ჰოსტინგის პროქსის თითოეულს შეუძლია HTTPS-ის ან კანონიკური ჰოსტის იძულება. ცალ-ცალკე ყველა მართალია, ერთად კი ციკლს იძლევიან. გამორთე ისინი სათითაოდ გარედან: გადაარქვი სახელი wp-content/plugins/the-plugin-ს ფაილ-მენეჯერით ან გაუშვი wp plugin deactivate --all და ისევ ჩართე, სანამ ციკლი არ დაბრუნდება.

წესი, რომელიც საკუთარ შედეგს ემთხვევა. ყველაზე მარტივი ციკლი, რომელიც ხელით დაწერილ წესებში გვხვდება: ფხვიერი შაბლონი, მაგალითად ^(.*)$, რომელიც ყველა გზას ოდნავ სხვა გზაზე გადაამისამართებს, საკუთარ შედეგს დაემთხვევა და ისევ გაეშვება. შაბლონები მკაცრად დაამაგრე და დარწმუნდი, რომ გამოსავალი შესასვლელს ვერ დაემთხვევა. ზემოთ მოცემული თარიღის წესისას სამიზნე /my-post/ ციფრებს არ შეიცავს, ამიტომ ისევ ვერ დაემთხვევა.

ქეშირებული რედირექტი. მიზეზის გასწორების შემდეგ ბრაუზერი ქეშირებულ 301-ს ისევ იმეორებს. შეამოწმე პრივატულ ფანჯარაში ან curl-ით, რომელსაც ქეში არ აქვს. თუ რეალური მნახველებისთვის ამოწმებ, გახსოვდეს, რომ საიტის წინ მდგომმა CDN-მა ან გვერდების ქეშმაც შეიძლება რედირექტი შეინახა, ამიტომ გაასუფთავე. ცარიელი გვერდი ან 500 შეცდომა .htaccess-ის შეცვლის შემდეგ სხვა პრობლემაა და მას სტატია WordPress-ის თეთრ ეკრანსა და 500 შეცდომებზე განმარტავს.

ყველა რედირექტის შემოწმება#

შეამოწმე curl -I-ით და არასდროს დაწკაპუნებით, რადგან curl სტატუს კოდს და დანიშნულებას ბრაუზერის ქეშისა და ავტომატური შესწორებების გარეშე აჩვენებს. გაუშვი ის სიაზე, რომელიც ცვლილებამდე შეინახე:

$ while read -r path; do    printf '%s -> ' "$path"    curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' \      "https://example.com$path"  done < old-paths.txt

ყოველი ძველი URL-ისთვის გჭირდება ერთი 301 (ან შემოწმებისას 302) ახალ URL-ზე და შემდეგ 200 დანიშნულების ადგილას. ყველაფერი, რაც ორ გადახტომას აჩვენებს, გასასწორებელია: პირველი რედირექტი მნახველებს URL-ზე აგზავნის, რომელიც თავად გადაამისამართებს, რაც დროს კარგავს და სიგნალს ასუსტებს. ყველაფერი, რაც 404-ს აჩვენებს, URL-ია, რომელიც შენმა წესმა გამოტოვა. ყველაფერი, რაც 301-ს მთავარ გვერდზე აჩვენებს, ზარმაცი წესია, რომელიც ბმულის აზრს კარგავს; ყოველი ძველი გვერდი მის ნამდვილ მემკვიდრესთან გაგზავნე.

როცა გამოტანა სუფთაა, 302 301-ად შეცვალე, საჭიროების შემთხვევაში სერვერი გადატვირთე და სია კიდევ ერთხელ გაუშვი.

შემდეგ: ბმულები, საიტის რუკა და ძიება#

რედირექტები გარედან მოსულ ადამიანებს ემსახურება. ყველაფერმა, რასაც აკონტროლებ, მათზე დაყრდნობა უნდა შეწყვიტოს.

• განაახლე შიდა ბმულები. ჩანაწერები, რომლებიც ერთმანეთს სრული ძველი URL-ებით უკავშირდება, ახლა ყოველ დაწკაპუნებაზე რედირექტს გადიან. ჯერ გადახედვა გააკეთე: wp search-replace 'example.com/2024/05/' 'example.com/' --dry-run, წაიკითხე რაოდენობა და დროშის გარეშე backup-ის შემდეგ გაუშვი. შაბლონური ჩანაცვლება სერიალიზებულ მონაცემებში ყოველთვის WP-CLI-ით გააკეთე და არა უმუშავებელი SQL UPDATE-ით. სტატია WordPress-ის ახალ ჰოსტინგზე გადატანაზე განმარტავს რატომ.
• ხელახლა შექმენი საიტის რუკა, რომ მხოლოდ ახალი URL-ები შეიცავდეს, და Search Console-ში ისევ გააგზავნე.
• თვალი ადევნე 404-ებს. რამდენიმე კვირა ვებსერვერის ჟურნალში ან 404-ის მონიტორში ეძებე გამოტოვებული ძველი URL-ები.
• მოელოდე ვარდნას. საძიებო სისტემებს ასეთი გადატანის დამუშავებას დღეები ან კვირები სჭირდება. დროებითი რყევა, რომელიც წყნარდება, ნორმაა; ვარდნა, რომელიც არ აღდგება, იმ წესის ნიშანია, რომელიც არასწორ ადგილას გადაამისამართებს.

RE:NODE-ზე WordPress-ის საიტს web ხაზზე იგივე ფაილ-მენეჯერი და SFTP აქვს, რაც ნებისმიერ სხვა გეგმას, და ეს საკმარისია .htaccess-ის ან wp-config.php-ის შესაცვლელად და მანამდე ასლის გადასაღებად.

FAQ#

დააზიანებს თუ არა პერმალინკის შეცვლა ჩემს პოზიციებს ძიებაში?

არა, თუ ყოველი ძველი URL ერთი 301-ით პირდაპირ შემცვლელზე პასუხობს. მოელოდე მოკლე რყევას, სანამ რობოტები საიტს თავიდან დაამუშავებენ. პოზიციები იკარგება, როცა ძველი URL-ები 404-ს აბრუნებს, მთავარ გვერდზე მიდის ან რამდენიმე გადახტომას გადის.

პერმალინკის შეცვლისას 301 გამოვიყენო თუ 302?

302 შემოწმებისას, რადგან არასწორი 301 ბრაუზერებში დიდხანს რჩება ქეშში, და შემდეგ 301 საბოლოო წესისთვის. პერმალინკის შეცვლა მუდმივია, ამიტომ საბოლოო მდგომარეობა ყოველთვის 301-ია.

რატომ არაფერს აკეთებს ჩემი რედირექტი .htaccess-ში?

ჩვეულებრივ სამიდან ერთი მიზეზია: სერვერი nginx-ია და .htaccess-ს არ კითხულობს, AllowOverride გამორთულია, ან წესი WordPress-ის ბლოკის ქვემოთაა და არასდროს სრულდება. შეამოწმე Server ჰედერი curl -I-ით და წესი # BEGIN WordPress-ის ზემოთ გადაიტანე.

შეიძლება რედირექტი plugin-ის გარეშე?

დიახ, და სისტემური შაბლონისთვის ასე უნდა გააკეთო. სერვერული წესი PHP-ის გაშვებამდე პასუხობს. plugin-ები აზრიანია, როცა ასობით ცალკეული URL გაქვს ან გინდა 404-ების ჟურნალი, რომელზეც იმუშავებ.

რამდენ ხანს შევინახო რედირექტები?

მინიმუმ ერთი წელი, უკეთესად უვადოდ. ისინი თითქმის არაფერი ღირს, გარე ბმულები და სანიშნეები ძველ URL-ებზე კი არ ქრება, როცა საძიებო სისტემები განახლდება.

რას ნიშნავს ERR_TOO_MANY_REDIRECTS?

ბრაუზერმა მეტი რედირექტი გაიარა, ვიდრე იღებს, ჩვეულებრივ დაახლოებით ოცი, რადგან ორი წესი მნახველს წინ და უკან აგზავნის. გაუშვი curl -sIL --max-redirs 8 ამ URL-ზე, წაიკითხე Location სტრიქონები და უთანხმოების ერთი მხარე მოაცილე.