Avaat Google Search Console ja huomaat, että etusivu on indeksoitu kahteen kertaan: muodossa site.ru/ ja site.ru/index.php. Tai site.ru/index.html. Hakukoneelle nämä ovat kaksi eri URL-osoitetta, joilla on sama sisältö. Seuraus: sivun auktoriteetti jakautuu kahtia duplikaattien kesken, sijoitukset laskevat ja crawl-budjettia menee hukkaan.

Ongelma on yhtä vanha kuin web. Mekaniikka on yksinkertainen: oletuksena palvelin palauttaa index.html- tai index.php-tiedoston, kun juurta pyydetään DirectoryIndex-direktiivin kautta, mutta se ei estä suoraa pääsyä osoitteeseen site.ru/index.php. Apachen näkökulmasta molemmat osoitteet ovat sallittuja. Hakukone kuitenkin näkee kaksi eri sivua, joilla on sama sisältö, ja alkaa arvailla, kumpaa sijoittaa.

Alla on kolme tapaa määrittää 301-uudelleenohjaus indeksitiedostoista juureen: yleispätevästä .htaccess-tiedostosta Cloudflareen ja Nginxiin. Lisäksi varmennusmenetelmä, joka vie kaksi minuuttia.

💡 Pikakatsaus:

• Lisää mod_rewrite-säännöt .htaccess-tiedostoon sieppaamaan pyynnöt index.html- ja index.php-tiedostoihin
• WordPressille ja CMS-järjestelmille käytä PHP-uudelleenohjausta entry point -tiedostossa index.php (se säilyy silloinkin, kun polkurakennetta päivitetään)
• Varmista tulos komennolla curl -I tai redirectchecker.com-palvelulla (vastauksen tulee olla 301 Moved Permanently)
• Käy läpi sivuston sisäiset linkit ja korvaa /index.php muodolla / valikoissa, logoissa ja widgeteissä

Miksi indeksitiedostojen duplikaatit vahingoittavat sivustoasi

Kun kävijä kirjoittaa osoiteriville site.ru, Apache korvaa sen hiljaisesti tiedostolla index.html tai index.php DirectoryIndex-asetuksen mukaisesti. Selain näyttää sivun, osoite pysyy siistinä eikä käyttäjä huomaa korvausta.

Mutta jos jossain päin verkkoa on jo olemassa linkki täyteen polkuun site.ru/index.php, hakukoneen crawler seuraa sitä, näkee saman sisällön kuin osoitteessa site.ru/ ja kirjaa duplikaatin. Mistä tällainen linkki on peräisin? Vaihtoehtoja on runsaasti: vanha kirjoitus kolmannen osapuolen sivustolla, kumppani, joka listasi väärän URL-osoitteen, somenjakoplugini, joka loi jaon index.php-päätteellä, tai jopa kehittäjä, joka lisäsi navigaatioon href="/index.html"-linkin sivupohjaa tehdessään.

Mitä käytännössä tapahtuu:

• Linkkien tuoma auktoriteetti jakautuu. Takaisinviittaukset jakautuvat osoitteiden / ja /index.php kesken sen sijaan, että ne kasaantuisivat yhdelle kanoniselle sivulle.
• Crawl-budjettia menee hukkaan. Botti käyttää aikaa duplikaattien läpikäymiseen hyödyllisten osioiden sijaan.
• Relevanssi laimenee. Hakukone ei ymmärrä, kumpaa kahdesta sivusta näyttää tuloksissa, ja saattaa vaihdella niiden välillä, käyttäjäkäyttäytymistilastot vääristyvät ja sijoitukset muuttuvat epävakaiksi.

Tilanne on täysin hallittavissa. Se ratkaistaan määrittämällä pysyvä 301-uudelleenohjaus tiedostoista index.html ja index.php juureen /. Tutustutaan käytettävissä oleviin menetelmiin.

Menetelmä 1: Uudelleenohjaus.htaccess-tiedoston kautta Apachella

.htaccess-tiedosto sijaitsee sivuston juuressa. Jos sitä ei ole, luo tekstitiedosto, jonka nimi alkaa pisteellä; mikä tahansa FTP-asiakasohjelma tai palveluntarjoajan tiedostonhallinta hoitaa tämän.

Avaa .htaccess ja etsi rivi RewriteEngine On. Jos sitä ei ole, lisää se aivan ensimmäiseksi riviksi mahdollisten kommenttien jälkeen. Se ottaa käyttöön mod_rewrite-moduulin, joka vastaa kaikista uudelleenohjauksista.

Lisää RewriteEngine On-rivin alle säännöt. Tässä on minimaalinen toimiva kokoonpano:

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]

Näin tämä toimii rivi riviltä:

• RewriteCond %{THE_REQUEST} tarkistaa alkuperäisen pyyntömerkkijonon, jonka selain lähetti palvelimelle. Se sisältää nimenomaisesti /index.php- tai /index.html-polun, ja juuri sitä me olemme pyydystämässä.
• RewriteRule ohjaa pyynnön verkkotunnuksen juureen 301-koodilla (pysyvä uudelleenohjaus). L-lippu (last) pysäyttää sääntöjen jatkokäsittelyn.
• %{HTTP_HOST} korvaa automaattisesti sivuston verkkotunnuksen; sinun ei tarvitse kirjoittaa sitä käsin. Protokollaksi on nimenomaisesti määritetty https://.

Kriittinen huomio: älä käytä yksinkertaistettua rakennetta Redirect 301 /index.php /. mod_alias-moduulin Redirect-direktiivi jää silmukkaan indeksitiedostojen kanssa. Kun uudelleenohjaus juureen / on tehty, Apache korvaa sen uudelleen tiedostolla index.php DirectoryIndex-asetuksen kautta, sääntö laukeaa uudestaan ja selain heittää loputtoman silmukan virheen. RewriteCond + RewriteRule -yhdistelmä mod_rewrite-moduulin kautta analysoi nimenomaan alkuperäistä pyyntöä (%{THE_REQUEST}), ei sisäisten sääntöjen uudelleenkirjoittamaa, joten silmukkaa ei synny.

.htaccess-tiedoston muutokset tulevat voimaan välittömästi; Apache lukee tiedoston uudelleen jokaisen pyynnön yhteydessä, eikä palvelimen uudelleenkäynnistystä tarvita.

Menetelmä 2: PHP-uudelleenohjaus WordPressille ja CMS-järjestelmille

WordPressiä, Joomlaa, Drupalia ja muita CMS-järjestelmiä käyttävillä sivustoilla .htaccess-tiedoston muokkaaminen on riskialtista: CMS kirjoittaa sen uusiksi, kun polkurakennetta päivitetään, URL-rakennetta muutetaan tai SEO-lisäosia aktivoidaan. Sääntösi saattavat kadota seuraavan asetusten tallennuksen yhteydessä.

WordPressille on olemassa kestävämpi lähestymistapa: uudelleenohjaus suoraan entry point -tiedostossa index.php. Se sijaitsee CMS-asennuksen juuressa ja suoritetaan jokaisen pyynnön yhteydessä, ennen kuin ydin latautuu.

Avaa WordPressin index.php ja lisää aivan alkuun, heti avaavan <?php-tagin jälkeen:

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
// ...

Puhtaalla PHP-pohjaisella sivustolla ilman CMS:ää logiikka on sama: sijoita koodi entry point -tiedostoon index.php julkisen hakemiston juuressa. Jos sivustosi käyttää molempia indeksitiedostoja (index.php ja index.html), lisää vastaava tarkistus index.html-tiedostolle saman skriptin alkuun.

Miksi tämä menetelmä on luotettavampi kuin .htaccess-tiedoston muokkaaminen CMS-järjestelmissä:

• Koodi sijaitsee PHP-tiedostossa, johon CMS ei koske polkuasetuksia päivittäessään.
• $_SERVER['REQUEST_URI']-tarkistus nappaa nimenomaan pyydetyn URL-osoitteen, ei sitä, jonka WordPressin sisäiset säännöt ovat uudelleenkirjoittaneet.
• exit() takaa, että suoritus pysähtyy; yksikään rivi sen jälkeen ei ajaudu suoritukseen.

Paljon liikennettä saavilla projekteilla PHP-uudelleenohjaus on hieman nopeampi kuin .htaccess-variantti: mod_rewrite ei käynnisty jäsentämään säännöllisiä lausekkeita, mikä säästää millisekunteja jokaisessa pyynnössä.

Menetelmä 3: Cloudflare, Nginx ja muut palvelimet

Cloudflare. Jos sivustosi kulkee Cloudflaren kautta, voit määrittää uudelleenohjauksen CDN-tasolla koskematta palvelintiedostoihin lainkaan. Mene kohtaan Rules → Redirect Rules ja luo sääntö:

• Kenttä: URI Path
• Operaattori: equals
• Arvo: /index.php
• Uudelleenohjauksen URL: https://yourdomain.com/
• Tilakoodi: 301

Lisää vastaava sääntö tiedostolle /index.html. Etu: uudelleenohjaus tapahtuu Cloudflaren reunalaskentapalvelimilla, eikä pyyntö koskaan edes saavu palvelimellesi. Haitta: verkkotunnuksen on oltava delegoitu Cloudflaren nimipalvelimille.

Nginx. Nginxiä käyttävät sivustot eivät käytä .htaccess-tiedostoa. Säännöt lisätään palvelimen konfiguraatiotiedostoon, yleensä /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
}

Muokkauksen jälkeen tarkista syntaksi komennolla nginx -t ja ota muutokset käyttöön: systemctl reload nginx.

LiteSpeed / OpenLiteSpeed. Palvelin tukee .htaccess-tiedostoa samoilla mod_rewrite-säännöillä kuin Apache; menetelmä 1 toimii sellaisenaan. Lisäksi voit käyttää sisäänrakennettua uudelleenohjausmekanismia LiteSpeed WebAdmin -paneelissa.

IIS (Windows Server). IIS:ää käyttävillä sivustoilla uudelleenohjaus määritetään URL Rewrite -moduulin kautta tiedostossa 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>

Lisää vastaava sääntö tiedostolle index.html.

Kuinka varmistaa, että uudelleenohjaus toimii

Luotettavin menetelmä on komentorivi. Suorita:

1
curl -I https://yourdomain.com/index.php

Vastauksen ensimmäisen rivin tulee olla HTTP/1.1 301 Moved Permanently, ja Location-otsakkeen tulee näyttää sivuston juuri. Toista sama index.html-tiedostolle. Etusivun juuressa / tulee vastata koodilla 200.

Vaihtoehtoiset varmennustyökalut:

• Redirect Checker (redirectchecker.com) näyttää koko uudelleenohjausketjun vastauskoodeineen, kätevä nopeaan diagnostiikkaan ilman terminaalia.
• Google Search Console → URL-tarkastus (tarkastus- ja testaustyökalu): näyttää, miten Googlebot näkee sivun uudelleenohjauksen jälkeen ja onko se käytettävissä indeksointia varten.

Uudelleenohjauksen määrittämisen jälkeen on kriittistä tarkistaa sivustosi sisäiset linkit. Varmista, että valikot, logo (joka yleensä linkittää etusivulle), murupolut ja aiheeseen liittyvien artikkelien lohkot osoittavat osoitteeseen /, eivät /index.php. Yksi rikkinäinen sisäinen linkki voi luoda juuri poistamasi duplikaatin uudelleen. Tee lähdekoodihaku koko sivustolta: avaa mikä tahansa sivu, paina Ctrl+U ja etsi href="/index.php" tai href="/index.html". Korvaa jokainen esiintymä muodolla href="/".

Video: Googlen lyhyt selitys 301-uudelleenohjauksista

Neljän minuutin video Google Search Centralilta, välttämätöntä katsottavaa, jos määrität uudelleenohjauksia ensimmäistä kertaa. John Mueller selittää, miten hakukone käsittelee pysyviä uudelleenohjauksia ja onko niiden määrälle rajaa:

⁉️🤔 Usein kysytyt kysymykset

Mitä tapahtuu, jos en määritä uudelleenohjausta index.php-tiedostosta lainkaan?

Hakukone valitsee kanonisen version itse, mutta ei välttämättä sitä, jota tarvitset. Osa linkkien tuomasta auktoriteetista menee duplikaatille, ja molemmat URL-osoitteet saattavat vuorotella hakutuloksissa. Suoraa rangaistuksen uhkaa ei ole, mutta sijoitukset ovat alhaisemmat kuin ne voisivat olla puhtaalla rakenteella. Googlen John Mueller on toistuvasti korostanut, että kanonisointi rel="canonical"-määritteellä on vihje hakukoneelle, ei direktiivi. Google saattaa jättää kanonisen huomiotta ja valita toisen sivun, jos se pitää sitä relevantimpana. 301-uudelleenohjaus on direktiivi: se takaa painoarvon siirtymisen ja sulkee duplikaatin pois indeksistä.

Voinko käyttää Redirect 301 /index.php / -direktiiviä mod_rewrite-sääntöjen sijaan?

Teknisesti kyllä, mutta indeksitiedostojen kohdalla tämä on vaarallista. Kun uudelleenohjaus juureen / on tehty, Apache korvaa sen uudelleen tiedostolla index.php DirectoryIndex-asetuksen kautta, Redirect-sääntö laukeaa uudestaan, tuloksena on loputon silmukka, ja selain katkaisee sen ERR_TOO_MANY_REDIRECTS-virheellä. RewriteCond-ehto %{THE_REQUEST}-tarkistuksella ei kärsi tästä ongelmasta: se analysoi alkuperäistä selaimelta tullutta pyyntöä, ei palvelimen sisäisten sääntöjen uudelleenkirjoittamaa.

Tarvitseeko uudelleenohjaus määrittää, jos sivusto toimii vain HTTPS:n yli?

Kyllä. HTTPS ja indeksiduplikaatit ovat kaksi erillistä ongelmaa. Vaikka HTTP→HTTPS-uudelleenohjaus olisi määritetty ja rel="canonical" oikein, suora pyyntö osoitteeseen https://site.ru/index.php palauttaa 200-koodin ilman uudelleenohjausta. Menetelmän 1 säännöt kattavat molemmat protokollat: RewriteRule määrittää kohde-URL:ssa nimenomaisesti https://.

Kuinka varmistan, ettei uudelleenohjaus ole rikkonut sivustoa?

Kolme tarkistuspistettä: 1) etusivu avautuu juuressa / ilman uudelleenohjauksia (curl -I-komennon tulee palauttaa 200); 2) URL-osoitteet, joissa on index.php ja index.html, palauttavat 301-koodin ja johtavat juureen /; 3) WordPressin hallintapaneeli (/wp-admin/) toimii ilman silmukoita. Viimeinen kohta on kriittinen: huonosti kirjoitettu sääntö .htaccess-tiedostossa voi siepata pyynnöt index.php-tiedostoon hallintapaneelin sisällä ja rikkoa kirjautumisen. Menetelmän 1 rakenne on turvallinen: se tarkistaa tarkan URI-vastaavuuden eikä koske osoitteeseen /wp-admin/index.php.

Entä muut indeksitiedostot, kuten index.aspx tai index.py?

Mekaniikka on sama: kopioi RewriteCond + RewriteRule -lohko, vaihda pääte ja lisää se .htaccess-tiedostoon. Epästandardien päätteiden kohdalla varmista, että tiedosto on fyysisesti olemassa juuressa ja että se on listattu DirectoryIndex-asetuksessa; muuten palvelin ei pysty tarjoilemaan sitä indeksitiedostona joka tapauksessa, eikä uudelleenohjausta tarvita.

Indeksitiedostojen duplikaattien käsittely: lopullinen tarkistuslista

301-uudelleenohjauksen määrittäminen tiedostoista index.html ja index.php juureen on "viisi minuuttia työtä, vuosien suoja" -tehtävä. Sääntö sijaitsee läpinäkyvästi .htaccess- tai index.php-tiedostossa eikä vaadi ylläpitoa, kun vaihdat ulkoasua tai siirryt toiselle palveluntarjoajalle.

Toimenpiteet muutosten tekemisen jälkeen:

• Varmista uudelleenohjaus komennolla curl -I tai redirectchecker.com-palvelulla; vastauksen tulee olla 301.
• Varmista, että etusivu avautuu juuressa 200-koodilla.
• Etsi href="/index.php" ja href="/index.html" sivun lähdekoodista; korvaa jokainen esiintymä muodolla href="/".
• Suorita Google Search Consolessa etusivun tarkastus; botin tulee nähdä 200-koodi ja kanoninen URL ilman /index.php-päätettä.

Tämän jälkeen duplikaatit katoavat vähitellen Search Consolen "Kattavuus"-raportista, ja takaisinviittausten tuoma auktoriteetti keskittyy yhdelle kanoniselle sivulle. Tulos ei ole välitön (hakukone tarvitsee aikaa indeksoidakseen sivut uudelleen), mutta se on väistämätön.