
🚀 Kuidas eemaldada index.php ja index.html URL-ist: 301 ümbersuunamine saidi juure
Avate Google Search Console'i ja näete, et avaleht on indekseeritud kaks korda: kui site.ru/ ja kui site.ru/index.php. Või site.ru/index.html. Otsingumootori jaoks on need kaks erinevat URL-i identse sisuga. Tulemus: lehe autoriteet jaguneb duplikaatide vahel pooleks, asetused langevad ja roomamiseelarve läheb raisku.
Probleem on sama vana kui veeb ise. Mehaanika on lihtne: vaikimisi tagastab server DirectoryIndex direktiivi kaudu juurkataloogi päringule index.html või index.php, kuid ei blokeeri otsest ligipääsu aadressile site.ru/index.php. Apache vaatenurgast on mõlemad aadressid legitiimsed. Otsingumootor aga näeb kahte erinevat lehte identse sisuga ja hakkab arvama, kumba neist järjestada.
Allpool on kolm viisi, kuidas seadistada 301 ümbersuunamine indeksifailidelt juurkataloogi: alates universaalsest .htaccess-st kuni Cloudflare ja Nginxini. Lisaks kinnitusmeetod, mis võtab kaks minutit.
💡 Kiire ülevaade:
- Lisa
.htaccess-imod_rewritereeglid, et püüda kinni päringud failideleindex.htmljaindex.php - WordPressi ja CMS-i puhul kasuta PHP ümbersuunamist sisendfailis
index.php(see säilib püsilinkide uuendamisel) - Kontrolli tulemust
curl -Ivõiredirectchecker.comabil (vastus peaks olema301 Moved Permanently) - Mine läbi saidi sisemised lingid ja asenda
/index.phpmenüüdes, logodes ja vidinates/-ga
Miks indeksifailide duplikaadid teie saiti kahjustavad
Kui külastaja trükib aadressiribale site.ru, asendab Apache vaikimisi selle failiga index.html või index.php vastavalt DirectoryIndex seadele. Brauser kuvab lehe, aadress jääb puhtaks ja kasutaja ei märka asendust.
Aga kui kuskil on juba olemas link täispikale teekonnale site.ru/index.php, järgib otsingurobot seda, näeb sama sisu mis aadressil site.ru/ ja registreerib duplikaadi. Kust selline link tuleb? Võimalusi on palju: vana postitus kolmanda osapoole saidil, partner, kes loetles vale URL-i, sotsiaalmeedia jagamise plugin, mis genereeris jagamise koos index.php sabaga, või isegi arendaja, kes lisas kujunduse käigus navigatsiooni href="/index.html".
Mida me praktikas saame:
- Jagatud lingi jõud. Tagasilingid jagunevad
/ja/index.phpvahel, selle asemel et koguneda ühele kanoonilisele lehele. - Raisatud roomamiseelarve. Robot kulutab aega duplikaatide roomamisele, mitte saidi kasulikele osadele.
- Lahjenenud asjakohasus. Otsingumootor ei mõista, kumba kahest lehest tulemustes kuvada, ja võib neid vaheldumisi näidata, kasutajakäitumise statistika moondub ja asetused muutuvad ebastabiilseks.
Olukord on täielikult hallatav. See lahendatakse püsiva 301 ümbersuunamise seadistamisega index.html-lt ja index.php-lt juurkataloogi /. Uurime saadaolevaid meetodeid.
Meetod 1: Ümbersuunamine.htaccess-i kaudu Apache'is
Fail .htaccess asub saidi juurkataloogis. Kui seda pole olemas, loo tekstifail, mille nime alguses on punkt; iga FTP-klient või hostingu failihaldur saab sellega hakkama.
Ava .htaccess ja leia rida RewriteEngine On. Kui seda pole, lisa see kõige esimeseks reaks pärast kommentaare. See lubab mod_rewrite mooduli, mis vastutab kõigi ümbersuunamiste eest.
RewriteEngine On alla lisa reeglid. Siin on minimaalne töötav komplekt:
1 RewriteEngine On 2 3 RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/ 4 RewriteRule ^index\.php$ https://%{HTTP_HOST}/ [R=301,L] 5 6 RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.html\ HTTP/ 7 RewriteRule ^index\.html$ https://%{HTTP_HOST}/ [R=301,L]
Kuidas see rida-realt töötab:
RewriteCond %{THE_REQUEST}kontrollib algset päringu stringi, mille brauser serverile saatis. See sisaldab selgesõnaliselt/index.phpvõi/index.html, mida me püüamegi.RewriteRulesuunab päringu domeeni juurkataloogi koodiga301(püsiv ümbersuunamine). LippL(last) peatab edasise reeglite töötlemise.%{HTTP_HOST}asendab automaatselt saidi domeeni; te ei pea seda käsitsi trükkima. Protokoll on selgesõnaliselt määratud kuihttps://.
Kriitiline märkus: ärge kasutage lihtsustatud konstruktsiooni Redirect 301 /index.php /. mod_alias-e Redirect direktiiv hakkab indeksifailide puhul silmusesse. Pärast ümbersuunamist /-le asendab Apache DirectoryIndex kaudu uuesti index.php, reegel käivitub uuesti ja brauser viskab lõputu silmuse vea. RewriteCond + RewriteRule kombinatsioon mod_rewrite kaudu analüüsib konkreetselt algset päringut (%{THE_REQUEST}), mitte seda, mille sisemised reeglid ümber kirjutasid, seega silmust ei teki.
Muudatused .htaccess-is jõustuvad koheselt; Apache loeb faili iga päringuga uuesti ja serveri taaskäivitust pole vaja.
Meetod 2: PHP ümbersuunamine WordPressi ja CMS-i jaoks
WordPressi, Joomla, Drupali ja teiste CMS-idega töötavatel saitidel on .htaccess-i muutmine riskantne: CMS kirjutab selle ümber püsilinkide uuendamisel, URL-i struktuuri muutmisel või SEO pluginatega. Teie reeglid võivad järgmisel seadete salvestamisel kaduda.
WordPressi jaoks on vastupidavam lähenemine: ümbersuunamine otse sisendfailis index.php. See asub CMS-i installi juurkataloogis ja käivitatakse iga päringuga, enne kui tuum laaditakse.
Ava WordPressi index.php ja lisa kohe algusesse, pärast avavat <?php silti:
1 <?php 2 // 301 redirect from index.php to root 3 if ($_SERVER['REQUEST_URI'] === '/index.php') { 4 header('Location: /', true, 301); 5 exit(); 6 } 7 8 // Standard WordPress code follows 9 define('WP_USE_THEMES', true); 10 // ...
Puhtal PHP-l põhinevate saitide puhul ilma CMS-ita on loogika sama: aseta kood avaliku kataloogi juures olevasse sisendfaili index.php. Kui teie sait kasutab mõlemat indeksifaili (index.php ja index.html), lisa sama skripti algusesse sarnane kontroll index.html jaoks.
Miks see meetod on CMS-i puhul usaldusväärsem kui .htaccess-i muutmine:
- Kood asub PHP-failis, mida CMS püsilinkide seadete uuendamisel ei puuduta.
$_SERVER['REQUEST_URI']kontroll püüab kinni konkreetselt küsitud URL-i, mitte selle, mille WordPressi sisemised reeglid ümber kirjutasid.exit()tagab, et täitmine peatub; mitte ükski rida pärast seda ei käivitu.
Suure liiklusega projektides on PHP ümbersuunamine veidi kiirem kui .htaccess variant: mod_rewrite ei käivitu regulaaravaldiste parsimiseks, säästes millisekundeid iga päringu kohta.
Meetod 3: Cloudflare, Nginx ja muud serverid
Cloudflare. Kui teie sait töötab läbi Cloudflare'i, saate ümbersuunamise seadistada CDN-i tasemel ilma serverifaile üldse puudutamata. Minge Rules → Redirect Rules ja looge reegel:
- Väli:
URI Path - Operaator:
equals - Väärtus:
/index.php - Ümbersuunamise URL:
https://yourdomain.com/ - Oleku kood:
301
Lisage sarnane reegel /index.html jaoks. Eelis: ümbersuunamine käivitub Cloudflare'i ääreserverites ja päring ei jõua kunagi teie hostingu serverisse. Puudus: domeen peab olema delegeeritud Cloudflare'i NS-ile.
Nginx. Nginxil põhinevad saidid ei kasuta .htaccess-i. Reeglid lisatakse serveri konfiguratsioonifaili, tavaliselt /etc/nginx/sites-available/yourdomain:
1 location = /index.php { 2 return 301 https://yourdomain.com/; 3 } 4 5 location = /index.html { 6 return 301 https://yourdomain.com/; 7 }
Pärast muutmist kontrolli süntaksit käsuga nginx -t ja rakenda muudatused: systemctl reload nginx.
LiteSpeed / OpenLiteSpeed. Server toetab .htaccess-i samade mod_rewrite reeglitega nagu Apache; meetod 1 töötab ilma muudatusteta. Lisaks saate kasutada sisseehitatud ümbersuunamise mehhanismi LiteSpeed WebAdmin paneelis.
IIS (Windows Server). IIS-il põhinevate saitide puhul konfigureeritakse ümbersuunamine URL Rewrite mooduli kaudu failis web.config:
1 <rule name="Redirect index.php to root" stopProcessing="true"> 2 <match url="^index\.php$" /> 3 <action type="Redirect" url="/" redirectType="Permanent" /> 4 </rule>
Lisage sarnane reegel index.html jaoks.
Kuidas kontrollida, kas ümbersuunamine töötab
Kõige usaldusväärsem meetod on käsurida. Käivita:
1 curl -I https://yourdomain.com/index.php
Vastuse esimene rida peaks olema HTTP/1.1 301 Moved Permanently ja Location päis peaks näitama saidi juurkataloogi. Korda sama index.html puhul. Avaleht juurkataloogis / peaks vastama koodiga 200.
Alternatiivsed kontrollimise tööriistad:
- Redirect Checker (redirectchecker.com) näitab täielikku ümbersuunamiste ahelat koos vastusekoodidega, mugav kiireks diagnostikaks ilma terminalita.
- Google Search Console → URL Inspection (ülevaatuse ja testimise tööriist): näitab, kuidas Googlebot näeb lehte pärast ümbersuunamist ja kas see on indekseerimiseks saadaval.
Pärast ümbersuunamise seadistamist on kriitilise tähtsusega kontrollida oma saidi sisemisi linke. Veenduge, et menüüd, logo (mis tavaliselt lingib avalehele), leivapuru ja seotud postituste plokid osutaksid /-le, mitte /index.php-le. Üks katkine sisemine link võib äsja eemaldatud duplikaadi uuesti luua. Tehke lähtekoodi otsing üle kogu saidi: avage ükskõik milline leht, vajutage Ctrl+U ja otsige href="/index.php" või href="/index.html". Asendage iga esinemine href="/"-ga.
Video: Google'i lühike selgitus 301 ümbersuunamiste kohta
Neljaminutiline video Google Search Centralist, hädavajalik vaatamiseks, kui seadistate ümbersuunamisi esimest korda. John Mueller selgitab, kuidas otsingumootor töötleb püsivaid ümbersuunamisi ja kas nende arvul on piirang:
⁉️🤔 Korduma kippuvad küsimused
Mis juhtub, kui ma ei seadista ümbersuunamist index.php-lt üldse?
Otsingumootor valib kanoonilise versiooni ise, kuid mitte tingimata selle, mida vajate. Osa lingi jõust läheb duplikaadile ja mõlemad URL-id võivad otsingutulemustes vahelduda. Otsest karistuste ohtu pole, kuid asetused on madalamad, kui need puhta struktuuriga olla võiksid. Google'i John Mueller on korduvalt rõhutanud, et kanoonilisuse määramine
rel="canonical"kaudu on vihje otsingumootorile, mitte direktiiv. Google võib ignoreerida kanoonilist ja valida teise lehe, kui peab seda asjakohasemaks. 301 ümbersuunamine on direktiiv: see tagab kaalu ülekandmise ja välistab duplikaadi indeksist.
Kas ma võin kasutada Redirect 301 /index.php / mod_rewrite asemel?
Tehniliselt jah, kuid indeksifailide puhul on see ohtlik. Pärast ümbersuunamist
/-le asendab ApacheDirectoryIndexkaudu uuestiindex.php,Redirectreegel käivitub uuesti, mille tulemuseks on lõputu silmus ja brauser katkestab selle veagaERR_TOO_MANY_REDIRECTS.RewriteCondkoos%{THE_REQUEST}kontrolliga seda probleemi ei oma: see analüüsib algset päringut brauserilt, mitte seda, mille serveri sisemised reeglid ümber kirjutasid.
Kas ma pean ümbersuunamise seadistama, kui sait töötab ainult üle HTTPS-i?
Jah. HTTPS ja indeksi duplikaadid on kaks sõltumatut probleemi. Isegi kui HTTP→HTTPS ümbersuunamine on seadistatud ja
rel="canonical"on korrektne, tagastab otsene päring aadressilehttps://site.ru/index.phpkoodi 200 ilma ümbersuunamiseta. Meetodi 1 reeglid katavad mõlemad protokollid:RewriteRulemäärab siht-URL-is selgesõnaliselthttps://.
Kuidas kontrollida, et ümbersuunamine pole saiti lõhkunud?
Kolm kontrollpunkti: 1) avaleht avaneb juurkataloogis
/ilma ümbersuunamisteta (curl -Ipeaks tagastama 200); 2) URL-idindex.phpjaindex.htmltagastavad 301 ja viivad/-le; 3) WordPressi administraator (/wp-admin/) töötab ilma silmusteta. Viimane punkt on kriitiline: halvasti kirjutatud reegel.htaccess-is võib püüda kinni päringudindex.php-le administraatori sees ja lõhkuda sisselogimise. Meetodi 1 konstruktsioon on ohutu: see kontrollib täpset URI vastavust ega puuduta/wp-admin/index.php-d.
Aga teised indeksifailid nagu index.aspx või index.py?
Mehaanika on sama: kopeerige
RewriteCond+RewriteRuleplokk, asendage laiend ja lisage see.htaccess-i. Mittestandardsete laiendite puhul veenduge, et fail on füüsiliselt juurkataloogis olemas ja on loetletudDirectoryIndex-is; vastasel juhul ei saa server seda niikuinii indeksifailina serveerida ja ümbersuunamist pole vaja.
Indeksifailide duplikaatidega tegelemine: lõplik kontrollnimekiri
301 ümbersuunamise seadistamine index.html-lt ja index.php-lt juurkataloogi on „viis minutit tööd, aastatepikkune kaitse" ülesanne. Reegel elab .htaccess-is või index.php-s läbipaistvalt ega vaja hooldust, kui muudate kujundust või kolite teisele hostingule.
Sammud pärast muudatuste tegemist:
- Kontrollige ümbersuunamist
curl -Ivõiredirectchecker.comabil; vastus peaks olema 301. - Veenduge, et avaleht avaneb juurkataloogis koodiga 200.
- Otsige lehe lähtekoodist
href="/index.php"jahref="/index.html"; asendage iga esineminehref="/"-ga. - Google Search Console'is käivitage avalehe ülevaatus; robot peaks nägema 200 ja kanoonilist URL-i ilma
/index.php-ta.
Pärast seda kaovad duplikaadid järk-järgult Search Console'i „Levi" aruandest ja tagasilingi jõud koondub ühele kanoonilisele lehele. Tulemus ei ole kohene (otsingumootor vajab uuesti roomamiseks aega), kuid see on vältimatu.



