Mixed content efter SSL — når hængelåsen ikke bliver hel

Kort svar: Mixed content betyder, at siden hentes over HTTPS, men at billeder, scripts eller stylesheets stadig hentes over HTTP. Browseren markerer så siden som ikke sikker og blokerer usikre scripts og stylesheets, så layout og funktioner kan gå i stykker. Find adresserne i browserkonsollen, ret dem i databasen med en søg-og-erstat, der håndterer serialiserede data, og sørg for, at WordPress-adressen selv står med https – ellers kommer problemet tilbage.

Fagligt gennemgået: 2. oktober 2026

Det sker næsten altid efter skiftet fra HTTP til HTTPS, hvor gamle adresser står tilbage i indholdet, i temaet eller i indstillingerne. Certifikatet kan være helt i orden; problemet er de adresser, siden beder browseren om at hente.

Mixed content giver ikke den røde fuldskærmsadvarsel. Den hører til “Din forbindelse er ikke privat”, som handler om selve certifikatet.

Før du ændrer noget: Tag en backup af databasen, før du kører søg-og-erstat. En forkert erstatning rammer hele sitet på én gang, og den kan kun fortrydes med backuppen.

Hvad browseren gør med usikkert indhold

Moderne browsere skelner mellem typer af indhold. Det forklarer, hvorfor nogle sider ser fine ud, mens andre mister menu, layout eller betalingsformular.

Ressource over http	Hvad browseren gør	Konsekvens
Billeder, lyd og video	Forsøger at hente over https i stedet; blokeres, hvis det ikke findes	Manglende billeder eller “ikke sikker”-markering
Scripts	Blokeres	Menuer, sliders, formularer og betaling holder op med at virke
Stylesheets og fonte	Blokeres	Layoutet falder fra hinanden
Iframes (fx kort og video)	Blokeres	Tomme felter på siden
Formularer, der sender til http	Browseren advarer, før data sendes	Besøgende tør ikke sende

1. Find hvad der er galt

Tryk F12, vælg Konsol, og genindlæs. Browseren skriver præcis, hvilke adresser der blev hentet eller blokeret over HTTP – typisk med ordet “Mixed Content”. Der er som regel et mønster: samme mappe, samme domæne eller samme plugin igen og igen.

Fanen Netværk kan filtreres på http://, så du ser alle usikre kald samlet. Notér også, om adresserne peger på dit eget domæne (det kan du rette) eller på en ekstern tjeneste (det kan du kun erstatte).

2. Sæt site-adressen til https

Under Indstillinger → Generelt skal både WordPress-adresse og Webstedsadresse begynde med https://. Står de stadig med http, genererer WordPress selv nye http-adresser til alt, der uploades og linkes fremover, og så vender problemet tilbage, lige så hurtigt som du retter det.

Er felterne låst, er de sat i wp-config.php med WP_HOME og WP_SITEURL – ret dem dér:

define( 'WP_HOME', 'https://dinside.dk' );
define( 'WP_SITEURL', 'https://dinside.dk' );

Site Health under Værktøjer → Webstedets tilstand viser, om sitet bruger HTTPS. Er certifikatet på plads, tilbyder WordPress en knap til at opdatere adressen. Den retter også adresser i indholdet ved visning, men ikke i databasen – så søg-og-erstat i næste trin er stadig vejen til en varig løsning.

Sørg samtidig for, at serveren omdirigerer alt fra http til https med en 301, så gamle links udefra også lander sikkert. Hav kun den regel ét sted, ellers risikerer du for mange omdirigeringer.

3. Ret adresserne i indholdet

Brug et søg-og-erstat-værktøj, der håndterer serialiserede data. Med WP-CLI kan du køre en tørkørsel først, så du ser, hvor mange forekomster der rettes:

wp search-replace 'http://dinside.dk' 'https://dinside.dk' --skip-columns=guid --dry-run
wp search-replace 'http://dinside.dk' 'https://dinside.dk' --skip-columns=guid

Det retter indhold, indstillinger og widget-data på én gang. Kolonnen guid springes over, fordi den er en fast identifikator og ikke en adresse, der vises.

Blokeditoren og mange sidebyggere gemmer adresser som JSON, hvor skråstregerne er escapet. De fanges ikke af den almindelige erstatning, så kør også:

wp search-replace 'http:\/\/dinside.dk' 'https:\/\/dinside.dk' --skip-columns=guid

Har sitet tidligere kørt med www, så gentag kommandoerne for http://www.dinside.dk, og erstat med den version, du bruger nu. Uden WP-CLI kan et søg-og-erstat-plugin, der håndterer serialiserede data, gøre det samme. Brug aldrig en ren tekst-erstatning direkte i en SQL-dump – den ødelægger serialiserede værdier.

4. Find de sidste rester

• Hårdkodede adresser i temaet – søg efter http:// i temafilerne, især i header.php, functions.php og stylesheets.
• Eksterne ressourcer fra en tjeneste, der ikke selv kører HTTPS. Find et alternativ; det kan ikke rettes fra din side.
• Adresser i et sidebygger-layout, som ikke altid nås af søg-og-erstat.
• Cachede sider – ryd cachen i cacheplugin, server og CDN efter rettelsen, ellers ser du det gamle.

Tre steder, hvor mixed content gemmer sig ekstra godt

Når søg-og-erstat er kørt, og konsollen stadig klager, er det som regel et af disse tre steder.

CSS-filer: baggrundsbilleder skrevet som url(http://...) i temaets stylesheet eller i sidebyggerens genererede CSS. Konsollen viser adressen på billedet, men ikke hvilken CSS-fil der bad om det – søg i temaet og i wp-content/uploads efter http://. Genererede CSS-filer skal typisk gendannes fra sidebyggerens indstillinger efter erstatningen.

Widgets og menuer: ældre widgetdata er gemt serialiseret, og et værktøj, der ikke håndterer det, springer dem over. Brugerdefinerede links i menuer skal nogle gange rettes i hånden under Udseende → Menuer.

Sidebyggere: Elementor, Divi og andre har egne værktøjer til at erstatte adresser (i Elementor fx under Værktøjer → Erstat URL), fordi deres data ikke altid nås af en generel erstatning.

5. Sitet bag Cloudflare eller en anden proxy

Ligger sitet bag Cloudflare eller en anden proxy, kan WordPress tro, at det kører på http, selvom besøgende ser https. Det giver en uendelig omdirigering eller mixed content i alt, WordPress selv genererer.

Løsningen er at bruge SSL-tilstanden “Full (strict)” i Cloudflare med et gyldigt certifikat på serveren, og om nødvendigt fortælle WordPress, at proxyen har modtaget forbindelsen over HTTPS. Det gøres i wp-config.php over linjen om at stoppe med at redigere:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

Brug kun koden, når sitet faktisk står bag en proxy, der sætter headeren. Detaljerne står i SSL-tilstande i Cloudflare.

6. Sæt en regel op, der fanger resten

Til de sidste enkelttilfælde kan browseren bedes om selv at opgradere kaldene til https. Som HTTP-header:

Content-Security-Policy: upgrade-insecure-requests

Eller som meta-tag i sidens head:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

Brug det som sikkerhedsnet, ikke som løsning. Adresserne bør rettes i indholdet, så de også er rigtige, næste gang indholdet bliver kopieret eller flyttet. Findes en ressource slet ikke over https, hjælper opgraderingen ikke – så blokeres den stadig.

Vil du finde rester uden at blokere noget, kan headeren Content-Security-Policy-Report-Only bruges i en periode til at rapportere usikre kald. Mere om headere står i sikkerhedsheadere i WordPress.

Test som Google og som en besøgende

Konsollen viser kun den side, du står på. En hurtig måde at tjekke hele sitet på er at køre en crawl med et værktøj, der rapporterer “insecure content” – de fleste SEO-crawlere har det som standardtjek, og Search Console har en HTTPS-rapport, der viser sider, Google ikke kan vise som HTTPS.

Tjek også kassen og kontaktformularen særskilt: en betalingsformular med ét http-script er præcis det, browsere blokerer hårdest, og det ser du først, når en kunde ringer.

Når alt er rettet, så ryd cachen én gang til, og åbn sitet i et privat vindue på både desktop og mobil. Er konsollen fri for “Mixed Content” på forsiden, en artikel, et produkt og i kassen, og markerer browseren ikke siden som ikke sikker, er du færdig.

Hvorfor det betyder noget

Usikre elementer får besøgende til at tvivle, og browsere blokerer aktivt scripts og stylesheets hentet over HTTP – så siden kan reelt gå i stykker. Se også guiden til SSL-certifikater og hvad advarslen om forbindelsen betyder.

Hos Hostious følger gratis SSL fra Let’s Encrypt med på WordPress hosting, så den egentlige opgave ved et skift er de gamle adresser i indholdet.

Læs også

• Hub: Domæner, DNS og SSL – alle guides om emnet samlet ét sted
• “Din forbindelse er ikke privat”
• SSL-tilstande i Cloudflare
• ERR_TOO_MANY_REDIRECTS i WordPress
• WP-CLI for begyndere
• Webhotel hos Hostious – webhotel med SSL og dansk support

Ofte stillede spørgsmål om mixed content i WordPress

Er et SSL-plugin en god løsning?

Som overgang, ja. Men det retter adresserne i farten ved hver sidevisning i stedet for i databasen – så problemet følger med, hvis pluginnet fjernes.

Påvirker mixed content min placering?

Indirekte. Blokerede scripts kan brække layoutet, og det rammer både brugere og de målinger Google bruger.

Hvorfor kommer mixed content tilbage, efter jeg har rettet det?

Fordi WordPress-adressen under Indstillinger → Generelt (eller WP_HOME/WP_SITEURL i wp-config.php) stadig står med http. Så genererer WordPress nye http-adresser til alt nyt indhold. Ret adressen til https først.

Konsollen viser et billede over http, men jeg kan ikke finde det i indholdet. Hvor er det?

Sandsynligvis i en CSS-fil som url(http://…) – i temaet eller i sidebyggerens genererede stylesheet – eller i serialiserede widget- og sidebyggerdata. Søg i temafilerne, og brug sidebyggerens eget værktøj til at erstatte adresser.

Hvorfor finder søg-og-erstat ikke alle adresserne?

Blokeditoren og mange sidebyggere gemmer adresser som JSON med escapede skråstreger (http:\/\/). Kør en ekstra erstatning for den form, og husk www-varianten, hvis sitet har kørt med www før.