HTTP-headers toevoegen
Deze tekst is vertaald met AI. Als je de oorspronkelijke tekst in het Engels wilt bekijken, klik dan hier.
Deze handleiding laat zien hoe je HTTP-kopteksten aan je WordPress.com-website toevoegt om verschillende aanvragen en reacties te verwerken.
Over HTTP-kopteksten
HTTP-kopteksten geven aanvullende informatie door naast een HTTP-aanvraag of -reactie op je website. HTTP-kopteksten geven je site instructies over hoe bepaalde aanvragen moeten worden verwerkt en hoe informatie moet worden verzameld, afhankelijk van de bron, service of het sociale netwerk waar de koptekstcode vandaan komt.
De meeste HTTP-kopteksten zijn geoptimaliseerd op WordPress.com en hoeven niet te worden gewijzigd, maar veel kunnen ook op je website worden toegepast of aangepast als je dat nodig hebt. Houd er rekening mee dat sommige HTTP-koptekstcodes niet kunnen worden aangepast op WordPress.com als ze een beveiligingsrisico vormen of conflicteren met andere functies op het WordPress.com-platform.
Lijst met veelvoorkomende HTTP-kopteksten
Hieronder staat een tabel met veelvoorkomende HTTP-kopteksten die op je site kunnen worden toegepast, met relevante opmerkingen over welke HTTP-kopteksten niet kunnen worden gewijzigd op WordPress.com. Je kunt ook meer lezen over verschillende HTTP-kopteksten van MDN.
| Koptekst | Beschrijving |
|---|---|
| X-Robots-Tag | Geeft aan hoe een webpagina wordt geïndexeerd in openbare zoekresultaten. De HTTP-koptekst is feitelijk gelijkwaardig aan <meta name="robots" content="...">. |
| Access-Control-Allow-Headers | Wordt gebruikt als reactie op een preflight-aanvraag, die de Access-Control-Request-Headers bevat om aan te geven welke HTTP-kopteksten tijdens de daadwerkelijke aanvraag kunnen worden gebruikt. |
| Access-Control-Allow-Methods | Specificeert een of meer methoden die zijn toegestaan bij toegang tot een resource als reactie op een preflight-aanvraag. |
| Access-Control-Allow-Credentials | Vertelt browsers of de reactie aan de frontend-JavaScript-code moet worden blootgesteld wanneer de credentials-modus van de aanvraag (Request.credentials) include is. |
| Access-Control-Allow-Origin | Geeft aan of de reactie kan worden gedeeld met aanvragende code van de opgegeven origin. |
| Access-Control-Expose-Headers | Stelt een server in staat aan te geven welke reactiekopteksten beschikbaar moeten worden gemaakt voor scripts die in de browser worden uitgevoerd als reactie op een cross-origin-aanvraag. |
| X-Frame-Options | Geeft aan of een browser een pagina wel of niet mag weergeven in een <frame>, <iframe>, <embed> of <object>. Sites kunnen dit gebruiken om clickjacking-aanvallen te voorkomen door ervoor te zorgen dat hun content niet in andere sites wordt ingesloten. |
| X-XSS-Protection | Een functie van Internet Explorer, Chrome en Safari die voorkomt dat pagina’s worden geladen wanneer ze gereflecteerde cross-site scripting-aanvallen (XSS) detecteren. Deze beveiligingen zijn grotendeels overbodig in moderne browsers wanneer sites een sterk Content-Security-Policy implementeren dat het gebruik van inline JavaScript (‘unsafe-inline’) uitschakelt. |
| X-Content-Type-Options | Geeft aan dat de MIME-typen die in de Content-Type-kopteksten worden aangekondigd, moeten worden gevolgd en niet mogen worden gewijzigd. Met de HTTP-koptekst kun je MIME-type sniffing voorkomen door aan te geven dat de MIME-typen bewust zijn geconfigureerd. |
| Strict-Transport-Security | Informeert browsers dat de site alleen via HTTPS mag worden geopend en dat toekomstige pogingen om de site via HTTP te openen automatisch naar HTTPS moeten worden omgezet. Opmerking: Neem contact op met support om includeSubdomains en preload directives toe te voegen. |
| Referrer-Policy | Bepaalt hoeveel referrer-informatie (verzonden met de Referer-koptekst) moet worden opgenomen in aanvragen. Naast de HTTP-koptekst kun je dit beleid in HTML instellen. |
| Content-Security-Policy | Stelt websitebeheerders in staat te bepalen welke resources de user agent voor een bepaalde pagina kan laden. Op een paar uitzonderingen na gaan beleidsregels vooral over het specificeren van server-origins en script-endpoints. Dit helpt beschermen tegen cross-site scripting-aanvallen. Dit kan worden aangepast met een plugin zoals Redirection of met custom-redirects.php. |
HTTP-kopteksten aan een website toevoegen
Er zijn twee methoden die je kunt gebruiken om een HTTP-responsheader aan je site toe te voegen.
HTTP-kopteksten toevoegen met een Redirection-plugin
Hoewel er verschillende manieren zijn om HTTP-kopteksten toe te voegen aan een website waarop plugins zijn ingeschakeld, raden we aan de Redirection-plugin te gebruiken.
Hoewel de naam van de Redirection-plugin suggereert dat deze alleen voor redirects is bedoeld, kun je deze plugin veilig gebruiken om HTTP-kopteksten toe te passen zonder ook maar één redirect te gebruiken. Als je ervoor kiest om alleen HTTP-kopteksten toe te passen, worden je pagina’s niet beïnvloed door redirects.
Nadat je de Redirection-plugin hebt geïnstalleerd, kun je de volgende stappen uitvoeren om een HTTP-koptekst toe te voegen:
- Ga naar de plugin-instellingen door te navigeren naar Gereedschap → Redirection.
- Klik op het tabblad “Site (Site)”.
- Scrol omlaag naar de sectie “HTTP Headers (HTTP-kopteksten)” onderaan het scherm. Hier vind je vervolgens een tabel met een rij voor elke HTTP-koptekst op je site.
- Klik op de knop “Add Header (Koptekst toevoegen)” om een rij aan de tabel toe te voegen voor nog een HTTP-koptekst.
- Kies de volgende informatie:
- Location (Locatie): Waar moet deze HTTP-koptekst worden toegepast? Over het algemeen is
sitede juiste optie voor de meeste HTTP-kopteksten. - Header (Koptekst): Als je op deze optie klikt, krijg je een dropdown met veelgebruikte HTTP-kopteksten.
- Als de optie die je wilt gebruiken niet beschikbaar is, kun je ook een aangepaste koptekst toevoegen. Hiermee wordt een nieuw vak geopend waarin je de aangepaste HTTP-koptekst en de waarde kunt toevoegen.
- Zelfs als een optie in de dropdownselectie wordt weergegeven, is deze mogelijk niet beschikbaar voor gebruik op het WordPress.com-platform zoals hierboven uitgelegd.
- Value (Waarde): Hiermee worden de beschikbare opties voor een bepaalde HTTP-koptekst weergegeven. Bij aangepaste kopteksten kan dit echter verschijnen als een leeg veld dat je moet invullen.
- Location (Locatie): Waar moet deze HTTP-koptekst worden toegepast? Over het algemeen is
- Klik op de knop “Update (Bijwerken)”, waarna de HTTP-kopteksten worden toegevoegd aan de requests en responses voor je website.
Het kan even duren voordat de wijzigingen in de HTTP-kopteksten worden toegepast op je live website. Hoewel de wijzigingen uiteindelijk na verloop van tijd worden bijgewerkt, kun je ook overwegen om de cache van je browser te wissen en de cache van je website te wissen.
HTTP-kopteksten toevoegen met PHP-code
Als je op zoek bent naar een geavanceerdere oplossing of als je het gebruik van plugins wilt vermijden, kun je HTTP-kopteksten ook instellen via een custom-redirects.php bestand met behulp van de PHP-functie header(). Dit kan worden toegevoegd aan de hoofdmap van de site met SFTP.
Alle wijzigingen met SFTP worden beschouwd als geavanceerde site-aanpassingen. Je moet geen bestanden bewerken tenzij je precies weet wat de wijziging doet, en we raden je aan deze methode alleen te gebruiken als je bekend bent met het gebruik van SFTP.
Hier is een algemeen overzicht van hoe je HTTP-kopteksten aan je sitebestanden toevoegt met SFTP:
- Maak verbinding met je WordPress-site via je favoriete SFTP-client.
- Standaard zou je je in de hoofdmap moeten bevinden. Controleer of je je in de map
htdocs(root) bevindt voor WordPress.com-sites. Maak in die map een nieuw bestand met de naamcustom-redirects.php - Gebruik een teksteditor op je apparaat (zoals TextEdit of Notepad) om het bestand naar behoefte te bewerken.
- Sla het bestand op de server op.
Hieronder zie je een voorbeeld van een geldig custom-redirects.php -bestand:
<?php
header('X-XSS-Protection: 1; mode=block');
header('X-Content-Type-Options: nosniff');
header('X-Frame-Options: SAMEORIGIN');
header('Referrer-Policy: no-referrer-when-downgrade');Laatste update: juni 22, 2026