A legjobb .htaccess útmutató SEO-knak (Példákkal!)

A weboldalad lehet, hogy leállt, miután elvégeztél néhány szerkesztést a .htaccess fájlodon. De emiatt nem kell aggódnod!

Ez sok SEO-val történik meg, akik megpróbálnak technikai javítások elvégzésével extrát nyújtani.

A WordPress műszerfalon keresztül végzett szerkesztések általában mini pánikrohamot okoznak, mivel a hibás .htaccess fájl frissítése után ki vagy zárva a műszerfalból.

A .htaccess fájlok egyszerre áldás és csapás a SEO-k számára, mivel segít a weboldal funkcióinak testreszabásában.

A fájlok jelszóval való védelmétől kezdve, a 301-es átirányításon át, vagy egy speciális hibaoldal beállításáig, a .htaccess hasznos, ha webhelye Apache webszerverrel fut.

Ha Ön olyan valaki, aki gyors megoldást keres, hogy webhelyét újra működésbe hozza egy .htaccess frissítési hiba után, vagy ha többet szeretne megtudni webhelye .htaccess fájljának optimalizálásáról, akkor ez az az erőforrás, amiről azt hitte, hogy soha nem is létezik.

Adunk néhány nagyon gyors .htaccess javítást és tippet, hogy Ön, mint SEO, most már magabiztosan végezhet változtatásokat a weboldalon anélkül, hogy aggódnia kellene az utóhatások miatt.

Azt már tudod, hogy mi az a .htaccess, és hogy mennyire hasznos egy Apache webkiszolgálót futtató webmester számára.

A kezdők számára azonban elmagyarázom a .htaccess néhány alapját, hogy segítsek nekik megérteni azt, mielőtt végrehajtják.

Kérem, hogy a tartalomjegyzék segítségével bátran váltson a kívánt fejezetre.

Mi az a .htaccess?

A.htaccess egy olyan konfigurációs fájl, amelyet az Apache webkiszolgáló szoftver olvashat és hajthat végre további funkciók és jellemzők engedélyezése/tiltása érdekében. Mivel a .htaccess fájl Unix-alapú környezetben létezik, és könyvtárszinten belül rendeződik, felülírja a globális webkiszolgáló beállításait, lehetővé téve a weboldal-hozzáférés egyéni konfigurálását.

Mit jelent a .htaccess?

A .htaccess a “hipertext hozzáférés” rövidítése. A név azután keletkezett, hogy a fájl népszerűvé vált a fejlesztők körében, akik a felhasználói elérési funkciók könyvtárankénti módosítására használták.

.htaccess az Apache kiszolgáló http.config direktíváit használja arra, hogy engedélyezze és korlátozza a könyvtárakhoz való hozzáférést a felhasználóneveket és jelszavakat használó egyének számára. Amikor azonban a SEO-król van szó, a .htaccess-nek még nagyobb szerepe van.

Mire használják a .htaccess-t?

Ha olyan webhelye van, amely folyamatosan különböző követelményekkel jelentkezik, tekintse a .htaccess-t áldásosnak.

SEO-ként a .htaccess jól jön, mivel segítségével utasításokat adhat a webkiszolgálónak a 301-es átirányításhoz, engedélyezheti a gyorsítótárazást, frissítheti a HTTP fejléceket, ellenőrizheti a lánctalálatot, SEO-baráttá teheti az URL-eket és még sok minden mást!

Hol található a .htaccess fájl?

Mivel a .htaccess egy könyvtárszintű konfiguráció, a webes könyvtáron belül szinte minden mappában megtalálható. Ha egyetlen webkönyvtárad van több alkönyvtárral (weboldal), a .htaccess fájl megtalálható a gyökérkönyvtárban és az egyes alkönyvtárakban is.

Ha WordPress felhasználó vagy, a .htaccess fájl elérésének legjobb módja a Yoast bővítmény opciója.

Vigyázat! Mivel a .htaccess nem olyasmi, amivel kezdőknek érdemes játszaniuk, javaslom, hogy a demóhelyen próbáld ki. Továbbá, bőséges ismeretekkel kell rendelkeznie a Filezilla használatáról a gyökérmappa eléréséhez, ha kizárják a WordPress adminból.

Ha WordPress webhelyet üzemeltet, van egy maroknyi bővítmény, amely támogatja a .htaccess fájl szerkesztését. Mivel a legtöbb WordPress-felhasználó a Yoastot választja alapértelmezett SEO bővítményként, hadd magyarázzam el, hogyan szerkesztheti a .htaccess fájlt a Yoast Dashboardban a WordPressen belül.

1. lépés: Jelentkezz be a WordPress Admin Dashboardra

2. lépés: Nyisd meg a Yoast Settings

3. lépés: Nyisd meg az Tools

4. lépés: Az eszközökön belül válaszd ki a “File Editor”-t

5. lépés: Szerkeszd a .htaccess fájlt és mentsd el

A legtöbb WordPress weboldalon a .htaccess alapértelmezett beállítással érkezik:

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ -
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php
# END WordPress

Mi van, ha a weboldaladnak nincs .htaccess fájlja?

Mivel a .htaccess egy automatikusan generált konfigurációs fájl, az esetek 99%-ában jelen lesz. Azonban ez általában egy rejtett fájl a könyvtárakon belül, és a webmesterek azt hiszik, hogy hiányzik. Csak engedélyezd a “rejtett fájlok megjelenítése” opciót, és máris meg fogod találni.

Ha még ezek után sem sikerül megtalálni a .htaccess fájlt, akkor lehet, hogy kézzel kell írni egyet és feltölteni a webszerverre.

Lépések az egyéni .htaccess fájl létrehozásához

1. lépés: Nyissa meg a jegyzettömböt

2. lépés: Írja be a konfigurációt (a teszteléshez használja a fent megadott alapértelmezett konfigurációt)

3. lépés: Mentse a fájlt ASCII-ben .htaccess fájlnévvel

4. lépés: Győződjön meg róla, hogy a fájl nem a .txt formátumban

5. lépés: A Filezilla segítségével töltse fel a .htaccess fájlt a webes könyvtárába

Megjegyzés: Ha WordPress felhasználó vagy, és üres a .htaccess fájl mezője, csak add hozzá a konfigurációt és mentsd el.

Mit tegyél, ha a .htaccess fájl frissítése után kizárnak a WordPress Dashboardból?

Előfordulhat, hogy a Yoast vagy a WP File Manager segítségével frissítette a .htaccess fájlt, és kizárták a műszerfalról. Ne ess pánikba! Ez könnyen javítható.

Ha SEO vagy, szerezd meg a weboldalad FTP hozzáférését a fejlesztőtől azon, aki a szervert kezeli. Ha szakértő segítségére van szüksége, a fejlesztője lehet a legjobb segítő kéz.

1. lépés: Jelentkezzen be a FileZilla segítségével a webkönyvtárába

2. lépés: Töltse le a .htaccess fájlt a könyvtárból

3. lépés: Frissítse a .htaccess fájlt az alapértelmezett konfigurációval, és mentse el

4. lépés: Cserélje ki a könyvtárban lévő régi .htaccess fájlt az újjal

Megjegyzés: Ha az a prioritása, hogy a webhelyet minél hamarabb újra online hozza, használja az alapértelmezett kódot. Ha azonban sok módosítást hajtott végre a .htaccess fájlban, próbálja megkeresni azt a kódot, amelyik visszafelé sült el. Távolítsa el azt, mielőtt visszatöltené a szerverre.

Miért lát hibát a .htaccess fájl frissítése után?

Ha SEO vagy, aki megpróbálja alaposan megtanulni a .htaccess fájlt, jó eséllyel az elején elkövet néhány hibát. Ez teljesen rendben is van, amíg meg nem érted, miért jelzett hibát a webszerver.

Van néhány gyakori probléma, amellyel a SEO-k találkoznak, amikor a .htaccess fájl frissítéséről van szó. Íme a leggyakoribb .htaccess problémák listája.

  1. Letiltott felülbírálat: Ahhoz, hogy a .htaccess fájl működjön, először engedélyeznie kell az AllowOverride opciót. Ha az AllowOverride opció None értékre van állítva, akkor a .htaccess fájlban beállított összes konfiguráció le lesz tiltva. Az Override opció engedélyezésének biztosításához kövesse az alábbi lépéseket:

1. lépés: Nyissa meg az Apache konfigurációs fájlt (http.conf)

2. lépés: Állítsa be az Allow OverRide direktívát : AllowOverride All

Step 3: Mentse az Apache Config fájlt és indítsa újra az Apache szervert

  1. Helytelenül írt fájlnév: Ez a második leggyakoribb hiba, amit a SEO-k elkövetnek. Mivel a .htaccess egy Unix-alapú, ASCII-ben mentett konfigurációs fájl, a helytelenül írt név hibát eredményez. Ha a fájl nem “.”-val kezdődik, vagy más fájlformátumban, például .txt-ben kerül feltöltésre, az Apache szerver figyelmen kívül hagyja a fájlt és a beállított konfigurációt.
  2. A .htaccess hierarchiája Tárgyak: A .htaccess fájlok végrehajtása a hierarchiájuk alapján történik. A .htaccess fájlok elején beállított néhány szabály érvénytelenítheti a konfiguráció későbbi szakaszában érkező szabályokat. Ha úgy gondolja, hogy ezek kritikusak, próbálja meg feljebb helyezni az adott konfigurációt.
  3. Több .htaccess fájl: Mivel a .htaccess fájlokat könyvtáranként lehet használni, van rá esély, hogy a webhelye több .htaccess fájlt használ. Ilyen esetekben az egyik fájl ellentmondhat a másikban beállított konfigurációnak, ami hibához vezethet. Ezt a hibát az egyes .htaccess fájlok letiltásával orvosolhatja.
  4. Syntax Error: A .htaccess fájl teljes mértékben a weboldal konfigurálásához használt szintaxis alapján működik. Egy szintaxis hiba a fájlban offline állapotba hozhatja webhelyét, és pánikrohamot okozhat. Ezért elengedhetetlen, hogy megértse a szintaxist, mielőtt frissíti a .htaccess fájlokat.

Milyen gyakori hibaüzeneteket kap a .htaccess fájl frissítése után?

Minden alkalommal, amikor egy felhasználó meglátogatja a webhelyét, közvetlenül vagy közvetve kapcsolatba lép a webkiszolgálóval. Az oldalakat, amelyeket a képekre és más erőforrásokra kattintva kapnak meg, a webszerver hozza le, ami azt jelenti, hogy Ön mint webmester korlátozhatja azt.

Egyes weboldalak a .htaccess-t használják a weboldalak eléréséhez szükséges hitelesítés beállítására. Ha SEO-król van szó, akkor arra használják, hogy a felhasználók és a keresőrobotok könnyen hozzáférjenek a legfontosabb oldalakhoz. Ha a weboldal nem adja meg a kért információt, a webkiszolgáló hibakódot generál a .htaccess fájlban beállított konfigurációk alapján.

Itt van a webszerverek által megjelenített hibakódok listája, ha nem sikerül lekérni a kért adatokat.

Client Request Errors

  • 400 – Bad Request: Invalid URL Structure. A szerver nem tudja értelmezni a felhasználó által feltett kérést.
  • 401 – Engedélyezés szükséges: Ezek az üzenetek akkor jelennek meg, ha az oldalhoz való hozzáférést a webmesterek korlátozták.
  • 402 – Fizetés szükséges (még nem használt): Ha a fizetés kezdeményezése nem történik meg, általában ezt a kódot adja ki.
  • 403 – Forbidden (Tiltott): A 403-as hiba egyszerű oka, hogy olyan erőforráshoz próbál hozzáférni, amely korlátozott jogosultsággal rendelkezik. Egy weboldal akkor jelenít meg 403-as tiltott hibát, amikor a felhasználók olyan oldalhoz próbálnak hozzáférni, amely hitelesítést igényel.
  • 404 – Nem található: A 404 egyértelmű jelzés a felhasználók számára, hogy a kért URL nem elérhető a weboldalon. Ennek oka lehet egy elírási hiba az URL-ben, vagy amikor az oldalt eltávolították a webhelyről.
  • 405 – Method Not Allowed: Ez a HTTP-válaszállapotkód azt jelzi, hogy a kiszolgáló megtagadta a kérési módszer elfogadását, annak ellenére, hogy megértette a kérés célját.
  • 406 – Nem elfogadható (kódolás): Ez általában akkor fordul elő, ha a kiszolgáló nem tud válaszolni az accept-header kérésre.
  • 407 – Proxy hitelesítés szükséges: Ez a hiba azt jelzi, hogy a kérés nem teljesíthető, mert a böngésző és a kiszolgáló között nincs proxykiszolgáló-hitelesítés.
  • 408 – A kérés ideje lejárt: Ez az egyik leggyakoribb HTTP-hiba, amellyel a webmesterek akkor találkoznak, amikor a kiszolgáló nem kapja meg a teljes kérést a kliens oldaláról a megadott időkorláton belül.
  • 409 – Összeférhetetlen kérés: Ez a hiba akkor fordul elő, amikor a cél erőforrás állapota ütközik az aktuális állapottal. A hiba feloldásához azonosítsa a konfliktust, és küldje el újra.
  • 410 – Gone: Ez a hibakód azt jelzi, hogy a kért erőforráshoz való hozzáférés véglegesen megszűnt a kiszolgálóról, és ez mindvégig így is marad.
  • 411 – Content Length Required: A hiba azt jelzi, hogy a kiszolgáló nem tudja elfogadni a kliens kérését, mert nem sikerült meghatározni a content-length fejlécet.
  • 412 – Előfeltétel sikertelen: A hiba a kiszolgálón végrehajtott egy vagy több biztonsági konfigurációval való biztonsági ütközés miatt keletkezett.
  • 413 – A kérési entitás túl hosszú: Ha a kért erőforrás túl nagy a szerver számára a betöltéshez, a felhasználó a 413 hibát tapasztalhatja.
  • 414 – Túl hosszú a kérési URI: Gondoljunk csak egy 2048 karakter feletti URL-szerkezetre. A szerver nem tudja megfejteni a keletkező 414-es hibát.
  • 415 – Nem támogatott médiatípus: Ez a hiba akkor jelenik meg, amikor a kiszolgáló nem hajlandó betölteni egy nem támogatott médiaformátumú erőforrást.

Kiszolgálói hibák

  • 500 – Belső kiszolgálói hiba
  • 501 – Nem implementált
  • 502 – Rossz átjáró
  • 503 – Nem elérhető szolgáltatás
  • 504 – Átjáró időkorlát
  • 505 – Nem támogatott HTTP verzió.

Mire szolgál a .htaccess?

Továbbirányítások

Megváltoztattad a weboldalad domain nevét?

SEO-ként biztosan nem szeretné, ha a felhasználók egy 404-es oldalt látnának, és azt sem szeretné, ha a nehezen megszerzett tekintély csak úgy eltűnne.

Mindkét aggodalomra csodaszerként tekinthet a .htaccessre. Az átirányítási utasítás hozzáadása a .htaccess fájlhoz segít átirányítani a forgalmat és a webhely tekintélyét az új domainre.

Az érdekes dolog az, hogy ugyanezt megteheti a webhelyén belüli URL-ek esetében is. A 301-es átirányítási irányelv létrehozásával a régi URL-t elérni próbáló felhasználóidat és a keresőmotorok botjait arra készteted, hogy egy új oldalt olvassanak a webhelyeden belül.

Példa a domain szintű átirányításra .htaccess segítségével:

# This allows you to redirect your entire website to any other domain 
Redirect 301 / http://example.com/

Példa URL átirányításra .htaccess használatával:

RedirectMatch 301 ^/old-url.html$ /new-url.html

SEO-barát URL-ek

Megzavarodott az URL-szerkezete? A felhasználók és a keresőrobotok nem tudják megérteni, hogy mi van az oldalon belül? Ez elég sok webmesterrel előfordul.

Az, hogy kezdetben nem fordítanak figyelmet az URL-szerkezetre, nagy fájdalmat okoz, miután a weboldal tekintélyt szerez.

A .htaccsok használatával beállíthatja a weboldalának megfelelő URL-szerkezetét.

Ezeken kívül minden olyan kiterjesztés, amely az URL-hez tartozik, például .html vagy .php, könnyen eltávolítható a .htaccess irányelvek hozzáadásával.

1. példa: A .htaccess használata a kiterjesztések eltávolítására az URL-ből

A .php mint kiterjesztés eltávolítása

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^(.*)$ .php

A .html mint kiterjesztés eltávolítása

RewriteEngine on 
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^(.*)$ .html

2. példa: A .htaccess használata az URL-ek kisbetűvé tételéhez

Módszer 1

RewriteCond %{REQUEST_URI} 
RewriteRule . ${lc:%{REQUEST_URI}}

A fenti kód az összes URL szerkezetre hatással lesz, beleértve a domain nevet is.

Módszer 2

RewriteCond %{REQUEST_URI} 
RewriteRule ^.+.html$ ${lc:%{REQUEST_URI}}

A fenti csak a html fájlnevekre lesz hatással.

Példa 2: A .htaccess dinamikus URL átírásához

RewriteEngine On
RewriteRule /(.*)/(.*)/$ page.php?category=&product=

Rontott URL: site.com/page.php?category=2&product=54

Jó URL: site.com/sandwiches/rueben-sandwich/

  • A .htaccess használata a webhely sebességének javítására

Az oldal sebessége az új hoo-ha a webmesterek körében.

Minden okuk megvan a felzúdulásra, mivel a Google most már az egyik legfontosabb tényezőnek tekinti az oldalak rangsorolása során a SERP-ben.

A Google nem szeretné, ha a felhasználóknak rossz felhasználói élményt nyújtanának az első helyen szereplő oldalak.

Egy lassan betöltődő weboldal ráadásul sok kúszóköltségvetést emészt fel.

A weboldal sebességének javításának egyik legegyszerűbb és legbiztonságosabb módja a .htaccess fájl.

  • Cache funkció engedélyezése

A cache funkció engedélyezésével a .htaccess fájlban a weboldal erőforrásai tárolódnak a látogató böngészőjében, lehetővé téve a gyors betöltést.

A gyorsítótárat két különböző módszerrel engedélyezheti

ExperiesByType – Ezzel a módszerrel a .htaccess fájlban beállíthatja a gyorsítótár időkeretét, más néven lejárati idejét minden egyes erőforrás számára a weboldalon belül.

Példa:

<ifModule mod_headers.c>
# YEAR
<FilesMatch ".(ico|gif|jpg|jpeg|png|flv|pdf)$">
Header set Cache-Control "max-age=29030400"
</FilesMatch>
# WEEK
<FilesMatch ".(js|css|swf)$">
Header set Cache-Control "max-age=604800"
</FilesMatch>
# 45 MIN
<FilesMatch ".(html|htm|txt)$">
Header set Cache-Control "max-age=2700"
</FilesMatch>
</ifModule>

Cache-Control Header – A Cache-control fejléc maximális életkort használ az erőforrások lejárata előtt.

Példa:

# One month for most static assets
<filesMatch ".(css|jpg|jpeg|png|gif|js|ico)$">
Header set Cache-Control "max-age=2628000, public"
</filesMatch>

Gzip tömörítés engedélyezése

Az egyik ok, ami rontja egy weboldal sebességét, az erőforrások mérete. A gzip engedélyezésével a .htaccess fájlban csökkentheti a képméretet, a fájlméretet és a fájlmennyiséget, miközben adatokat küld az ügyféloldali böngészőnek.

A gzip engedélyezése az egyik legegyszerűbb .htaccess irányelv.

Itt egy példa:

<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>

Deflate opció engedélyezése

Néhány webszerver nem támogatja a gzip-et, így a weboldal hibákba ütközhet. Ilyen esetekben tanácsos a .htaccess fájlban a deflate opciót használni.

Itt egy példa:

<IfModule mod_deflate.c>
# Compress text, HTML, JavaScript, CSS, XML
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
# The following lines are to avoid bugs with some browsers
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0 no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html
BrowserMatch bMSI !no-gzip !gzip-only-text/html
# Do not cache if these files are already cached
SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png)$ no-gzip
# Proxies must give the right content
# Header append Vary User-Agent env=!dont-vary
Header append Vary User-Agent
</IfModule>

A .htaccess használata a jobb feltérképezés és indexelés érdekében

A robot.txt fájlt már használhatja a keresőmotorok számára a webhely feltérképezésének és indexelésének engedélyezésére és tiltására. Lehetséges azonban, hogy webhelyén a weboldalon kívül más erőforrások is vannak. Ilyen esetekben előfordulhat, hogy az rbot.txt nem működik.

Ha azt szeretné, hogy néhány erőforrás, például egy PFD vagy egy Word-dokumentum ne legyen indexelve, akkor a legjobb módja ennek, ha a .htaccess fájlban beállít egy X-robots-tagot.

A .htaccess fájl egyéni fejléce az összes indexelő direktívával működhet.

Példa:

<FilesMatch ".(docx|pdf)$">
Header add X-robots-tag "noindex, noarchive, nosnippet"
</FilesMatch>

Ez esetben minden .doc és .pdf kiterjesztésű fájl noindex, noarchive, nosnippet fájlnak minősül.

Következtetés

Majdnem minden Apache szervernek van egy előre beállított konfigurációs fájlja. Ez azonban az egész webhelyre vonatkozik, ezért nehéz könyvtárszintű konfigurációt beállítani.

Ez az a pont, ahol a .htaccess áldásként hat. A .htaccess segítségével könyvtár- és alkönyvtárszintű konfigurációt állíthat be az Apache konfigurációs beállításainak felülírására.

Ezeken kívül egyszerű konfigurációs kódokat használhat a hitelesítés beállításához. Ez inkább akkor hasznos, ha megosztott tárhelye van több weboldallal.

A .htaccess fájl előnyei

  • Elolvas minden kérést
  • A szerver újraindítása nélkül azonnali módosítás
  • Effektívan kezeli a felhasználói hozzáférést a preferenciák alapján
  • Meghatározza a könyvtár szintű konfigurációt
  • Egy igazi áldás a SEO-k számára

Hátrányai a .htaccess fájl

  • A.htaccess fájlok növelhetik a webhely üzemeltetésének biztonsági kockázatait
  • Kisebb, mint a szerverszintű konfiguráció, mivel a .htaccess fájlokat minden egyes oldal betöltésekor keresik és olvassák
  • A weboldal sebességét befolyásolja, ami milliós nagyságrendű forgalmat bonyolít.

A.htaccess fájlok nem ajánlottak szerverkonfigurációs módszerként a biztonsági és teljesítményproblémák miatt

.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.