Protejarea prin .htaccess, în hostingul bazat pe Apache sau LiteSpeed, reprezintă ansamblul metodelor practice de securitate folosite pentru a bloca un director cu nume de utilizator și parolă, a împiedica citirea fișierului .htaccess din exterior, a forța conexiunea HTTPS și a limita accesările malițioase. Cea mai întâlnită aplicație este protejarea cu parolă a accesului la un director prin Basic Auth și stocarea parolelor în fișierul .htpasswd. Totuși, un aspect crucial este acesta: Basic Auth singur nu criptează datele; pentru o utilizare sigură, trebuie să funcționeze neapărat peste HTTPS, alături de un certificat SSL. certificat SSL găzduire web sigură
Securitatea site-urilor web este adesea asociată cu firewall-uri masive, software complex sau pluginuri costisitoare. În realitate, un fișier .htaccess configurat corect reprezintă unul dintre primele straturi de apărare, în special pe hostingul partajat, WordPress, aplicațiile PHP personalizate și site-urile de mici afaceri. Cu acest fișier poți proteja cu parolă directoare critice precum panoul de administrare, redirecționa traficul HTTP către HTTPS, dezactiva listarea directoarelor, bloca accesul la anumite fișiere, reduce hotlink-ul și activa headere de securitate de bază.
În acest ghid vom aborda pas cu pas procesul de securizare cu .htaccess, vom explica cele mai frecvente comenzi de securitate din viața reală și vom împărtăși exemple pe care le poți copia și adapta. Comenzile din conținut sunt potrivite în special pentru mediile de hosting care suportă modulele Apache mod_rewrite, mod_auth_basic și mod_headers. Servere LiteSpeed sunt, de asemenea, compatibile în mare măsură cu Apache, așa că majoritatea regulilor funcționează identic. Totuși, înainte de a aplica pe site-ul live, este recomandat să faci neapărat o copie de rezervă a fișierului și, dacă este posibil, să testezi pe un subdomeniu de test. administrare domeniu backup site web
Ce este fișierul .htaccess și de ce este important pentru securitate?
.htaccess este un fișier de configurare locală care dictează comportamentul serverului web pentru directorul respectiv și subdirectoarele sale. Când este plasat în directorul rădăcină, afectează de obicei întregul site; de exemplu, fișierul .htaccess din directorul public_html gestionează regulile care rulează la rădăcina web principală a domeniului tău. Când este pus într-un subdirector, poate fi valabil doar pentru acel director și căile din interiorul său.
Deoarece cu acest fișier se poate realiza controlul accesului la nivel de server, anumite cereri pot fi blocate înainte de a ajunge la codul aplicației. De exemplu, dacă protejezi cu parolă directorul admin, atacatorul va fi oprit de autentificarea serverului înainte de a ajunge la WordPress, panoul personalizat sau fișierul tău PHP. Această abordare reduce tentativele de atac prin forță brută și îngreunează exploatarea vulnerabilităților de la nivelul aplicației.
Avantajele proeminente ale fișierului .htaccess din punct de vedere al securității sunt:
- Regulile de acces pot fi definite fără a modifica codul aplicației.
- Anumite directoare pot fi protejate cu nume de utilizator și parolă.
- Cererile HTTP pot fi redirecționate automat către HTTPS.
- Listarea directoarelor, accesul la fișiere sensibile și utilizarea hotlink pot fi limitate.
- Comportamentul browserului poate fi făcut mai sigur prin headere de securitate.
- Se pot aplica restricții în funcție de adresa IP, extensia fișierului sau metoda de cerere.
Cu toate acestea, .htaccess nu asigură singur toată securitatea. Oferă cele mai eficiente rezultate atunci când este utilizat împreună cu software actualizat, o politică de parole puternice, backup regulat, infrastructură de hosting de încredere, WAF, scanare de malware și certificat SSL. securitate hosting securitate WordPress
Logica securizării cu .htaccess: Basic Auth și .htpasswd
Expresia securizare prin fișier .htaccess are de obicei două sensuri distincte. Primul, solicitarea unui nume de utilizator și a unei parole la intrarea într-un director; al doilea, împiedicarea vizualizării fișierului .htaccess în sine din exterior. Prima operațiune se face cu Basic Auth, iar a doua cu reguli de restricționare a accesului la fișiere.
În structura Basic Auth, fișierul .htaccess conține regula de autentificare, iar fișierul .htpasswd stochează informațiile despre numele de utilizator și parola criptată. Parola nu trebuie păstrată în text simplu. Pe sistemele moderne se folosesc metode de hash precum bcrypt, Apache MD5 sau bazate pe SHA. Cea mai sigură abordare este ca panoul de control al hostingului să folosească funcția de confidențialitate a directorului sau de director protejat cu parolă; deoarece aceste panouri plasează adesea fișierul .htpasswd în locația corectă și efectuează automat procesul de criptare a parolei.
Un exemplu de regulă de protejare cu parolă este următorul:
AuthType Basic
AuthName Zona Protejata
AuthUserFile /home/utilizator/.htpasswd
Require valid-user
Semnificația acestor patru linii este simplă: tipul de autentificare este setat ca Basic, se definește numele zonei care apare în browser, se indică calea completă de server către fișierul .htpasswd care conține parolele utilizatorilor și se permite accesul doar utilizatorilor valizi. Cea mai frecventă greșeală aici este scrierea unei adrese URL pe linia AuthUserFile. Valoarea corectă nu este o adresă web, ci calea fizică a fișierului de pe server. De exemplu, https://nume-site.com/.htpasswd este incorect; /home/utilizator/.htpasswd este aproape de formatul corect.
Unde ar trebui păstrat fișierul .htpasswd?
Păstrează fișierul .htpasswd în afara directorului public_html, dacă este posibil. Astfel, chiar și în cazul unei configurări greșite a serverului, fișierul nu poate fi accesat direct prin web. De exemplu, dacă site-ul tău rulează în /home/contutilizator/public_html, este mai sigur să plasezi fișierul .htpasswd în afara rădăcinii web, cum ar fi /home/contutilizator/.htpasswd.
În ceea ce privește permisiunile fișierelor, o valoare practică de pornire poate fi 640 sau 644 pentru .htpasswd și 644 pentru .htaccess. În funcție de configurația serverului, pot fi necesare permisiuni diferite; totuși, permisiunile 777, care permit scrierea de către oricine, creează un risc de securitate și nu ar trebui folosite.
Protejarea directoarelor cu .htaccess pas cu pas
Pașii de mai jos sunt potriviți în special pentru utilizatorii care doresc să protejeze directoare precum admin, panel, test, staging, rapoarte sau fișiere dedicate clienților. Înainte de a începe operațiunea, fă o copie de rezervă a fișierului .htaccess existent. Chiar și un caracter greșit poate cauza o eroare 500 Internal Server Error.
1. Stabilește directorul de protejat
Mai întâi clarifică ce director vrei să securizezi. De exemplu, dacă vrei să protejezi doar zona nume-site.com/admin, poți plasa fișierul .htaccess în interiorul directorului admin. Dacă vrei să închizi temporar întregul site și să-l deschizi doar pentru persoanele autorizate, poți adăuga regula în fișierul .htaccess din directorul rădăcină.
2. Creează un utilizator .htpasswd
Dacă panoul de control al hostingului are un instrument pentru directoare protejate cu parolă, aceasta este cea mai practică metodă. Dacă nu există un astfel de instrument, pe serverele cu acces SSH se poate crea un utilizator cu comanda htpasswd. Un exemplu de logică este următorul: htpasswd -c /home/utilizator/.htpasswd admin. Această comandă generează o parolă pentru utilizatorul admin și o salvează în fișier. Când adaugi un utilizator nou la un fișier existent, nu folosi parametrul -c; altfel, fișierul poate fi recreat.
3. Adaugă regula .htaccess
Adaugă următoarele linii în fișierul .htaccess din directorul care va fi protejat:
AuthType Basic
AuthName Panou Administrare
AuthUserFile /home/utilizator/.htpasswd
Require valid-user
După salvare, intră în directorul respectiv din browser. Dacă apare ecranul pentru nume de utilizator și parolă, operațiunea a reușit. Dacă nu te poți autentifica deși parola este corectă, calea AuthUserFile poate fi greșită sau permisiunile fișierului .htpasswd nu pot fi citite de către server.
4. Nu folosi fără HTTPS
Basic Auth transportă credențialele în Base64; aceasta nu este o criptare puternică în sens real. Dacă traficul trece prin HTTP, cineva care monitorizează rețeaua poate captura numele de utilizator și parola. Din acest motiv, regula de securizare cu fișier .htaccess trebuie aplicată întotdeauna împreună cu forțarea HTTPS. Poți reduce acest risc activând SSL pe platforma Hostragons și adăugând apoi o regulă de redirecționare HTTPS. instalare SSL redirecționare HTTPS
Forțarea HTTPS și redirecționarea www
Unul dintre cei mai de bază pași pentru creșterea securității site-ului este redirecționarea întregului trafic către HTTPS. După ce certificatul SSL este activ, se poate adăuga o regulă cu următoarea logică în fișierul .htaccess din directorul rădăcină:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Această regulă mută cererile venite prin HTTP către HTTPS pe același nume de domeniu și aceeași cale. Redirecționarea permanentă 301 oferă semnalul corect și din punct de vedere SEO. Totuși, dacă site-ul tău folosește reverse proxy, CDN sau load balancer, starea HTTPS poate fi citită din headere diferite. În astfel de cazuri, ar trebui preferată regula de redirecționare recomandată de furnizorul de hosting.
Preferința pentru domeniul cu sau fără www trebuie să fie, de asemenea, consecventă. De exemplu, dacă vrei să muți tot traficul către versiunea fără www, se poate folosi următoarea abordare:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.domeniuexemplu\.com$ [NC]
RewriteRule ^(.*)$ https://domeniuexemplu.com/$1 [L,R=301]
Aici trebuie să înlocuiești domeniuexemplu.com cu propriul tău nume de domeniu. Dacă faci simultan atât redirecționarea HTTPS cât și cea www, ai grijă să nu creezi un lanț de redirecționări. Structura ideală îl duce pe utilizator la URL-ul final într-un singur pas. redirecționare domeniu redirecționare compatibilă SEO
Comenzi de bază care cresc securitatea site-ului cu .htaccess
Tabelul de mai jos rezumă cele mai frecvent utilizate comenzi de securitate .htaccess și când ar trebui aplicate. Înainte de a adăuga fiecare comandă, verifică-ți configurația existentă; există posibilitatea unor conflicte cu unele reguli WordPress, Laravel sau CMS-uri personalizate.
| Scop | Exemplu de comandă sau directivă | Când se folosește? | Aspect de reținut |
|---|---|---|---|
| Protejare director | AuthType Basic, Require valid-user | Directoare admin, staging, rapoarte | Trebuie folosit neapărat împreună cu HTTPS |
| Forțare HTTPS | RewriteCond %{HTTPS} off | Pentru a securiza întregul trafic al site-ului | Dacă există CDN, poate fi necesară o regulă specială |
| Dezactivare listare director | Options -Indexes | În directoarele fără fișier index | Împiedică vizualizarea structurii de fișiere |
| Protejare .htaccess | Require all denied | Pentru a preveni citirea fișierelor de configurare | Sintaxa poate varia în funcție de versiunea Apache |
| Blocare hotlink | RewriteCond %{HTTP_REFERER} | Pentru a reduce utilizarea imaginilor pe alte site-uri | Testează previzualizările CDN și rețele sociale |
| Headere de securitate | Header set X-Frame-Options SAMEORIGIN | Pentru a reduce atacurile bazate pe browser | mod_headers trebuie să fie activ |
Dezactivarea listării directoarelor
Dacă într-un director nu există index.html, index.php sau un fișier de intrare implicit, serverul poate afișa lista de fișiere. Această situație este riscantă în ceea ce privește fișierele de backup, imaginile, rapoartele temporare sau codurile sursă vechi. Listarea directoarelor poate fi dezactivată cu o comandă simplă:
Options -Indexes
După această linie, utilizatorii nu vor mai putea lista conținutul directorului. În directoarele fără un fișier index, se va vedea de obicei un răspuns 403 Forbidden. Acest comportament este de dorit din punct de vedere al securității.
Blocarea accesului la .htaccess și fișierele sensibile
Fișierul tău .htaccess nu ar trebui să fie vizibil prin web. Apache protejează de obicei acest fișier în mod implicit; totuși, ca un strat suplimentar de securitate, se poate folosi următoarea logică:
<Files .htaccess>
Require all denied
</Files>
Similar, fișiere precum .env, composer.json, composer.lock, config.php.bak, backup.sql, database.sql ar trebui, de asemenea, blocate de la accesul extern. În special în aplicațiile Laravel, Symfony sau PHP personalizate, fișierul .env poate conține parola bazei de date, chei API și informații SMTP. Scurgerea acestui fișier poate duce până la compromiterea întregului sistem.
Pentru a bloca extensii multiple de fișiere sensibile, se poate aplica următoarea logică:
<FilesMatch ^(\.env|composer\.(json|lock)|package\.json|yarn\.lock|.*\.sql|.*\.bak)$>
Require all denied
</FilesMatch>
Când adaugi astfel de reguli, asigură-te că nu blochezi fișierele statice de care aplicația ta are cu adevărat nevoie. De exemplu, unele fișiere de verificare sau integrare pot fi incluse accidental în domeniul de aplicare, iar serviciile terțe ar putea să nu mai funcționeze.
Dezactivarea rulării PHP în anumite directoare
Directoarele de upload sunt una dintre zonele cele mai vizate de atacatori. Dacă un sistem cu un control slab al încărcării fișierelor permite încărcarea unui fișier PHP malițios, executarea acestuia reprezintă un risc major. Dezactivarea rulării PHP în directoarele unde se încarcă imagini sau media oferă o apărare suplimentară.
Poți plasa un fișier .htaccess în directorul de upload respectiv și aplica următoarea logică:
<FilesMatch \.php$>
Require all denied
</FilesMatch>
Această regulă blochează accesul la fișierele PHP din directorul respectiv. Pentru WordPress, o abordare similară este frecvent utilizată în directorul wp-content/uploads; totuși, trebuie testată deoarece unele pluginuri pot avea nevoi speciale de procesare a fișierelor.
Reducerea consumului de trafic prin blocarea hotlink
Hotlink-ul reprezintă utilizarea directă a fișierelor tale media de către alte site-uri pe paginile lor. Această situație crește consumul de lățime de bandă și poate duce la probleme de performanță. O regulă simplă de blocare a hotlink-ului are următoarea logică:
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?domeniuexemplu\.com [NC]
RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [F,NC]
Această regulă blochează cererile pentru imagini care vin cu un referer ne-gol și care nu provin de pe numele tău de domeniu. Totuși, dacă ai Google Images, previzualizări pentru social media, domenii CDN sau parteneri de afaceri, poate fi necesar să adaugi aceste domenii pe lista albă. utilizare CDN performanță site web
Permiterea sau blocarea anumitor adrese IP
Dacă dorești să accesezi panoul de administrare doar de la adresa IP a biroului, restricția IP este un strat suplimentar eficient. Pentru Apache 2.4 și versiunile ulterioare, logica de bază este următoarea:
Require ip 203.0.113.10
Când această regulă este folosită singură, permite doar adresa IP specificată. Dacă folosești IP dinamic, fii atent; când IP-ul se schimbă, s-ar putea să nu-ți mai poți accesa panoul. Pentru o utilizare mai flexibilă, poate fi mai sănătos să aplici restricția IP împreună cu protecția prin parolă.
Pentru a bloca o anumită adresă IP rău intenționată, se poate folosi următoarea logică:
<RequireAll>
Require all granted
Require not ip 198.51.100.25
</RequireAll>
Blocarea IP funcționează în atacurile la scară mică; dar nu este suficientă singură împotriva atacurilor de tip botnet sau care folosesc IP-uri variabile. În acest caz, firewall-ul pentru aplicații, limitarea ratei și soluțiile de securitate la nivel de server sunt mai eficiente.
Headere de securitate: Protecție suplimentară la nivel de browser
.htaccess poate fi folosit nu doar pentru controlul accesului, ci și pentru gestionarea headere-lor de securitate ale browserului. Dacă mod_headers este activ, următoarele headere cresc nivelul de securitate de bază pe multe site-uri:
Header always set X-Content-Type-Options nosniff
Header always set X-Frame-Options SAMEORIGIN
Header always set Referrer-Policy strict-origin-when-cross-origin
Header always set Permissions-Policy geolocation=(), microphone=(), camera=()
X-Content-Type-Options nosniff reduce tendința browserului de a ghici și executa tipurile de fișiere. X-Frame-Options SAMEORIGIN limitează încorporarea site-ului tău ca iframe în alte domenii și reduce riscul de clickjacking. Referrer-Policy controlează ce informații de referer sunt partajate în timpul redirecționării. Permissions-Policy restricționează permisiunile browserului, cum ar fi camera, microfonul și locația.
Content-Security-Policy, adică CSP, este un header de securitate mai puternic; totuși, trebuie aplicat cu atenție. Un CSP prea strict poate perturba funcționarea reclamelor, analiticelor, plăților, suportului live sau serviciilor de fonturi. Din acest motiv, este mai corect să testezi mai întâi în modul de raportare și apoi să treci treptat în producție.
Lista de verificare înainte de implementare

Modificările .htaccess au efect rapid. De aceea, înainte de a adăuga comenzi de securitate, să acționezi pe baza unei liste scurte de verificare reduce riscul de întrerupere.
- Descarcă pe computer o copie de rezervă a fișierului .htaccess existent.
- Verifică dacă certificatul SSL este activ și instalat corect.
- Adaugă regulile de redirecționare una câte una; nu modifica toate regulile simultan.
- Verifică erorile 500, 403 și 404 din browser și din jurnalele de erori ale serverului.
- Nu șterge regulile de rescriere proprii WordPress, Laravel sau ale software-ului personalizat.
- Testează forțarea HTTPS în zonele unde folosești protecția prin parolă.
- Dacă folosești CDN, plugin de cache și plugin de securitate, evaluează posibilitatea de conflict.
- Testează fluxurile de autentificare, formulare și plată pe mobil, desktop și browsere diferite.
Aplicarea regulilor pe bucăți este foarte importantă în practică. De exemplu, adaugă mai întâi Options -Indexes și testează, apoi adaugă redirecționarea HTTPS, apoi treci la protecția prin parolă. Astfel, când apare o problemă, poți găsi rapid care linie a cauzat-o.
Cele mai frecvente greșeli și soluțiile lor
500 Internal Server Error
Această eroare provine de obicei dintr-o greșeală de sintaxă, o directivă nesuportată sau utilizarea unui modul greșit. De exemplu, folosirea comenzii Header când mod_headers nu este activ poate genera o eroare. Pentru rezolvare, elimină temporar ultimele linii adăugate, examinează jurnalele de erori ale serverului și verifică dacă mediul de hosting suportă modulul respectiv.
Ecranul de parolă revine constant
Dacă ecranul de autentificare reapare continuu deși numele de utilizator și parola sunt corecte, calea către .htpasswd poate fi greșită, formatul hash al parolei poate să nu fie suportat de server sau permisiunile fișierului sunt incorecte. Asigură-te că folosești calea fizică completă pe linia AuthUserFile.
Redirecționarea HTTPS creează o buclă infinită
Pe site-urile din spatele unui CDN sau proxy, serverul poate vedea cererea intern ca HTTP și poate încerca să redirecționeze constant către HTTPS. În acest caz, poate fi necesară o regulă specială care să țină cont de headere precum X-Forwarded-Proto. De asemenea, este important ca modul SSL din panoul CDN să fie la un nivel corect, cum ar fi Full sau Full Strict.
Imaginile sau fișierele CSS nu se încarcă
Dacă regulile de hotlink, FilesMatch sau headerele de securitate au fost scrise prea larg, fișierele statice legitime pot fi și ele blocate. Verificând secțiunea Network din uneltele de dezvoltator ale browserului, poți vedea care fișier este blocat și cu ce cod HTTP.
Securitatea .htaccess pe site-urile WordPress
Pe site-urile WordPress, fișierul .htaccess este de o importanță critică pentru linkurile permanente. Din acest motiv, nu este necesar să modifici inutil regulile create de WordPress între etichetele BEGIN WordPress și END WordPress. Este mai sigur să adaugi regulile de securitate de obicei deasupra sau dedesubtul acestor blocuri.
Măsurile practice ce pot fi aplicate pentru WordPress sunt:
- Aplicarea unei protecții suplimentare Basic Auth pe directorul wp-admin.
- Dezactivarea rulării PHP în wp-content/uploads.
- Restricționarea accesului la xmlrpc.php dacă nu îl folosești.
- Reducerea vizibilității fișierelor readme.html și a fișierelor de licență.
- Armonizarea redirecționării HTTPS cu adresele site-ului WordPress.
În special pentru wp-admin, folosirea atât a parolei de utilizator WordPress, cât și a protecției prin parolă .htaccess oferă o apărare pe două niveluri. Totuși, deoarece unele pluginuri care folosesc AJAX au nevoie de fișierul wp-admin/admin-ajax.php, blocarea completă a întregului director wp-admin poate perturba unele funcționalități. Prin urmare, testarea pe site-ul live este obligatorie. hosting WordPress optimizare viteză WordPress
Sfaturi profesionale pentru securitatea .htaccess
Subiectul căruia administratorii de sistem experimentați îi acordă cea mai mare atenție este echilibrul dintre securitate și sustenabilitate. Regulile prea agresive pot părea sigure pe termen scurt, dar pot crește costurile de întreținere pe termen lung. De aceea, scopul, domeniul de aplicare și rezultatul testului fiecărei reguli ar trebui notate.
- Fă o copie de rezervă datată înainte de modificările critice: cum ar fi htaccess-2026-01-15.bak.
- Evită să adaugi sute de reguli inutile într-un singur fișier .htaccess.
- Deoarece redirecționările 301 sunt permanente, ține cont de cache-ul browserului și al motorului de căutare.
- După adăugarea headere-lor de securitate, verifică erorile din consola browserului.
- În directoarele protejate cu parolă, creează utilizatori individuali în loc să folosești parole slabe partajate.
- Închide directoarele de test, staging și backup la nivel de server înainte de a le bloca pentru motoarele de căutare.
Un alt punct important este revizuirea periodică a regulilor de securitate. O integrare folosită astăzi poate fi eliminată mâine; totuși, o cale lăsată deschisă special pentru ea poate fi uitată în .htaccess. A face un scurt control de securitate la fiecare trei luni, a curăța permisiunile inutile și a reorganiza redirecționările vechi este un obicei bun.
Concluzie: Un fișier mic, un strat mare de securitate
Comenzile de securizare și creștere a securității site-ului cu fișierul .htaccess, atunci când sunt folosite corect, întăresc prima linie de apărare a site-ului tău web împotriva atacurilor. Protejarea directoarelor cu parolă, forțarea HTTPS, dezactivarea listării directoarelor, blocarea accesului la fișierele sensibile și activarea headere-lor de securitate sunt pași aplicabili, măsurabili și eficienți pentru majoritatea site-urilor web.
Cu toate acestea, securitatea .htaccess singură nu este suficientă. Trebuie gândită împreună cu o infrastructură de hosting de încredere, software actualizat, certificat SSL, backup regulat și o politică de parole puternice. Găzduindu-ți site-ul web pe Hostragons, poți gestiona dintr-un singur panou componente de securitate de bază precum SSL, hostingul și administrarea domeniului; și poți avansa pas cu pas către o structură mai sigură atunci când ai nevoie. pachete găzduire web cumpără domeniu certificate SSL
Întrebări frecvente
Securizarea cu fișierul .htaccess criptează cu adevărat fișierele?
Nu. De obicei, această expresie este folosită cu sensul de protejare a directoarelor cu nume de utilizator și parolă. Basic Auth limitează accesul; pentru ca transferul de date să fie sigur, este necesară utilizarea SSL cu HTTPS.
Este sigur să păstrez fișierul .htpasswd în interiorul public_html?
Nu este recomandat. Cea mai sigură abordare este să păstrezi fișierul .htpasswd în afara public_html, într-un director care nu poate fi accesat direct prin web. Astfel, chiar și în cazul unui risc de configurare greșită, probabilitatea ca fișierul să fie vizualizat scade.
Ce ar trebui să fac dacă primesc o eroare 500 după modificarea .htaccess?
Mai întâi elimină ultimele linii adăugate sau revin-o la fișierul de backup. Apoi verifică jurnalele de erori ale serverului. Eroarea provine cel mai adesea dintr-o greșeală de tastare, o directivă nesuportată sau un modul Apache inactiv.
Este corect să securizez directorul wp-admin WordPress cu .htaccess?
Da, poate oferi un strat suplimentar de securitate. Totuși, deoarece unele pluginuri au nevoie de fișiere precum admin-ajax.php, după implementare trebuie testate neapărat operațiunile de autentificare, comentarii, coș, plată și formulare.
Redirecționarea HTTPS este dăunătoare din punct de vedere SEO?
O redirecționare 301 HTTPS aplicată corect nu este dăunătoare; dimpotrivă, oferă o structură URL sigură și consecventă. Important este să nu creezi un lanț de redirecționări și să menții toate linkurile interne compatibile cu adresele HTTPS finale.