Skip to content

Kõik WordPressist, veebiarendusest — ja mitte ainult

🚀 Kuidas eemaldada index.php ja index.html URL-ist: 301 ümbersuunamine saidi juure

🚀 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-i mod_rewrite reeglid, et püüda kinni päringud failidele index.html ja index.php
  • WordPressi ja CMS-i puhul kasuta PHP ümbersuunamist sisendfailis index.php (see säilib püsilinkide uuendamisel)
  • Kontrolli tulemust curl -I või redirectchecker.com abil (vastus peaks olema 301 Moved Permanently)
  • Mine läbi saidi sisemised lingid ja asenda /index.php menüü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.php vahel, 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:

1RewriteEngine On
2
3RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/
4RewriteRule ^index\.php$ https://%{HTTP_HOST}/ [R=301,L]
5
6RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.html\ HTTP/
7RewriteRule ^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.php või /index.html, mida me püüamegi.
  • RewriteRule suunab päringu domeeni juurkataloogi koodiga 301 (püsiv ümbersuunamine). Lipp L (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 kui https://.

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
3if ($_SERVER['REQUEST_URI'] === '/index.php') {
4 header('Location: /', true, 301);
5 exit();
6}
7
8// Standard WordPress code follows
9define('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:

1location = /index.php {
2 return 301 https://yourdomain.com/;
3}
4
5location = /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:

1curl -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 Apache DirectoryIndex kaudu uuesti index.php, Redirect reegel käivitub uuesti, mille tulemuseks on lõputu silmus ja brauser katkestab selle veaga ERR_TOO_MANY_REDIRECTS. RewriteCond koos %{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 aadressile https://site.ru/index.php koodi 200 ilma ümbersuunamiseta. Meetodi 1 reeglid katavad mõlemad protokollid: RewriteRule määrab siht-URL-is selgesõnaliselt https://.

Kuidas kontrollida, et ümbersuunamine pole saiti lõhkunud?

Kolm kontrollpunkti: 1) avaleht avaneb juurkataloogis / ilma ümbersuunamisteta (curl -I peaks tagastama 200); 2) URL-id index.php ja index.html tagastavad 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äringud index.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 + RewriteRule plokk, asendage laiend ja lisage see .htaccess-i. Mittestandardsete laiendite puhul veenduge, et fail on füüsiliselt juurkataloogis olemas ja on loetletud DirectoryIndex-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 -I või redirectchecker.com abil; vastus peaks olema 301.
  • Veenduge, et avaleht avaneb juurkataloogis koodiga 200.
  • Otsige lehe lähtekoodist href="/index.php" ja href="/index.html"; asendage iga esinemine href="/"-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.