Mga Redirect Rule sa WordPress htaccess: Tamang Paggawa ng 301

Naglilipat ka ba ng URL at gusto mong panatilihin ng luma ang ranking nito? Kailangan mo ng 301 sa .htaccess, nakalagay sa lugar na hindi buburahin ng WordPress, nakasulat gamit ang tamang directive, at nakaturo sa eksaktong URL na talagang inihahatid ng WordPress. Magkamali ka sa kahit alin sa tatlong ito at ang aabutin mo ay redirect chain, loop, o isang 500 na magla-lock sa iyo palabas ng wp-admin.

Ang desisyon, ang tuntunin sa paglalagay, at ang pagsubok — sa ganitong pagkakasunod.

Aling directive: Redirect, RedirectMatch, o RewriteRule

May dalawang Apache module na sangkot dito at hindi sila magkapalit.

Redirect (mod_alias) — iisang kilalang path patungo sa iisang destinasyon. Ang pinakasimpleng bagay na gumagana:

Redirect 301 /old-page/ https://example.com/new-page/

Dalawang ugali ang dapat mong malaman. Tumutugma ito sa path prefix, hindi sa eksaktong string, kaya nahuhuli rin ng /old-page/ ang /old-page/anything/ at idinudugtong nito ang /anything/ sa destinasyon. At awtomatiko nitong dinadala ang query string.

RedirectMatch (mod_alias) — iisang regex na sumasaklaw sa maraming URL. Ganito mo ililipat ang isang buong seksyon:

RedirectMatch 301 ^/blog/(.*)$ https://example.com/articles/$1

Ang capture group na (.*) ay nagiging $1 sa destinasyon, kaya ang /blog/hello-world/ ay dadaong sa /articles/hello-world/. Pansinin ang unang slash: tumutugma ang mga pattern ng mod_alias sa buong URL path.

RewriteRule (mod_rewrite) — kailangan kapag nakadepende ang redirect sa isang kondisyon: ang hostname, ang protocol, isang query string, isang user agent. Walang anuman sa mod_alias ang makakasubok sa mga iyon.

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

Sa isang per-directory na .htaccess, tinatanggal ang unang slash sa pattern — kaya nga ^(.*)$ dito at ^/blog/ naman sa halimbawa ng mod_alias. Ang paglilito rito ang pinakakaraniwang dahilan kung bakit tahimik na walang ginagawa ang isang na-paste na rule.

Gawing default ang mod_alias. Abutin lang ang RewriteRule kapag kailangan mo ng kondisyon. Mas kaunting regex, mas kaunting paraan para magkamali.

Saan dapat mapunta ang mga rule

Ang mga custom redirect ay nabibilang sa itaas ng linyang # BEGIN WordPress. Hindi sa loob nito.

# --- custom redirects ---
Redirect 301 /old-page/ https://example.com/new-page/
RedirectMatch 301 ^/blog/(.*)$ https://example.com/articles/$1

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Dalawang magkahiwalay na dahilan:

1. Isinusulat muli ng WordPress ang sarili nitong block. Ang pag-save sa Settings → Permalinks ay tumatawag sa flush_rewrite_rules(), na nagtatapon ng lahat ng nasa pagitan ng mga marker at nire-regenerate ito. Ang rule na inilagay mo sa loob ay mawawala sa susunod na may humipo sa screen na iyon — maaaring makalipas ang ilang buwan, na walang makakaugnay sa dalawang pangyayari.
2. Ang pagkakasunod-sunod ang nagpapasya kung sino ang mananalo. Nagtatapos ang WordPress block sa isang catch-all na nagpapadala ng bawat request na hindi file at hindi directory patungo sa index.php. Ang RewriteRule na nakalagay pagkatapos nito ay hindi na tatakbo.

Isang tapat na komplikasyon: ang mod_alias at mod_rewrite ay hindi talaga tumatakbo ayon sa pagkakasunod sa file. Pinoproseso ng Apache ang mod_alias habang isinasalin ang URL at ang per-directory na mod_rewrite ay mamaya pa, sa yugto ng fixup — kaya kayang manalo ng isang linyang Redirect laban sa RewriteRule na nasa itaas nito sa file. Kung mapansin mong kailangan mo ang dalawa sa magkakapatong na path, pumili ng isang module para sa path na iyon at manatili doon. Hindi sulit ang isang oras para i-debug ang away ng mod_alias at mod_rewrite.

Mga trailing slash

Nagdaragdag ang sariling canonical redirect ng WordPress ng trailing slash sa halos lahat ng permalink. Kaya ito:

Redirect 301 /old-page/ https://example.com/new-page

ay lumilikha ng dalawang hop — ang 301 mo patungo sa URL na walang slash, tapos ang sariling 301 ng WordPress na nagdaragdag ng slash. Nakakapasa pa rin ng ranking signal ang mga chain, pero nasasayang ang crawl budget at nadaragdagan ng isang round trip ang bawat bisita.

I-load muna ang destinasyon sa isang browser, kopyahin ang URL nang eksakto kung paano ito huminto sa address bar, at iyon ang gamitin. Kung nagtatapos sa .html ang iyong permalink structure o kung wala itong trailing slash, itugma iyon sa halip. Walang pangkalahatang tamang sagot dito, mayroon lamang “itugma ang inihahatid ng WordPress.”

Pagsubok nang hindi mo isinasara ang pinto sa sarili mo

Binabasa ang .htaccess sa bawat request. Ang isang syntax error ay nagbabalik ng 500 para sa buong site kasama ang wp-admin, kaya kailangang naroon na ang daan pabalik bago mo pa ito kailanganin.

I-back up muna ang file. Sa pamamagitan ng SSH:

cp /path/to/wordpress/.htaccess /path/to/wordpress/.htaccess.bak

Kung mag-500 ang site, ipalit muli ang pangalan ng sirang file at agad na babalik ang site. Mag-iwan ng SFTP session na bukas na sa ibang window — ang pag-log in mula sa simula habang bagsak ang site ang pinagsisimulan ng pagkapanic. Tandaan na ang apachectl configtest ay hindi nagpa-parse ng .htaccess, kaya iuulat nitong malusog ang config habang patay ang site mo.

Mag-test gamit ang curl, hindi ang browser. Matigas ang pagka-cache ng mga browser sa 301 response at maluwag nilang ipapakita sa iyo ang resulta kahapon:

curl -sI https://example.com/old-page/ | head -n 5

Dalawang bagay ang basahin: dapat sabihin ng status line ang 301, at ang Location: header ay dapat ang eksaktong huling URL. Para makita ang buong chain, sundan ito:

curl -sIL https://example.com/old-page/ | grep -E '^(HTTP|Location)'

Ang higit sa isang linyang HTTP/1.1 301 ay nangangahulugang gumawa ka ng chain. Ang higit sa mga limang linya ay nangangahulugang gumawa ka ng loop, at hihinto ang curl at sasabihin niya iyon sa iyo.

Gumamit ng 302 habang hindi ka pa sigurado. Ang 302 ay hindi nagka-cache nang katulad, kaya nababawi ang isang pagkakamali sa loob ng ilang segundo. Lumipat sa 301 kapag ipinakita na ng curl ang destinasyong iyong hinangad. Walang halaga ito at mas maraming site na ang nailigtas nito kaysa sa alinmang ugali sa artikulong ito.

Kung may rule na parang wala talagang ginagawa, kumpirmahin munang binabasa nga ng Apache ang file. Ang AllowOverride None sa directory ay nagiging dahilan para tuluyang hindi pansinin ng Apache ang .htaccess, at ganap itong binabalewala ng nginx — suriin ang Server: header gamit ang curl -I bago mo i-debug ang mga regex. Para buuin ang block na may tamang syntax para sa iyong bersyon ng Apache at install path, gamitin ang WordPress htaccess generator.

Kailan hindi dapat gumamit ng htaccess

Para sa iilang redirect na kailangang pamahalaan mismo ng mga editor, mas mainam na kasangkapan ang isang redirect plugin na nagse-save ng mga rule sa database — nabubuhay ito sa mga paglilipat ng host at hindi nangangailangan ng SSH. Totoo ang kapalit: kailangang mag-boot ng php para maihatid ang redirect, na mas mabagal kaysa sa Apache na sumasagot nang diretso.

Gamitin ang .htaccess para sa mga istruktural at permanenteng paglipat — pagpapalit ng domain, pagpapalit ng pangalan ng seksyon, pagpilit ng https o www. Gumamit ng plugin para sa mga isahang redirect na pang-editorial. Ayos lang ang paggawa ng dalawa basta alam mo kung aling layer ang nagmamay-ari ng aling URL, dahil ang redirect na nakadeklara sa dalawang lugar ay isang bug na naghihintay lang ng masamang hapon.