- A passzív kevert tartalom csak figyelmeztetést hoz, az aktív (szkript, iframe, CSS) blokkolódik és funkciót tör el.
- A böngésző automatikus javítása csak a kép, hang és videó egy részére vonatkozik, a szkriptekre nem, és nem tisztítja meg a forrást.
- A WP-CLI search-replace a soros adatokat is helyesen kezeli, de csak --precise és --recurse-objects kapcsolóval, előbb mindig --dry-run módban.
- A maradék http:// hivatkozás a leggyakrabban sablonfájlban, hardcode-olt CSS-háttérképben, hirdetéskódban, e-mail-sablonban és az RSS-feedben marad benn.
- Ha egy külső beágyazás nem érhető el HTTPS-en, nem a kevert tartalmat engedjük meg, hanem a szolgáltatót cseréljük, proxyzunk vagy kilinkelünk.
A HTTPS-átállás akkor nevezhető késznek, ha nemcsak a lakat jelenik meg a címsorban, hanem a fejlesztői konzol is üres marad. A gyakorlatban a kettő ritkán esik egybe. Az oldal betölt, a tanúsítvány érvényes, a látogató mégis gyanús jelzést lát, vagy egy űrlap nem küld, mert valahol a rendszer mélyén maradt egy http:// kezdetű hivatkozás. Ez a cikk arról szól, hogyan találod meg és hogyan számolod fel ezeket a maradványokat úgy, hogy közben nem töröd el az adatbázist.
Mit jelent pontosan a kevert tartalom, és miért marad benn az átállás után?
Kevert tartalomról akkor beszélünk, ha egy HTTPS-en kiszolgált oldal valamilyen erőforrást titkosítatlan HTTP-kapcsolaton kér le. Lehet ez kép, stíluslap, betűtípus, JavaScript-fájl vagy beágyazott keret. A lap ilyenkor csak részben védett, mert a beágyazott kérés a nyílt hálózaton utazik, és elvileg módosítható útközben.
Az átállás technikai része rendszerint rövid. A tanúsítvány kiadása automatizált, az átirányítás néhány sor a szerverkonfigurációban. A takarítás húzódik el, mert a http:// kezdetű címek nem egy helyen élnek. Ott vannak a bejegyzések törzsében, a sablon PHP-fájljaiban, a bővítmények beállítás-mezőiben, a widget-ekben, a testreszabó egyedi CSS-ében, a menüpontokban, a felhasználói profilokban, sőt a kiküldött levelek sablonjaiban is. Egy közepes WordPress-adatbázisban ez több ezer előfordulást jelenthet.
Saját tapasztalat. A migrációk nagyobb részében az abszolút, protokollal együtt elmentett URL a gyökérok. A tartalomszerkesztő évekig beillesztett teljes címeket, a bővítmények pedig elmentették a feltöltési mappa akkori, HTTP-s alapcímét, és azt használják minden új kimenetnél.
Mi a különbség a passzív és az aktív kevert tartalom között?
A passzív kevert tartalom nem tudja átírni az oldal működését, az aktív igen. Ezért a böngészők a kettőt eltérően kezelik.
Passzívnak számít a kép, a hang és a videó, vagyis minden olyan erőforrás, amit a lap csak megjelenít, de nem enged a saját kódjához férni. Ha ezt HTTP-n töltöd, a támadó legrosszabb esetben lecserélheti a képet, de a munkamenet-sütihez nem jut hozzá. A böngésző emiatt enged, csak jelez.
Aktívnak számít a JavaScript, a stíluslap, a betöltött betűtípus, az iframe, az XMLHttpRequest és a fetch hívás, a WebSocket-kapcsolat, valamint a Flash-korszakból maradt beágyazások. Ezek bele tudnak nyúlni a dokumentumba, olvashatják a sütiket, átírhatják az űrlap célcímét. A modern böngészők ezeket hivatalosan igazoltan alapértelmezés szerint blokkolják, nem csak figyelmeztetnek. Ez a viselkedés a W3C Mixed Content specifikációjában és a böngészőgyártók dokumentációjában is rögzítve van.
A gyakorlati következmény éles. Egy passzív hiba esztétikai és bizalmi kérdés, egy aktív hiba funkciót tör el. Ha a kosár szkriptje vagy a foglalási naptár iframe-je HTTP-n jön, a látogató számára az oldal egyszerűen nem működik, és erről nem kap magyarázatot.
Miért nem elég, ha a böngésző automatikusan javítja a hivatkozásokat?
Mert a böngésző csak a kockázat egy részét kezeli, és nem a forrást javítja, hanem a tünetet takarja el.
A nagy böngészők ma automatikus protokollemelést végeznek a passzív erőforrásokon. Megpróbálják HTTPS-en lekérni a képet, és ha ez sikerül, betöltik. Ha nem sikerül, a kép egyszerűen eltűnik. Ez három okból nem megoldás. Egyrészt az aktív erőforrásokra nem vonatkozik, tehát a szkriptek továbbra is blokkolódnak. Másrészt böngészőnként és verziónként eltérő, tehát nem tudsz rá építeni. Harmadrészt a HTML-forrásban ettől még ott marad a rossz cím, amit minden más rendszer változatlanul lát.
Ez utóbbi a legdrágább. A keresőrobot, a közösségi előnézet-generáló, a levelezőprogram, az RSS-olvasó és az AI-válaszmotorok forráskövető komponense nem böngésző. Ezek a nyers HTML-t dolgozzák fel, és a benne lévő http:// címet betű szerint veszik. Szakmai feltételezés. A vegyes protokollú kimenet a gépi feldolgozók szemében következetlenségnek látszik, ami nem közvetlen rangsorolási tényező, de nehezíti az oldal megbízható forrásként való kezelését. Ezt hivatalos dokumentáció nem mondja ki, viszont a hivatkozások stabilitására minden komolyabb útmutató kitér.
Hogyan találod meg a maradék http:// hivatkozásokat adatbázis-szinten?
A megbízható sorrend az, hogy előbb megszámolod, aztán cserélsz, és sosem fordítva. A felmérés olvasás, nem kockázat.
Kezdd a teljes adatbázisra kiterjedő leltárral. A WP-CLI keresője végignézi az összes táblát, a bővítmények saját tábláit is, és megmondja, hány találat van táblánként és oszloponként.
wp db query "SELECT COUNT(*) FROM wp_postmeta WHERE meta_value LIKE '%http://sajatdomain.hu%'"
wp search-replace 'http://sajatdomain.hu' 'https://sajatdomain.hu' --all-tables --dry-run --report-changed-only
A --dry-run semmit nem ír, csak kiírja, mit írna. Ebből a listából derül ki, hogy a találatok hol koncentrálódnak. Ha a wp_options és a wp_postmeta viszi a többséget, akkor a probléma nem a tartalomban van, hanem a beállításokban.
Külön nézd meg a nem WordPress-kezelt helyeket is. A statikus fájlokban álló címeket a szerveren grep-pel találod meg a leggyorsabban.
grep -rn 'http://sajatdomain.hu' wp-content/themes wp-content/uploads --include='*.php' --include='*.css' --include='*.js'
Hogyan írd meg a WP-CLI search-replace-t úgy, hogy a soros adatok épek maradjanak?
A WordPress rengeteg beállítást PHP-serialize formában tárol. Ez a formátum a szöveg hosszát is elmenti a szöveg elé. Ha egy egyszerű SQL REPLACE paranccsal írod át a http szót https-re, a karakterszám eggyel nő, a mentett hossz viszont marad, és a teljes rekord olvashatatlanná válik. Ilyenkor tűnik el egy csapásra a sablon összes beállítása vagy egy oldalépítő teljes elrendezése.
A WP-CLI ezt kezeli, mert kicsomagolja, átírja és újraszámolt hosszal menti vissza a soros értékeket. Ehhez azonban kapcsolók kellenek.
wp search-replace 'http://sajatdomain.hu' 'https://sajatdomain.hu' --all-tables --precise --recurse-objects --skip-columns=guid --report-changed-only
--all-tablesa WordPress előtagján kívüli, bővítmények által létrehozott táblákra is kiterjeszti a cserét.--precisekikapcsolja a gyors SQL-alapú utat, és PHP-ban dolgozza fel a sorokat, így a soros adat biztosan helyesen épül újra.--recurse-objectsa beágyazott tömbökbe és objektumokba is belemegy, ez az oldalépítők adatstruktúrái miatt fontos.--skip-columns=guidvédi a bejegyzés-azonosítót. A guid mező nem URL, hanem állandó azonosító, az RSS-olvasók ez alapján döntik el, hogy egy tétel új-e. Ha átírod, a feliratkozóknál minden régi bejegyzés újként jelenhet meg.
A csere előtt készíts adatbázis-mentést, és ellenőrizd is, hogy visszatölthető. A wp db export mentes.sql parancs pár másodperc, a helyreállítás nélküle viszont órák.
Ha protokoll-független, kettős perjellel kezdődő címeket is találsz, azokat is érdemes teljes HTTPS-alakra hozni, mert a levelezőprogramok és egyes feldolgozók nem tudják értelmezni a hiányzó protokollt.
Miért nem a bejegyzésekben marad a hiba, hanem a sablonban és a bővítmény-beállításokban?
Saját tapasztalat, és ez a cikk legfontosabb állítása. A migráció után futtatott csere szinte mindig megtalálja a bejegyzés-törzseket, mert azok a wp_posts táblában, sima szövegként állnak. A maradék viszont két helyen húzódik meg, ahová az általános csere nem ér el.
Az első a sablonfájl. A gyermeksablon functions.php-jában, a header.php-ben vagy egy egyedi sablonrészletben beírt teljes URL nincs az adatbázisban, tehát a WP-CLI nem látja. Ugyanez igaz a sablonhoz tartozó style.css-ben megadott background-image hivatkozásokra. Ezek a hivatkozások ráadásul aktív kevert tartalmat is okozhatnak, ha külső szkriptet vagy betűtípust töltenek.
A második a bővítmények beállítás-mezője. Egy süti-tájékoztató, egy analitika-bővítmény, egy űrlapkezelő vagy egy sliderkezelő sokszor saját táblában, saját formátumban tárolja az értékeket, néha kódolva. Az --all-tables ezekre kiterjed, a base64-ben vagy JSON-szövegként elmentett URL-re viszont a sima karakterlánc-csere nem talál rá. Ilyenkor nincs más út, mint a bővítmény admin felületén kézzel átnézni a mezőket.
Milyen ellenőrzőlistán menj végig a csere után?
A cserét mindig tételes átnézés követi. Ez a lista lefedi azokat a helyeket, amik a leggyakrabban maradnak ki.
- Sablonfájlok. A gyermeksablon és a szülősablon PHP-fájljai, különösen a fejléc, a lábléc és az egyedi sablonrészletek. Itt keress teljes URL-t és külső szkript-betöltést.
- Hardcode-olt CSS-háttérképek. A sablon stíluslapja, a testreszabó egyedi CSS-mezője, az oldalépítők szekciónkénti háttérbeállítása. Ezek a böngésző hálózati fülén látszanak, a HTML-forrásban nem mindig.
- Hirdetés- és mérőkódok. Remarketing-címkék, konverziókövető szkriptek, partnerprogram-kódok, chat-widget beillesztések. Régebbi beillesztett kódrészletek gyakran még HTTP-s betöltőcímmel érkeztek.
- E-mail-sablonok. A rendelés-visszaigazolás, a jelszó-emlékeztető, a hírlevél fejlécében lévő logó és a levélben lévő gombok célcíme. A levelezőprogramok egy része blokkolja a titkosítatlan képet, így a logó helyén üres doboz marad.
- RSS-feed. Nyisd meg a feed címét, és nézd át a nyers XML-t. A csatornacím, a kiemelt kép és a bejegyzésekben lévő beágyazások mind maradhattak HTTP-n.
- Oldaltérkép és strukturált adat. Az XML-oldaltérkép címei, a JSON-LD blokk
url,logoésimagemezői, a canonical és az Open Graph címkék. - Átirányítási szabályok. A
.htaccessvagy nginx-konfiguráció régi, teljes URL-t tartalmazó szabályai, amik HTTP-re irányítanak vissza, és átirányítási hurkot okoznak.
Mit tegyél, ha egy külső beágyazás nem érhető el HTTPS-en?
A rövid válasz az, hogy a kevert tartalmat nem engedjük meg, hanem a beágyazást cseréljük. A böngészőben mindenképpen blokkolódna, tehát a hibás állapot fenntartása semmit nem old meg.
Ha térképről van szó, a legtöbb esetben a szolgáltató időközben kiadott HTTPS-en is elérhető beágyazó kódot, csak a régi verzió maradt az oldalon. Kérd le újra a beágyazást a szolgáltató felületéről, ne a meglévő kódban írd át kézzel a protokollt.
Ha a szolgáltató tényleg nem támogatja a HTTPS-t, három használható út marad. Válthatsz másik szolgáltatóra, ami ugyanazt a funkciót adja. Kiszolgálhatod a tartalmat saját szerveren keresztül, vagyis a saját domainen futó végpont kéri le a külső forrást, és HTTPS-en adja tovább, de ilyenkor a licenc- és adatvédelmi feltételeket előre nézd meg. Vagy kiveszed a beágyazást, és helyette egy jól megírt szöveges hivatkozást teszel ki, ami új ablakban nyitja a külső oldalt.
Amit ne csinálj, az az upgrade-insecure-requests irányelv megoldásként való használata olyan forráson, ami nem is létezik HTTPS-en. Ez a fejléc utasítja a böngészőt a protokollemelésre, de ha a szolgáltató oldalán nincs HTTPS-végpont, a kérés hibára fut, és a funkció így is elvész. Belső, saját erőforrások átmeneti kezelésére viszont hasznos, amíg a takarítás tart.
Hogyan ellenőrzöd, hogy tényleg tiszta lett az oldal?
Egyetlen oldal megnyitása nem elég. A kevert tartalom oldaltípusonként eltér, mert eltérő sablonrészletek és bővítmények futnak.
Nyisd meg a fejlesztői eszközök konzolját, és járj végig legalább egy főoldalt, egy blogbejegyzést, egy kategórialistát, egy terméklapot, a kosarat, a pénztárt és egy kapcsolati űrlapot tartalmazó oldalt. A konzol kiírja a blokkolt és a figyelmeztetett kéréseket egyaránt. A nyers forrásban külön keress rá a http:// szövegre, mert a böngésző által automatikusan emelt kérés a hálózati fülön már HTTPS-ként látszik.
Ezután futtass egy teljes bejárást. Egy asztali bejáró vagy egy parancssori ellenőrző végigmegy az oldaltérképen, és összeszedi, mely oldalakon maradt titkosítatlan erőforrás. Végül nézd meg a Search Console lefedettségi és oldalélmény-jelentéseit, mert az újrafeldolgozás után ott is megjelennek az elérhetetlenné vált erőforrások.
A takarítás nem garantál rangsorbeli elmozdulást, és önmagában nem hoz több érdeklődőt. Azt viszont jó eséllyel megelőzi, hogy egy blokkolt szkript miatt működésképtelen legyen egy űrlap vagy egy fizetési lépés, és ez az a hatás, ami a leggyorsabban mérhető.
Források és további olvasnivalók
- W3C, Mixed Content specifikáció
- MDN Web Docs, Mixed content és Content Security Policy leírások
- Google Search Central, HTTPS-átállás és Security Issues dokumentáció
- Chrome for Developers, kevert tartalom kezelése és protokollemelés
- WordPress Developer Resources, WP-CLI search-replace parancs leírása
- WordPress Support, Moving WordPress és HTTPS-beállítás dokumentáció
- OWASP, Transport Layer Security Cheat Sheet
Gyakori kérdések
Elég, ha bekapcsolok egy kevert tartalmat javító bővítményt?
Átmeneti megoldásnak jó, de a forrás nem javul meg tőle. Ezek a bővítmények kimenet közben írják át a hivatkozásokat, tehát minden oldalbetöltésnél dolgoznak, és ha kikapcsolod őket, a hiba azonnal visszatér. Ráadásul az e-mail-sablonokra és az RSS-feedre jellemzően nem hatnak. Érdemes velük indulni, amíg az adatbázis-szintű csere elkészül, utána viszont ki kell tudni kapcsolni őket.
Miért nem szabad sima SQL REPLACE paranccsal átírni az URL-eket?
Mert a WordPress sok beállítást PHP-serialize formában tárol, ahol a szöveg hossza is mentve van. A http helyett https egy karakterrel hosszabb, így a mentett hossz hibássá válik, és az egész rekord olvashatatlan lesz. Ilyenkor tűnhet el a sablon összes beállítása. A WP-CLI search-replace a --precise és --recurse-objects kapcsolóval ezt helyesen kezeli.
Mit csinál pontosan a --skip-columns=guid kapcsoló, és miért kell?
A guid mező a bejegyzés állandó azonosítója, nem böngészésre szánt cím. Az RSS-olvasók ez alapján döntik el, hogy egy tétel új-e. Ha átírod, a feliratkozóknál a régi bejegyzések újként jelenhetnek meg, ami tömeges, fölösleges értesítést okoz. Ezért a guid oszlopot mindig ki kell hagyni a cseréből.
Honnan tudom, hogy passzív vagy aktív kevert tartalommal van dolgom?
A böngésző konzolja megmondja. Ha a szöveg blokkolásról szól, és az erőforrás el sem indul, akkor aktív, tehát szkript, stíluslap, betűtípus, iframe vagy háttérhívás. Ha csak figyelmeztetés jelenik meg, de az elem betölt vagy némán eltűnik, akkor passzív, jellemzően kép, hang vagy videó. Az aktív eset a sürgősebb, mert funkciót tör el.
Mi legyen, ha egy régi külső szolgáltató beágyazása csak HTTP-n él?
Először kérd le újra a beágyazó kódot a szolgáltatótól, mert sok esetben már létezik HTTPS-es változat, csak a régi kód maradt az oldalon. Ha tényleg nincs, válts másik szolgáltatóra, szolgáld ki a tartalmat saját HTTPS-végponton keresztül, vagy cseréld a beágyazást szöveges hivatkozásra. A kevert tartalom meghagyása nem opció, mert a böngésző úgyis blokkolja.
Árt a keresőoptimalizálásnak, ha maradt néhány kevert tartalom hiba?
Közvetlen rangsorolási büntetésről nincs hivatalos információ. Az viszont igazolt, hogy az aktív kevert tartalom blokkolódik, ami eltörhet mérőkódot, űrlapot vagy fizetési lépést, és ezzel valós üzleti kárt okoz. A blokkolt erőforrások a Search Console jelentéseiben is megjelenhetnek. A takarítás tehát inkább működési és bizalmi kérdés, mint közvetlen rangsorolási tényező.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.