En ĉi tiu artikolo, ni esploros la fundamentajn principojn uzi la .htaccess-dosieron, kiu estas kerna por plibonigi SEO. Ĉi tiu dosiero certigas taŭgan indeksadon de paĝoj de serĉiloj. Ni lernos kiel administri alidirektilojn, agordi sekurecon kaj akceli rendimenton. Aldone, ni provizos konsilojn pri kiel agordi ĉi tiun dosieron sendepende.
Kial .htaccess estas Bezonata
La .htaccess-dosiero funkcias kiel speco de "remoregilo" por retaj programistoj sur Apache-serviloj. Ĝi ofertas oportunajn ilojn por ĝustigi diversajn parametrojn kaj administri la konduton de retejo. Kiam rekta aliro al la ĉefaj agordaj dosieroj de la servilo estas neatingebla (kiel ofte okazas kun virtuala gastigado, ekzemple), .htaccess fariĝas utila ilo por fari necesajn ŝanĝojn.
Htaccess ofte troviĝas en la radika dosierujo de via retejo aŭ en tiuj dosierujoj, kie necesas speciala agordo. Ekzemple, se vi uzas WordPress, agordo povas esti farita per la Yoast SEO-kromaĵo, kiun ni diskutis en la artikolo pri Agordante robots.txt. En aliaj kazoj, sufiĉas iri al la bezonata dosierujo kaj redakti la ekzistantan dosieron .htaccess, aŭ krei ĝin se ĝi ankoraŭ ne estis kreita.
Agordante la dosieron .htaccess
301 Alidirekti htaccess
301-alidirektilo en la .htaccess-dosiero povas esti komparita al konstanta alidirekto en retejo. Ĝi informas serĉilojn kaj retumiloj, ke la paĝo nun konstante troviĝas ĉe nova adreso kaj sugestas ĝisdatigi legosignojn kaj indeksadon. Tia alidirekto estas kutime uzata kiam paĝo estas movita aŭ forigita por konservi sian rangon en serĉrezultoj kaj redirekti vizitantojn al la nova loko.
Por aktivigi alidirektilojn, vi devas ebligi la respondan komandon en la dosiero .htaccess:
RewriteEngine on
Post tio, vi povas agordi la plej simplan formon de alidirekto:
<IfModule mod_rewrite.c>
RewriteEngine On
Redirect 301 /old-page.html /new-page.html
</IfModule>
Simila alidirektilo uzante la AlidirektiPermanente direktivo aspektas jene:
<IfModule mod_rewrite.c>
RewriteEngine On
Redirect permanent /old-page.html http://new-domain.ru/new-page.html
</IfModule>
Ĉi tiuj estas la plej facilaj alidirektaj metodoj por agordi. Ni konsideru agordon kiu uzas aliajn, pli altnivelajn specojn de alidirektiloj kun la mod_rewrite modulo:
<IfModule mod_rewrite.c>
RewriteEngine On
# Redirecting from one page to another
RewriteRule ^old-page.html$ http://www.example.com/new-page.html [R=301,L]
# Redirecting all traffic from one domain to another
RewriteCond %{HTTP_HOST} ^oldsite.com$ [OR]
RewriteCond %{HTTP_HOST} ^www.oldsite.com$
RewriteRule ^(.*)$ http://www.newsite.com/$1 [R=301,L]
# Redirecting from www to non-www (or vice versa)
RewriteCond %{HTTP_HOST} ^www.example.com$
RewriteRule ^(.*)$ http://example.com/$1 [R=301,L]
# Redirecting from HTTP to HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]
# Redirecting from one subdomain to another
RewriteCond %{HTTP_HOST} ^subdomain1.example.com$
RewriteRule ^(.*)$ http://subdomain2.example.com/$1 [R=301,L]
</IfModule>
302 alidirektilo .htaccess, indikanta provizoran translokadon, estas renkontata multe malpli ofte. Jen ekzemplo de tia agordo:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^old-page.html$ /new-page.html [R=302,L]
</IfModule>
Direktiva EraroDocument
Ĉi tiu agordo permesas vin kontroli kion la uzanto vidas kiam HTTP-eraroj okazas en via retejo. Anstataŭ la norma erarmesaĝo, vi povas montri vian propran paĝon, kiu estos pli informa por la vizitanto kaj helpos ilin kompreni kio okazis. Simple sekvu ĉi tiun sintakson por uzo:
ErrorDocument <error_code> <URL_page>
Ekzemple,
ErrorDocument 404 /errors/not_found.html
Signifas ke kiam a 404 eraro okazas, la paĝo ĉe /eraroj/not_found.html estos malfermita. Absolutaj URL-oj estas precizigitaj simile:
ErrorDocument 500 http://example.com/errors/server_error.html
Ĉi tiu ekzemplo indikas la ekranon de la server_error.html paĝo ĉe http://example.com/errors/ okaze de 500 eraro.
Neante Aliron al Reteja Adresaro
La dosiero .htaccess havas la komandon Nei de ĉiuj, kiu helpas nei aliron al certaj dosierujoj aŭ dosieroj en via retservilo. Ĉi tio povas esti utila se vi volas kaŝi privatajn informojn aŭ gravajn dosierojn de vizitantoj de la retejo por certigi datuman sekurecon.
Por malŝalti listigon (rigardante ĉiujn disponeblajn dosierujojn), vi devas aldoni la linion:
Options -Indexes
Ekzemplo de blokado de aliro al specifa dosierujo aspektas jene:
<Directory /path_to_your_directory>
Order Deny,Allow
Deny from all
</Directory>
Simile, vi povas nei aliron al ununura dosiero:
<Files "file.php">
Order Deny,Allow
Deny from all
</Files>
Aŭ por gamo da dosieroj per etendaĵo:
<FilesMatch "\.(txt|log|bak)$"> # Select the desired extensions, in the example: txt, log, bak
Order Deny,Allow
Deny from all
</FilesMatch>
Blokado de Aliro per IP
Bloki aliron per IP en la .htaccess-dosiero estas metodo, kiu permesas vin limigi aliron al via retejo por specifaj IP-adresoj aŭ iliaj grupoj. Ĉi tio povas esti utila se vi volas malhelpi aliron al via retejo aŭ ĝiaj specifaj partoj por certaj homoj aŭ nedezirataj robotoj.
Blokado de ununura IP-adreso estas farita per la komando:
Order Deny,Allow
Allow from all
Deny from 11.22.33.44
Blokado de pluraj IP-adresoj estas farita simile per duobligo de la "Nei de" linio kun la postulataj adresoj.
Por blokado de gamo da IP-adresoj:
Order Deny,Allow
Allow from all
Deny from 11.11.11.11/24
Por permesi aliron nur por specifaj IP-oj, aldonu la kodon:
Order Deny,Allow
Deny from all
Allow from 11.22.33.44
Por kompleta rifuzo de aliro, uzu la direktivon Nei de ĉiuj, kaj por blokado de adresoj per masko, specifu Nei de 11.22.
kie, 11.22 estas la IP-adreso maski.
Blokado de Vizitantoj de Uzanto-Agente
Bloki uzantojn de Uzanto-Agente en la .htaccess-dosiero estas metodo por kontroli, kiu povas aliri vian retservilon surbaze de informoj pri la retumilo, kiun la vizitanto uzas. La ĉeno Uzanto-Agente enhavas datumojn pri la retumilo, kiun homo uzas por interagi kun via servilo, kaj danke al ĉi tiu informo, vi povas limigi la aliron por iuj uzantoj.
La plej ofta maniero bloki de Uzanto-Agente estas uzi mod_rewrite:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^Bot1 [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot2 [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot3 [NC]
RewriteRule ^.*$ - [F,L]
</IfModule>
En ĉi tiu ekzemplo:
- RewriteCond %{HTTP_USER_AGENT} estas uzata por kontroli la Uzanto-Agent-ĉenon.
- ^Bot1, ^Bot2, ^Bot3 estas ekzemploj de Uzanto-Agent-ĉenoj, kiujn ni volas bloki. La NC-modifiloj indikas, ke la komparo estu uskle-nesensebla.
- RewriteRule ^.*$ - [F,L] validas por la peto se iu el la RewriteCond-kondiĉoj estas plenumitaj. Ĝi sendas respondon kun la 403 Malpermesita statuskodo (F) kaj ĉesas prilabori regulojn (L).
Kaŝmemoro en htaccess
Agordi kaŝmemoron per la .htaccess-dosiero helpas akceli vian retejon igante ĝin ŝargi pli rapide por uzantoj. Ĝi funkcias jene: iuj dosieroj, kiel bildoj, CSS-stiloj kaj JavaScript-skriptoj, estas konservitaj en la kaŝmemoro de la retumilo de la uzanto post la unua ŝarĝo. Nun la retumilo povas uzi ĉi tiujn dosierojn el la kaŝmemoro, anstataŭ reŝargi ilin de la servilo ĉiufoje kiam la uzanto vizitas paĝon. Ĉi tio reduktas la tempon de ŝarĝo kaj plibonigas la rendimenton de la retejo.
Konsideru ekzemplon:
# Enable caching for images for 1 month
<FilesMatch "\.(jpg|jpeg|png|gif|svg)$">
Header set Cache-Control "max-age=2592000, public"
</FilesMatch>
# Enable caching for CSS and JavaScript for 1 week
<FilesMatch "\.(css|js)$">
Header set Cache-Control "max-age=604800, public"
</FilesMatch>
Por rimedoj kiuj estas ofte ĝisdatigitaj, aliflanke, estas necese malŝalti kaŝmemoron:
# Excluding caching for HTML pages and XML files
<FilesMatch "\.(html|xml)$">
Header set Cache-Control "no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "0"
</FilesMatch>
Optimumigo de Reteja Agado
la mod_deflate kaj mod_gzip moduloj en Apache helpas kunpremi informojn, kiujn la servilo sendas al la aparatoj de uzantoj. Ĉi tio malpligrandigas la dosierojn, kio siavice plirapidigas la paĝan ŝarĝon. Tamen, estas grave memori, ke subteno kaj agordo de ĉi tiuj moduloj povas varii depende de via servilo.
Ekzemplo de uzado de la mod_deflate modulo:
<IfModule mod_deflate.c>
# Compressing text file types
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-httpd-fastphp
AddOutputFilterByType DEFLATE image/svg+xml
</IfModule>
Ekzemplo por mod_gzip:
<IfModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$ # Enabling compression for files with extensions .html, .txt, .css, .js, .php, .pl
mod_gzip_item_include mime ^application/x-javascript.* # Enabling compression for MIME types starting with application/x-javascript
mod_gzip_item_include mime ^text/.* # Enabling compression for MIME types starting with text/
mod_gzip_item_exclude mime ^image/.* # Excluding from compression MIME types starting with image/
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.* # Excluding already compressed data (responses with the Content-Encoding: gzip header)
</IfModule>
Ni diskutis la plej ofte uzatajn direktivojn. Vi povas konatiĝi kun ĉiuj kapabloj de la dosiero en la oficiala dokumentado.
Kiel Kontroli la Funkcion de la .htaccess Dosiero
Por kontroli ĉu via .htaccess-dosiero funkcias en la retejo, vi povas plenumi la jenajn paŝojn:
- Intencite ŝanĝi la dosieron .htaccess kun eraro. Responde, la servilo devus doni eraron. Ĉi tiu metodo montras ĉu la operacio de la dosiero estas ĝenerale aplikata sur la servilo.
- Kontrolu la funkciojn de specifaj ŝanĝoj, kiujn vi faris. Ekzemple, faru malgrandan ĝustigon al unu el la parametroj kaj taksu la ĉeeston de ŝanĝoj.
- Kontrolu la statuskodon de la paĝo se la ŝanĝoj rilatas al la respondo de la servilo. Kiel fari tion, ni antaŭe priskribis en la artikolo HTTP-Eraraj Kodoj: kompleta listo de servilaj eraroj.
- Vidu al la servilaj protokoloj. Ili montras ĉiujn erarojn rilatajn al la funkciado de la dosiero .htaccess.
- Faru provojn uzante interretajn servojn aŭ ilojn.
Gravas kompreni, ke por kontroli la funkciojn de la dosiero .htaccess, vi ne bezonas plenumi ĉiujn paŝojn samtempe. Sufiĉas elekti la plej taŭgan metodon el la listo kaj uzi ĝin.
konkludo
Agordi la dosieron .htaccess estas grava paŝo en optimumigo kaj protektado de via Apache-servilo. Ni esploris kiel ĉi tiu dosiero helpas administri alidirektilojn, kunpremi enhavon kaj certigi sekurecon. Post kiam vi majstras labori kun .htaccess, vi akiras potencan ilon por plibonigi la rendimenton kaj funkciecon de retejoj.