Asensit SSL-varmenteen ja määritit HTTPS:n, mutta selain näyttää edelleen "yhteys ei ole suojattu" -varoituksen. Kuulostaako tutulta?

Tältä sekasisältövirhe näyttää. Sivusto vaikuttaa toimivan hyvin, kävijät eivät valita, mutta Google näkee ongelman ja laskee hakusijoitustasi. Vuodesta 2018 lähtien Chrome on merkinnyt sekasisältöä sisältävät sivut turvattomiksi, ja käytäntö kiristyy jokaisen päivityksen myötä.

Tämän korjaaminen vaatii kaksi vaihetta. Et tarvitse kehittäjää, sinun ei tarvitse muokata jokaista linkkiä käsin, eikä ole riskiä ulkoasun rikkoutumisesta.

💡 Nopea yleiskatsaus:

• etsi sekasisällön lähde Chrome DevToolsilla tai verkkotyökaluilla
• asenna lisäosa (automaattinen tapa) tai muokkaa .htaccess-tiedostoa ja tietokantaa (manuaalinen tapa)
• varmista lopputulos ja määritä HTTPS-uudelleenohjaus tulevaisuutta varten

Mitä sekasisältö on ja miksi se on vaarallista

Sekasisältö on tilanne, jossa sivu latautuu HTTPS:n yli, mutta sen yksittäiset elementit (kuvat, skriptit, tyylit, fontit) haetaan turvattomalla HTTP-protokollalla.

Selain tulkitsee tämän tietoturva-aukoksi. Hyökkääjä voi kaapata HTTP-pyynnön, korvata skriptin tai kuvan ja päästä käsiksi käyttäjätietoihin. Siksi Chrome, Firefox ja Safari estävät "aktiivisen" sekasisällön (skriptit, iframe-kehykset) kokonaan, kun taas "passiivinen" sisältö (kuvat, media) laukaisee varoituksen osoiteriville.

Tyypillinen syy on siirtyminen HTTP:stä HTTPS:ään. Vanhat linkit sisällössä, teeman asetuksissa, CSS-tiedostoissa ja vimpaimissa säilyvät http://-alkuisina. WordPress ei muuta niitä automaattisesti, mistä ristiriita johtuu.

Vuodesta 2020 lähtien Google on todennut yksiselitteisesti: HTTPS on sijoitussignaali. Sekasisältöä sisältävä sivu menettää "vihreän lukon" ja sen myötä kävijöiden luottamuksen ja hakutulossijoitukset. Tämä on korjattava välittömästi SSL:n asennuksen jälkeen, ilman viivettä.

Vaihe 1: Diagnoosi, ongelman lähteen paikantaminen

Ennen kuin korjaat mitään, sinun on ymmärrettävä, mitkä resurssit latautuvat HTTP:n yli. Yleispätevä menetelmä on Chrome DevTools.

Avaa sivustosi Chromessa, paina F12 (tai Ctrl+Shift+I), siirry Console-välilehdelle ja päivitä sivu. Jokainen rivi, jossa on "Mixed Content" -varoitus, näyttää ongelmallisen tiedoston tarkan URL-osoitteen.

Lähistöllä, Security-välilehdellä, löydät yhteenvedon: varmenteen tilan, luettelon turvattomista pyynnöistä ja suosituksia niiden korjaamiseksi. Tämä riittää tilanteen nopeaan arviointiin.

Jos virheitä on paljon ja tarvitset täydellisen luettelon yhdessä raportissa, verkkotyökalut tulevat avuksi.

Jitbit SSL Checker on ilmainen verkkoskanneri. Syötä URL-osoite ja saat luettelon kaikista sivun HTTP-resursseista: kuvat, skriptit, CSS, ulkoiset kutsut. Ilmaisversio tarkistaa jopa 200 sivua.

Why No Padlock on toinen ilmainen palvelu, joka tarjoaa yksityiskohtaisen analyysin: mitkä elementit eivät ole suojattuja, mistä ne latautuvat ja mihin sisältötyyppiin ne kuuluvat. Se tukee kirjautumista vaativien sivujen tarkistamista.

HTTPS Checker on macOS-työpöytäsovellus, joka skannaa sivustosi paikallisesti ja näyttää virheet jokaisen muutoksen jälkeen. Se toimii 100 sivun rajalla ja on kätevä vaiheittaiseen virheenkorjaukseen.

Kun ongelmallisten URL-osoitteiden luettelo on edessäsi, siirry niiden korjaamiseen.

Vaihe 2: Korjaaminen, kolme toimivaa tapaa

Tavan valinta riippuu virheiden määrästä ja halukkuudestasi työskennellä koodin kanssa. Lisäosat hoitavat tehtävän parilla klikkauksella, kun taas manuaalinen tapa antaa täyden hallinnan.

Tapa 1: Really Simple Security, automatisoitu ratkaisu

Really Simple Security (entinen Really Simple SSL) on suosituin WordPress SSL -lisäosa, jolla on 3 miljoonaa aktiivista asennusta ja arvosana 4,9/5 WordPress.orgissa.

Asenna lisäosa kohdasta "Lisäosat → Lisää uusi", aktivoi se ja suorita asennusvelho. Lisäosa tekee automaattisesti seuraavat:

• asettaa HTTPS:n WordPress-asetuksiin (sivuston osoite ja kotiosoite),
• määrittää 301-uudelleenohjauksen HTTP:stä HTTPS:ään,
• korvaa HTTP-linkit sisällössä lennossa tulostuspuskurin kautta,
• tarkistaa varmenteen ja varoittaa vanhenemisesta.

Asennuksen jälkeen avaa sivustosi incognito-tilassa ja varmista, että osoitepalkin lukko on vihreä eikä DevTools → Console näytä Mixed Content -varoituksia. Suurimmalle osalle sivustoja tämä riittää.

Tapa 2: SSL Insecure Content Fixer, joustavat tasoasetukset

Jos Really Simple Security ei toiminut (esimerkiksi osa sisällöstä latautuu kolmannen osapuolen rajapintojen kautta), asenna SSL Insecure Content Fixer. Lisäosalla on 100 000 aktiivista asennusta, arvosana 4,8/5, ja se tarjoaa viisi suodatustasoa:

• Simple on perustaso aloittelijoille, korjaa linkit sisällössä ja asetuksissa;
• Content tarkistaa lisäksi tekstiwidgetit ja shortcodet;
• Widgets keskittyy widgettien sisältöön, mukaan lukien mukautettu HTML;
• Capture kaappaa koko sivun ennen renderöintiä ja korvaa jokaisen http://-osoitteen https://-osoitteella. Hitaampi mutta tehokkaampi;
• Capture All tarjoaa maksimaalisen kattavuuden: skriptit, inline-tyylit, ulkoiset kutsut. Eniten resursseja kuluttava tila.

Aloita Simple-tasosta. Jos virheitä jää, vaihda korkeammalle tasolle ja tarkista sivustosi uudelleen. Älä hyppää suoraan Capture All -tasoon ilman tarvetta: se kuormittaa palvelinta ja saattaa olla ristiriidassa välimuistilisäosien kanssa.

Tapa 3: Manuaalinen korjaus,.htaccess ja tietokanta

Jos vastustat periaatteessa ylimääräisiä lisäosia tai virhe on yksittäinen, tässä on suora reitti.

Vaihe A. Pakota HTTPS-uudelleenohjaus.htaccess-tiedostossa. Lisää seuraava tiedoston alkuun (ennen riviä # BEGIN WordPress):

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

Tallenna ja varmista, että etusivu ja kaikki sisäiset URL-osoitteet ohjautuvat HTTPS:ään. Lataa.htaccess-tiedostosta varmuuskopio ennen muokkaamista: yksi kirjoitusvirhe voi rikkoa sivustosi.

Vaihe B. Korvaa HTTP-linkit tietokannassa. Vanhat URL-osoitteet artikkeleissa, metakentissä ja asetuksissa sisältävät yhä http://-alkuisia osoitteita. Niiden muuttaminen suoralla SQL-kyselyllä on riskialtista, koska serialisoitu PHP-data hajoaa. Käytä:

• WP-CLI: wp search-replace 'http://example.com' 'https://example.com' --dry-run (ensin ilman --dry-run-lippua nähdäksesi korvausten määrän);
• Better Search Replace -lisäosaa, joka tekee saman hallintapaneelin kautta esikatselun kera.

Korvausten jälkeen tyhjennä selaimen välimuisti (Ctrl+Shift+Del), lisäosien välimuisti (WP Rocket, LiteSpeed) ja tarkista sivustosi incognito-tilassa.

Hyödyllinen video aiheesta

GoTechWizard-kanavan tekijä näyttää prosessin sekasisällön korjaamisesta diagnoosista puhtaaseen HTTPS:ään ilman yhtäkään riviä koodia:

⁉️🤔 Usein kysytyt kysymykset

Miksi sivusto näyttää yhä "ei turvallinen" SSL-asennuksen jälkeen?

SSL-sertifikaatti on aktivoitu palvelimella, mutta osa sisällöstä latautuu HTTP:n yli. Sertifikaatti kattaa selaimen ja palvelimen välisen yhteyden, kun taas sivun sisäiset HTTP-linkit ohittavat sen. Selain havaitsee protokollien sekoituksen ja varoittaa käyttäjää. Pääsyitä on kolme: vanhat kuvalinkit artikkeleissa (lisätty ennen SSL-asennusta), kovakoodatut HTTP-URL-osoitteet teemassa tai lisäosissa sekä ulkoiset resurssit (Google-fontit, CDN-skriptit), jotka latautuvat http://-alkuisesti https://-alkuisuuden sijaan. Tee diagnoosi DevTools → Console -kautta ja noudata tämän artikkelin ohjeita.

Tarvitseeko minun ostaa SSL-sertifikaatti vai riittääkö ilmainen?

Valtaosalle sivustoista ilmainen Let's Encryptin SSL on riittävä. Kaikki selaimet ja hakukoneet tunnistavat sen. Maksulliset sertifikaatit (OV, EV) ovat järkeviä verkkokaupoille, pankeille ja maksulomakkeita sisältäville sivustoille: ne edellyttävät yrityksen vahvistamista ja näyttävät organisaation nimen osoiterivillä. Blogille, portfoliolle tai yrityssivustolle Let's Encrypt on standardi. Useimmat hosting-palveluntarjoajat (Timeweb, Beget, Hostinger) myöntävät sen automaattisesti sivustoa luotaessa.

Voiko sekasisällön korjata ilman lisäosia ja koodimuutoksia?

Joillakin hosting-palveluntarjoajilla kyllä. Cloudflare sisältää ilmaispaketissaan Automatic HTTPS Rewrites -vaihtoehdon: se korjaa HTTP-linkit HTTPS-muotoon lennossa kaikelle CDN:n kautta kulkevalle liikenteelle. Tämä on kuitenkin puolittainen ratkaisu: ongelma säilyy palvelintasolla, ja kun poistat Cloudflaren käytöstä, virheet palaavat. On parempi poistaa syy korvaamalla HTTP-linkit tietokannassa ja määrittämällä.htaccess-uudelleenohjaus. Silloin sivustosi on puhdas riippumatta liikenteen toimitustavasta.

SSL Insecure Content Fixer* vai Really Simple Security: kumpi valita?*

Se riippuu tehtävästä. Really Simple Security on "asenna ja unohda" -ratkaisu: se sopii tyypilliselle WordPress-sivustolle ilman monimutkaisia integraatioita. SSL Insecure Content Fixer on työkalu, jossa on porrastetut tasot hienosäätöä varten. Jos virheitä jää Really Simple Securityn aktivoinnin jälkeen (näin käy epästandardien teemarakenteiden, mukautettujen endpointien tai suoria HTTP-kutsuja tekevien lisäosien kanssa), vaihda SSL Insecure Content Fixeriin ja nosta suodatustasoa. Käytäntö osoittaa: ensimmäinen lisäosa kattaa useimmat tapaukset, toinen hoitaa loput.

Onko Capture All -tilan käyttö SSL Insecure Content Fixerissä turvallista?

Capture All sieppaa ja uudelleenkirjoittaa jokaisen sivun tavun ennen sen lähettämistä selaimeen. Tämä on luotettavaa, mutta lisää suorittimen kuormitusta. Heikolla hostingilla tai paljon liikennettä sisältävillä sivustoilla vasteaika voi hidastua 100-300 ms. Välimuistilisäosat (WP Rocket) lieventävät tätä vaikutusta: sivu luodaan kerran ja tarjoillaan välimuistista. Ennen Capture Allin käyttöönottoa varmista, etteivät lievemmät tasot ole ratkaisseet ongelmaa, ja luo varmuuskopio.

Sekasisältö korjattu, mitä seuraavaksi

Sekasisältövirhe ei ole kuolemantuomio. Tämän artikkelin kahden vaiheen jälkeen se on täysin ratkaistu eikä yleensä palaa. Avain on olla vaientamatta selainvaroituksia vaan poistaa syy: vaihda jokainen resurssi HTTPS-muotoon.

Vakiinnuta tuloksesi: määritä automaattinen SSL-tarkistus (UptimeRobot tai hosting-valvonta lähettää ilmoituksen 30 päivää ennen sertifikaatin vanhenemista) ja ota tavaksi lisätä uudet linkit alusta alkaen https://-alkuisina. Muutama minuutti ennaltaehkäisyä nyt säästää tunteja virheenetsintää myöhemmin.