Du installerade ett SSL-certifikat och konfigurerade HTTPS, men webbläsaren visar fortfarande en varning om "anslutningen är inte säker". Låter det bekant?

Så här ser ett mixed content-fel ut. Sajten verkar fungera bra, besökarna klagar inte, men Google ser problemet och sänker din sökrankning. Sedan 2018 markerar Chrome sidor med mixed content som osäkra, och policyn blir striktare med varje uppdatering.

Att åtgärda detta tar två steg. Ingen utvecklare behövs, ingen manuell redigering av varje länk, och ingen risk att förstöra layouten.

💡 Snabb översikt:

• hitta källan till mixed content med Chrome DevTools eller onlineverktyg
• installera ett plugin (automatisk metod) eller redigera .htaccess och databasen (manuell metod)
• verifiera resultatet och ställ in HTTPS-omdirigering för framtiden

Vad är mixed content och varför är det farligt

Mixed content är en situation där en sida laddas över HTTPS, men enskilda element på den (bilder, skript, stilar, typsnitt) hämtas över det osäkra HTTP-protokollet.

Webbläsaren ser detta som ett säkerhetshål. En angripare kan fånga upp HTTP-förfrågan, byta ut ett skript eller en bild och få tillgång till användardata. Därför blockerar Chrome, Firefox och Safari "aktivt" mixed content (skript, iframes) helt, medan "passivt" innehåll (bilder, media) utlöser en varning i adressfältet.

Den typiska orsaken är migrering från HTTP till HTTPS. Gamla länkar i innehåll, temainställningar, CSS-filer och widgets ligger kvar med prefixet http://. WordPress ändrar dem inte automatiskt, därav konflikten.

Sedan 2020 har Google uttryckligen sagt: HTTPS är en rankningssignal. En sida med mixed content förlorar det "gröna hänglåset" och, tillsammans med det, besökarnas förtroende och SERP-positioner. Du måste åtgärda detta omedelbart efter att du installerat SSL, utan dröjsmål.

Steg 1: Diagnos, hitta källan till problemet

Innan du åtgärdar något måste du förstå vilka resurser som laddas över HTTP. Den universella metoden är Chrome DevTools.

Öppna din sajt i Chrome, tryck på F12 (eller Ctrl+Shift+I), gå till fliken Console och ladda om sidan. Varje rad med en "Mixed Content"-varning visar den exakta webbadressen till den problematiska filen.

I närheten, på fliken Security, hittar du en sammanfattning: certifikatstatus, lista över osäkra förfrågningar och rekommendationer för att åtgärda dem. Detta räcker för en snabb bedömning av situationen.

Om det finns många fel och du behöver få en komplett lista i en rapport, kommer onlineverktyg till undsättning.

Jitbit SSL Checker är en gratis onlineskanner. Ange webbadressen och få en lista över alla HTTP-resurser på sidan: bilder, skript, CSS, externa anrop. Gratisversionen kontrollerar upp till 200 sidor.

Why No Padlock är en annan gratistjänst med detaljerad analys: vilka element som inte är säkra, varifrån de laddas och vilken typ av innehåll de tillhör. Den stöder kontroll av sidor som kräver autentisering.

HTTPS Checker är ett skrivbordsverktyg för macOS som skannar din sajt lokalt och visar fel efter varje ändring. Det fungerar med en gräns på 100 sidor och är praktiskt för stegvis felsökning.

När du har listan över problematiska webbadresser framför dig, gå vidare till att åtgärda dem.

Steg 2: Åtgärda, tre fungerande metoder

Valet av metod beror på antalet fel och din vilja att arbeta med kod. Plugins löser uppgiften med ett par klick, medan den manuella metoden ger dig full kontroll.

Metod 1: Really Simple Security, automatiserad lösning

Really Simple Security (tidigare Really Simple SSL) är det mest populära WordPress SSL-pluginet med 3 miljoner aktiva installationer och betyget 4,9/5 på WordPress.org.

Installera tillägget via "Tillägg → Lägg till nytt", aktivera det och kör installationsguiden. Tillägget gör automatiskt följande:

• sätter HTTPS i WordPress-inställningarna (webbplatsadress och hem-URL),
• konfigurerar en 301-omdirigering från HTTP till HTTPS,
• ersätter HTTP-länkar i innehåll "i farten" via utdatabuffert,
• kontrollerar certifikatet och varnar om utgångsdatum.

Öppna din webbplats i inkognitoläge efter installationen och kontrollera att hänglåset i adressfältet är grönt och att det inte finns några varningar om blandat innehåll i DevTools → Console. För de allra flesta webbplatser räcker detta.

Metod 2: SSL Insecure Content Fixer, flexibla nivåinställningar

Om Really Simple Security inte fungerade (till exempel för att visst innehåll laddas via tredjeparts-API:er) installerar du SSL Insecure Content Fixer. Tillägget har 100 000 aktiva installationer, betyget 4,8/5 och erbjuder fem filtreringsnivåer:

• Simple är grundnivån för nybörjare, fixar länkar i innehåll och inställningar;
• Content kontrollerar dessutom textwidgets och shortcodes;
• Widgets fokuserar på widgetinnehåll, inklusive anpassad HTML;
• Capture fångar upp hela sidan före rendering och ersätter varje http:// med https://. Långsammare men mer effektivt;
• Capture All ger maximal täckning: skript, inline-stilar, externa anrop. Det mest resurskrävande läget.

Börja med Simple. Om fel kvarstår byter du till en högre nivå och kontrollerar webbplatsen igen. Hoppa inte direkt till Capture All i onödan: det belastar servern och kan krocka med cachingtillägg.

Metod 3: Manuell fix,.htaccess och databas

Om du är principiellt emot extra tillägg eller om felet är isolerat, här är den direkta vägen.

Steg A. Tvinga HTTPS-omdirigering i.htaccess. Lägg till följande i början av filen (före # BEGIN WordPress):

1
RewriteEngine On
2
RewriteCond %{HTTPS} off
3
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Spara och kontrollera att startsidan och alla interna URL:er omdirigeras till HTTPS. Ladda ner en säkerhetskopia av.htaccess innan du redigerar: ett enda skrivfel kan krascha webbplatsen.

Steg B. Ersätt HTTP-länkar i databasen. Gamla URL:er i inlägg, metafält och inställningar har fortfarande http://. Att ändra dem med en direkt SQL-fråga är riskabelt eftersom serialiserad PHP-data förstörs. Använd:

• WP-CLI: wp search-replace 'http://example.com' 'https://example.com' --dry-run (först utan --dry-run för att se antalet ersättningar);
• tillägget Better Search Replace, som gör samma sak via adminpanelen med förhandsgranskning.

Rensa webbläsarens cache (Ctrl+Shift+Del), tilläggscache (WP Rocket, LiteSpeed) efter ersättningen och kontrollera webbplatsen i inkognitoläge.

Användbar video i ämnet

Skaparen av GoTechWizard-kanalen demonstrerar processen för att åtgärda blandat innehåll från diagnos till ren HTTPS utan en enda rad kod:

⁉️🤔 Vanliga frågor

Varför visar sajten fortfarande "inte säker" efter att jag installerat SSL?

SSL-certifikatet är aktiverat på servern, men en del innehåll laddas över HTTP. Certifikatet skyddar anslutningen mellan webbläsaren och servern, medan HTTP-länkar inuti sidan går förbi det. Webbläsaren ser blandningen av protokoll och varnar användaren. Det finns tre huvudorsaker: gamla länkar till bilder i inlägg (infogade före SSL-installationen), hårdkodade HTTP-URL:er i temat eller tillägg, och externa resurser (Google fonts, CDN-skript) som laddas via http:// istället för https://. Diagnostisera via DevTools → Console och följ stegen i den här artikeln.

Behöver jag köpa ett SSL-certifikat eller räcker ett gratis?

För de allra flesta sajter räcker ett gratis SSL från Let's Encrypt. Det godkänns av alla webbläsare och sökmotorer. Betalda certifikat (OV, EV) är meningsfulla för webbutiker, banker och sajter med betalformulär: de kräver företagsverifiering och visar organisationsnamnet i adressfältet. För en blogg, en portfölj eller en företagssajt är Let's Encrypt standard. De flesta webbhotell (Timeweb, Beget, Hostinger) utfärdar det automatiskt när du skapar en sajt.

Kan blandat innehåll åtgärdas utan tillägg och kodändringar?

Hos vissa webbhotell, ja. Cloudflare inkluderar alternativet Automatic HTTPS Rewrites i sin gratisplan: det fixar HTTP-länkar till HTTPS i farten för all trafik som passerar genom CDN:et. Det är dock en halvmesyr: problemet kvarstår på servernivå, och när du inaktiverar Cloudflare kommer felen tillbaka. Det är bättre att eliminera orsaken genom att ersätta HTTP-länkar i databasen och sätta upp en.htaccess-omdirigering. Då är din sajt ren oavsett hur trafiken levereras.

SSL Insecure Content Fixer](/orig_post/8-best-wordpress-ssl-plugins-2022-free-amp-paid) eller Really Simple Security: vilket ska jag välja?*

Det beror på uppgiften. Really Simple Security är en "ställ in och glöm"-lösning: passar en typisk WordPress-sajt utan komplexa integrationer. SSL Insecure Content Fixer är ett verktyg med graderade nivåer för finjustering. Om fel kvarstår efter att du aktiverat Really Simple Security (detta händer med icke-standardiserade temastrukturer, anpassade endpoints eller tillägg med direkta HTTP-anrop), byt till SSL Insecure Content Fixer och öka filtreringsnivån. Erfarenheten visar: det första tillägget täcker de flesta fall, det andra hanterar resten.

Är det säkert att använda Capture All-läget i SSL Insecure Content Fixer?

Capture All fångar upp och skriver om varje byte på sidan innan den skickas till webbläsaren. Det är tillförlitligt men ökar CPU-belastningen. På svaga webbhotell eller sajter med hög trafik kan det uppstå en svarsfördröjning på 100-300 ms. Cachingtillägg (WP Rocket) mildrar denna effekt: sidan genereras en gång och serveras från cache. Innan du aktiverar Capture All, kontrollera att mildare nivåer inte har löst problemet, och skapa en säkerhetskopia.

Fixat blandat innehåll, vad händer nu

Ett fel med blandat innehåll är ingen dödsdom. Efter de två stegen i den här artikeln är det helt löst och kommer som regel inte tillbaka. Nyckeln är att inte tysta webbläsarens varningar utan att eliminera orsaken: växla varje resurs till HTTPS.

Konsolidera ditt resultat: sätt upp automatisk SSL-kontroll (UptimeRobot eller webbhotellets övervakning skickar ett meddelande 30 dagar innan certifikatet löper ut) och gör det till en vana att infoga nya länkar med https:// från början. Några minuters förebyggande arbete nu sparar timmar av felsökning senare.