.htaccess beveiligen: wachtwoordbeveiliging en commando's voor websitebeveiliging

.htaccess beveiligen betekent in de praktijk: op Apache- of LiteSpeed-hosting een map afschermen met gebruikersnaam en wachtwoord, voorkomen dat het .htaccess-bestand van buitenaf kan worden gelezen, HTTPS verplicht maken en ongewenste toegang beperken. De bekendste toepassing is een map met .htaccess via Basic Auth met een wachtwoord beveiligen, terwijl de wachtwoorden in een .htpasswd-bestand worden opgeslagen. Belangrijk om meteen helder te hebben: Basic Auth versleutelt je gegevens niet op zichzelf. Voor veilig gebruik moet dit altijd via HTTPS met een actief SSL-certificaat draaien. SSL certificaat Veilige Web Hosting

Bij websitebeveiliging denken veel mensen direct aan grote firewalls, complexe software of dure beveiligingsplug-ins. Toch is een goed ingericht .htaccess-bestand, zeker bij shared hosting, WordPress, maatwerk-PHP-applicaties en websites van kleine bedrijven, vaak een van de eerste verdedigingslagen. Met dit bestand kun je kritieke mappen zoals een beheeromgeving met een wachtwoord beschermen, HTTP-verkeer naar HTTPS doorsturen, directory listing uitschakelen, toegang tot gevoelige bestanden blokkeren, hotlinking beperken en basisbeveiligingsheaders activeren.

In deze gids leggen we stap voor stap uit hoe .htaccess-wachtwoordbeveiliging werkt, welke beveiligingscommando’s in de praktijk het vaakst worden gebruikt en welke voorbeelden je veilig kunt kopiëren en aanpassen. De commando’s in dit artikel zijn vooral bedoeld voor hostingomgevingen met ondersteuning voor Apache mod_rewrite, mod_auth_basic en mod_headers. LiteSpeed-servers zijn grotendeels Apache-compatibel, waardoor de meeste regels daar op dezelfde manier werken. Maak vóór wijzigingen op een live website wel altijd een back-up van het bestand en test bij voorkeur eerst op een testsubdomein of stagingomgeving. Domeinbeheer website back-up

Wat is een .htaccess-bestand en waarom is het belangrijk voor beveiliging?

.htaccess is een lokaal configuratiebestand dat bepaalt hoe de webserver zich moet gedragen voor de betreffende map en de onderliggende mappen. Staat het bestand in de hoofdmap, dan beïnvloedt het meestal de hele website. Een .htaccess-bestand in de map public_html beheert bijvoorbeeld de regels die gelden voor de webroot van je domeinnaam. Plaats je het bestand in een submap, dan kan het alleen voor die map en de paden daaronder gelden.

Omdat je met dit bestand toegang op serverniveau kunt regelen, kunnen bepaalde verzoeken worden tegengehouden voordat ze je applicatiecode bereiken. Beveilig je bijvoorbeeld de admin-map met een wachtwoord, dan loopt een aanvaller al tegen serverauthenticatie aan voordat hij bij WordPress, een maatwerkpanel of een PHP-bestand komt. Die aanpak vermindert brute-forcepogingen en maakt het lastiger om kwetsbaarheden in de applicatielaag uit te buiten.

De belangrijkste beveiligingsvoordelen van .htaccess zijn:

• Je kunt toegangsregels instellen zonder de applicatiecode aan te passen.
• Specifieke mappen kunnen met gebruikersnaam en wachtwoord worden beschermd.
• HTTP-verzoeken kunnen automatisch naar HTTPS worden doorgestuurd.
• Directory listing, toegang tot gevoelige bestanden en hotlinking kunnen worden beperkt.
• Met beveiligingsheaders kan browsergedrag veiliger worden gemaakt.
• Je kunt beperkingen instellen op basis van IP-adres, bestandsextensie of requestmethode.

Tegelijkertijd is .htaccess geen complete beveiligingsoplossing op zichzelf. Het werkt het best in combinatie met actuele software, een sterk wachtwoordbeleid, regelmatige back-ups, betrouwbare hostinginfrastructuur, een WAF, malwarecontrole en een SSL-certificaat. Hostingbeveiliging WordPress veiligheid

De logica achter .htaccess-wachtwoordbeveiliging: Basic Auth en .htpasswd

De term .htaccess versleutelen of .htaccess beveiligen wordt vaak voor twee verschillende dingen gebruikt. Ten eerste: een map pas toegankelijk maken na invoer van een gebruikersnaam en wachtwoord. Ten tweede: voorkomen dat het .htaccess-bestand zelf van buitenaf bekeken kan worden. Het eerste gebeurt met Basic Auth, het tweede met regels die bestandstoegang blokkeren.

Bij Basic Auth bevat het .htaccess-bestand de authenticatieregels, terwijl het .htpasswd-bestand de gebruikersnaam en het gehashte wachtwoord bewaart. Wachtwoorden mogen niet als platte tekst worden opgeslagen. Moderne systemen gebruiken hashmethoden zoals bcrypt, Apache MD5 of SHA-gebaseerde varianten. De veiligste en meest gebruiksvriendelijke aanpak is vaak de functie voor mapbeveiliging of met wachtwoord beveiligde mappen in je hostingcontrolepaneel. Zulke panelen plaatsen het .htpasswd-bestand meestal op de juiste locatie en regelen het hashen van wachtwoorden automatisch.

Een voorbeeld van een eenvoudige wachtwoordbeveiligingsregel ziet er zo uit:

AuthType Basic

AuthName Beveiligd Gebied

AuthUserFile /home/gebruiker/.htpasswd

Require valid-user

De betekenis van deze vier regels is eenvoudig: het authenticatietype wordt ingesteld op Basic, de naam die de browser in het inlogvenster toont wordt bepaald, het volledige serverpad naar het .htpasswd-bestand wordt opgegeven en alleen geldige gebruikers krijgen toegang. De meest gemaakte fout zit in de regel AuthUserFile: daar hoort geen URL te staan. De juiste waarde is geen webadres, maar het fysieke bestandspad op de server. Dus https://voorbeeld.nl/.htpasswd is fout; /home/gebruiker/.htpasswd komt veel dichter in de buurt van het juiste formaat.

Waar bewaar je het .htpasswd-bestand?

Plaats het .htpasswd-bestand bij voorkeur buiten public_html. Daardoor kan het bestand, zelfs bij een onhandige serverconfiguratie, niet direct via het web worden opgevraagd. Draait je website bijvoorbeeld in /home/accountnaam/public_html, dan is /home/accountnaam/.htpasswd een veiligere locatie dan een plek binnen de webroot.

Voor bestandsrechten is 640 of 644 voor .htpasswd vaak een praktisch startpunt, en 644 voor .htaccess. Afhankelijk van de serverconfiguratie kunnen andere rechten nodig zijn. Rechten zoals 777, waarbij iedereen kan schrijven, vormen echter een duidelijk beveiligingsrisico en moeten worden vermeden.

Stap voor stap een map beveiligen met .htaccess

De onderstaande stappen zijn vooral geschikt voor gebruikers die een admin-, panel-, test-, staging-, rapportage- of klantmap willen afschermen. Maak voordat je begint een back-up van je bestaande .htaccess-bestand. Zelfs één verkeerd teken kan al leiden tot een 500 Internal Server Error.

1. Bepaal welke map je wilt beveiligen

Bepaal eerst exact welke map je met een wachtwoord wilt beschermen. Wil je bijvoorbeeld alleen voorbeeld.nl/admin beveiligen, dan kun je het .htaccess-bestand in de map admin plaatsen. Wil je tijdelijk de hele website afsluiten en alleen toegankelijk maken voor bevoegde personen, dan voeg je de regel toe aan het .htaccess-bestand in de hoofdmap.

2. Maak een .htpasswd-gebruiker aan

Heeft je hostingcontrolepaneel een functie voor met wachtwoord beveiligde mappen, dan is dat meestal de makkelijkste methode. Is zo’n tool er niet, dan kun je op servers met SSH-toegang een gebruiker aanmaken met het commando htpasswd. De basislogica is bijvoorbeeld: htpasswd -c /home/gebruiker/.htpasswd admin. Dit commando maakt een wachtwoord voor de gebruiker admin aan en slaat dit op in het bestand. Gebruik de parameter -c niet wanneer je een extra gebruiker aan een bestaand bestand toevoegt; anders kan het bestand opnieuw worden aangemaakt en overschreven.

3. Voeg de .htaccess-regel toe

Voeg in het .htaccess-bestand van de te beveiligen map de volgende regels toe:

AuthType Basic

AuthName Beheerpaneel

AuthUserFile /home/gebruiker/.htpasswd

Require valid-user

Sla het bestand op en open daarna de betreffende map in je browser. Verschijnt er een venster voor gebruikersnaam en wachtwoord, dan werkt de configuratie. Kun je ondanks het juiste wachtwoord niet inloggen, dan is waarschijnlijk het AuthUserFile-pad onjuist of kan de server het .htpasswd-bestand door de bestandsrechten niet lezen.

4. Gebruik dit nooit zonder HTTPS

Basic Auth verstuurt inloggegevens in Base64; dat is geen sterke versleuteling. Gaat het verkeer via HTTP, dan kan iemand die het netwerkverkeer onderschept de gebruikersnaam en het wachtwoord achterhalen. Daarom moet .htaccess-wachtwoordbeveiliging altijd worden gecombineerd met een verplichte HTTPS-verbinding. Op Hostragons kun je SSL activeren en daarna een HTTPS-redirectregel toevoegen om dit risico te verkleinen. SSL installatie HTTPS omleiding

HTTPS verplicht maken en www doorsturen

Een van de meest basale stappen om je website veiliger te maken, is al het verkeer naar HTTPS doorsturen. Nadat het SSL-certificaat actief is, kun je in het .htaccess-bestand in de hoofdmap een regel toevoegen volgens deze logica:

RewriteEngine On

RewriteCond %{HTTPS} off

RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Deze regel stuurt verzoeken die via HTTP binnenkomen door naar dezelfde domeinnaam en hetzelfde pad, maar dan via HTTPS. De 301-statuscode betekent een permanente redirect en geeft ook voor SEO het juiste signaal. Gebruik je echter een reverse proxy, CDN of load balancer, dan kan de HTTPS-status via andere headers worden doorgegeven. In zulke situaties is het beter om de redirectregel te gebruiken die je hostingprovider of CDN aanbeveelt.

Ook de keuze tussen wel of geen www moet consistent zijn. Wil je bijvoorbeeld al het verkeer naar de versie zonder www sturen, dan kun je deze aanpak gebruiken:

RewriteEngine On

RewriteCond %{HTTP_HOST} ^www\.voorbeeld\.nl$ [NC]

RewriteRule ^(.*)$ https://voorbeeld.nl/$1 [L,R=301]

Vervang voorbeeld.nl door je eigen domeinnaam. Combineer je HTTPS- en www-redirects, let er dan op dat je geen redirectketen maakt. De ideale configuratie brengt de bezoeker in één stap naar de uiteindelijke URL. Domein doorverwijzing SEO-vriendelijke omleiding

Basiscommando’s om je website met .htaccess beter te beveiligen

De onderstaande tabel vat de meest gebruikte .htaccess-beveiligingscommando’s samen en laat zien wanneer je ze toepast. Controleer vóór elke wijziging je bestaande configuratie; regels van WordPress, Laravel of een maatwerk-CMS kunnen soms botsen met nieuwe .htaccess-regels.

Directory listing uitschakelen

Als een map geen index.html, index.php of ander standaard startbestand bevat, kan de server soms de bestandenlijst tonen. Dat is riskant bij back-upbestanden, afbeeldingen, tijdelijke rapporten of oude broncode. Met een simpele regel kun je directory listing uitschakelen:

Options -Indexes

Na deze regel kunnen bezoekers de mapinhoud niet meer als lijst bekijken. In mappen zonder indexbestand verschijnt meestal een 403 Forbidden-reactie. Vanuit beveiligingsoogpunt is dat gewenst gedrag.

Toegang tot .htaccess en gevoelige bestanden blokkeren

Je .htaccess-bestand mag niet via het web zichtbaar zijn. Apache beschermt dit bestand doorgaans standaard, maar als extra beveiligingslaag kun je de volgende logica gebruiken:

<Files .htaccess>

Require all denied

</Files>

Hetzelfde geldt voor bestanden zoals .env, composer.json, composer.lock, config.php.bak, backup.sql en database.sql. Vooral bij Laravel, Symfony en maatwerk-PHP-applicaties kan een .env-bestand databasewachtwoorden, API-sleutels en SMTP-gegevens bevatten. Als zo’n bestand uitlekt, kan dat leiden tot volledige overname van de applicatie of serveromgeving.

Om meerdere gevoelige bestanden en extensies tegelijk te blokkeren, kun je deze logica toepassen:

<FilesMatch ^(\.env|composer\.(json|lock)|package\.json|yarn\.lock|.*\.sql|.*\.bak)$>

Require all denied

</FilesMatch>

Let er bij dit soort regels op dat je geen statische bestanden blokkeert die je applicatie echt nodig heeft. Als bijvoorbeeld verificatiebestanden of integratiebestanden per ongeluk binnen de regel vallen, kunnen externe diensten niet meer goed werken.

PHP-uitvoering in specifieke mappen blokkeren

Uploadmappen zijn een geliefd doelwit voor aanvallers. Als een systeem zwakke controles heeft op bestandsuploads en een schadelijk PHP-bestand wordt geüpload, dan vormt het uitvoeren van dat bestand een groot risico. In mappen waar alleen afbeeldingen of mediabestanden worden geplaatst, biedt het blokkeren van PHP-uitvoering een extra verdedigingslaag.

Plaats in de betreffende uploadmap een .htaccess-bestand en gebruik deze logica:

<FilesMatch \.php$>

Require all denied

</FilesMatch>

Deze regel blokkeert toegang tot PHP-bestanden in die specifieke map. Voor WordPress wordt een vergelijkbare aanpak vaak toegepast in wp-content/uploads. Test dit wel goed, omdat sommige plug-ins eigen bestandsverwerking kunnen gebruiken.

Hotlinking blokkeren om dataverkeer te verminderen

Hotlinking betekent dat andere websites jouw afbeeldingsbestanden direct op hun eigen pagina’s gebruiken. Daardoor verbruik jij bandbreedte, terwijl de afbeelding elders wordt getoond. Dit kan voor hogere belasting en slechtere prestaties zorgen. Een eenvoudige hotlink-beveiliging werkt volgens deze logica:

RewriteEngine On

RewriteCond %{HTTP_REFERER} !^$

RewriteCond %{HTTP_REFERER} !^https?://(www\.)?voorbeeld\.nl [NC]

RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [F,NC]

Deze regel blokkeert afbeeldingsverzoeken met een niet-lege referer die niet van jouw eigen domein komen. Gebruik je Google Afbeeldingen, sociale-mediapreviews, CDN-domeinen of partnersites, dan moet je die domeinen mogelijk op een whitelist plaatsen. Gebruik van CDN websiteprestaties

Specifieke IP-adressen toestaan of blokkeren

Wil je dat je adminpaneel alleen vanaf het IP-adres van je kantoor toegankelijk is, dan is IP-beperking een effectieve extra laag. Voor Apache 2.4 en hoger is de basislogica als volgt:

Require ip 203.0.113.10

Wanneer je deze regel alleen gebruikt, krijgt uitsluitend het opgegeven IP-adres toegang. Werk je met een dynamisch IP-adres, wees dan voorzichtig: zodra je IP verandert, kun je jezelf buitensluiten. In de praktijk is het vaak verstandiger om IP-beperking te combineren met wachtwoordbeveiliging.

Wil je een specifiek kwaadaardig IP-adres blokkeren, dan kan dat met deze logica:

<RequireAll>

Require all granted

Require not ip 198.51.100.25

</RequireAll>

IP-blokkering kan nuttig zijn bij kleinschalige aanvallen. Tegen botnets of aanvallen vanaf wisselende IP-adressen is het op zichzelf echter onvoldoende. In dat geval zijn een applicatiefirewall, rate limiting en server-side beveiligingsoplossingen effectiever.

Beveiligingsheaders: extra bescherming op browserniveau

.htaccess is niet alleen geschikt voor toegangscontrole, maar ook voor het beheren van browserbeveiligingsheaders. Als mod_headers actief is, verhogen de volgende headers op veel websites het basisbeveiligingsniveau:

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 beperkt dat browsers bestandstypen gaan raden en mogelijk verkeerd uitvoeren. X-Frame-Options SAMEORIGIN beperkt het insluiten van je site als iframe op andere domeinen en verkleint zo het risico op clickjacking. Referrer-Policy bepaalt welke refererinformatie bij doorklikken wordt gedeeld. Permissions-Policy beperkt browserrechten zoals camera, microfoon en locatie.

Content-Security-Policy, vaak afgekort tot CSP, is een krachtigere beveiligingsheader, maar moet voorzichtig worden toegepast. Een te strenge CSP kan advertenties, analytics, betaalproviders, livechat of fontdiensten breken. Daarom is het verstandig om eerst in report-onlymodus te testen en de policy daarna stapsgewijs live te zetten.

Checklist voordat je wijzigingen doorvoert

.htaccess-wijzigingen hebben direct effect. Werk daarom met een korte checklist voordat je beveiligingscommando’s toevoegt; zo verklein je de kans op downtime.

• Download een back-up van het bestaande .htaccess-bestand naar je computer.
• Controleer of je SSL-certificaat actief en correct geïnstalleerd is.
• Voeg redirectregels één voor één toe; wijzig niet alle regels tegelijk.
• Controleer 500-, 403- en 404-fouten in de browser en in de serverlogs.
• Verwijder niet per ongeluk de rewrite-regels van WordPress, Laravel of maatwerksoftware.
• Test of gebieden met wachtwoordbeveiliging alleen via HTTPS bereikbaar zijn.
• Gebruik je een CDN, cacheplug-in of beveiligingsplug-in, controleer dan mogelijke conflicten.
• Test inloggen, formulieren en betaalprocessen op mobiel, desktop en in verschillende browsers.

Regels stapsgewijs toepassen is in de praktijk erg belangrijk. Voeg bijvoorbeeld eerst Options -Indexes toe en test dat, voeg daarna de HTTPS-redirect toe en ga pas vervolgens door met wachtwoordbeveiliging. Als er dan een probleem ontstaat, kun je veel sneller achterhalen welke regel de oorzaak is.

Veelgemaakte fouten en hoe je ze oplost

500 Internal Server Error

Deze fout wordt meestal veroorzaakt door een syntaxfout, een niet-ondersteunde directive of het gebruik van een module die niet actief is. Gebruik je bijvoorbeeld het Header-commando terwijl mod_headers niet is ingeschakeld, dan kan dat een fout veroorzaken. Verwijder tijdelijk de laatst toegevoegde regels, bekijk de serverlogs en controleer of je hostingomgeving de betreffende module ondersteunt.

Het wachtwoordvenster blijft terugkomen

Als het inlogvenster steeds opnieuw verschijnt terwijl de gebruikersnaam en het wachtwoord kloppen, dan is het pad naar .htpasswd mogelijk verkeerd, ondersteunt de server het gebruikte wachtwoordhashformaat niet of zijn de bestandsrechten onjuist. Controleer vooral of AuthUserFile een volledig fysiek serverpad bevat.

De HTTPS-redirect veroorzaakt een oneindige lus

Bij websites achter een CDN of proxy kan de server het verzoek intern als HTTP zien en daardoor steeds opnieuw naar HTTPS proberen te redirecten. In zo’n geval is vaak een aangepaste regel nodig die rekening houdt met headers zoals X-Forwarded-Proto. Ook moet de SSL-modus in je CDN-paneel correct staan, bijvoorbeeld Full of Full Strict.

Afbeeldingen of CSS-bestanden laden niet

Als hotlinkregels, FilesMatch-regels of beveiligingsheaders te breed zijn geschreven, kunnen ook legitieme statische bestanden worden geblokkeerd. Open de Network-tab in de ontwikkelaarstools van je browser om te zien welk bestand met welke HTTP-statuscode wordt tegengehouden.

.htaccess-beveiliging voor WordPress-websites

Bij WordPress is het .htaccess-bestand cruciaal voor permalinks. Daarom moet je de regels tussen BEGIN WordPress en END WordPress niet onnodig aanpassen. Beveiligingsregels kun je meestal veiliger boven of onder deze blokken plaatsen.

Praktische maatregelen voor WordPress zijn onder meer:

• Extra Basic Auth-beveiliging toevoegen aan de map wp-admin.
• PHP-uitvoering blokkeren binnen wp-content/uploads.
• Toegang tot xmlrpc.php beperken als je dit bestand niet gebruikt.
• De zichtbaarheid van readme.html en licentiebestanden verminderen.
• HTTPS-redirects laten aansluiten op de WordPress-siteadressen.

Vooral bij wp-admin geeft de combinatie van een WordPress-gebruikerswachtwoord en .htaccess-wachtwoordbeveiliging een dubbele verdedigingslaag. Sommige plug-ins hebben echter toegang nodig tot wp-admin/admin-ajax.php. Als je de volledige wp-admin-map zonder testen afsluit, kunnen bepaalde functies kapotgaan. Test daarom altijd op de live situatie of eerst in een stagingomgeving. WordPress hosting WordPress versnelling

Professionele tips voor .htaccess-beveiliging

Ervaren systeembeheerders letten vooral op de balans tussen beveiliging en onderhoudbaarheid. Zeer agressieve regels kunnen op korte termijn veilig lijken, maar op lange termijn extra beheerlast en storingen veroorzaken. Noteer daarom bij elke regel het doel, de scope en het testresultaat.

• Maak vóór kritieke wijzigingen een gedateerde back-up, bijvoorbeeld htaccess-2026-01-15.bak.
• Vermijd honderden onnodige regels in één .htaccess-bestand.
• Houd bij 301-redirects rekening met browsercache en cache van zoekmachines, omdat ze permanent zijn.
• Controleer na het toevoegen van beveiligingsheaders de foutmeldingen in de browserconsole.
• Maak voor met wachtwoord beveiligde mappen liever persoonlijke gebruikers aan dan één gedeeld zwak wachtwoord.
• Sluit test-, staging- en back-upmappen op serverniveau af voordat zoekmachines ze kunnen vinden.

Een ander belangrijk punt is dat je beveiligingsregels regelmatig opnieuw beoordeelt. Een integratie die vandaag nodig is, kan morgen verwijderd zijn, terwijl een speciaal daarvoor opengezet pad in .htaccess vergeten wordt. Eens per kwartaal een korte beveiligingscontrole uitvoeren, overbodige toestemmingen opruimen en oude redirects bijwerken is een gezonde gewoonte.

Conclusie: een klein bestand, een stevige beveiligingslaag

.htaccess-wachtwoordbeveiliging en commando’s om je website beter te beveiligen versterken, mits goed toegepast, de eerste verdedigingslinie van je website. Mappen met een wachtwoord beschermen, HTTPS verplicht maken, directory listing uitschakelen, toegang tot gevoelige bestanden blokkeren en beveiligingsheaders activeren zijn voor de meeste websites haalbare, meetbare en effectieve stappen.

Toch is .htaccess-beveiliging alleen niet genoeg. Zie het als onderdeel van een breder geheel met betrouwbare hostinginfrastructuur, actuele software, een SSL-certificaat, regelmatige back-ups en een sterk wachtwoordbeleid. Wanneer je je website bij Hostragons host, kun je belangrijke beveiligingsonderdelen zoals SSL, hosting en domeinbeheer vanuit één paneel beheren en stap voor stap naar een veiligere configuratie toewerken. Web hosting pakketten Koop domein SSL certificaten

Veelgestelde vragen

Versleutelt .htaccess-beveiliging mijn bestanden echt?

Nee. Meestal bedoelt men hiermee dat mappen met gebruikersnaam en wachtwoord worden afgeschermd. Basic Auth beperkt de toegang; voor veilige gegevensoverdracht is SSL met HTTPS noodzakelijk.

Is het veilig om het .htpasswd-bestand binnen public_html te bewaren?

Dat wordt afgeraden. De veiligste aanpak is om .htpasswd buiten public_html te plaatsen, in een map die niet direct via het web bereikbaar is. Zo verklein je ook bij een verkeerde configuratie de kans dat het bestand zichtbaar wordt.

Wat moet ik doen als ik na een .htaccess-wijziging een 500-fout krijg?

Verwijder eerst de laatst toegevoegde regels of zet je back-up terug. Controleer daarna de serverlogs. De oorzaak is meestal een typefout, een niet-ondersteunde directive of een Apache-module die niet actief is.

Is het verstandig om de WordPress-map wp-admin met .htaccess te beveiligen?

Ja, het kan een extra beveiligingslaag bieden. Omdat sommige plug-ins bestanden zoals admin-ajax.php nodig hebben, moet je na de wijziging wel inloggen, reacties, winkelwagen, betalingen en formulieren zorgvuldig testen.

Is een HTTPS-redirect schadelijk voor SEO?

Nee, een correct ingestelde 301-redirect naar HTTPS is niet schadelijk. Het zorgt juist voor een veilige en consistente URL-structuur. Belangrijk is dat je geen redirectketens maakt en dat interne links naar de uiteindelijke HTTPS-adressen verwijzen.