Kai prieš kelerius metus Google oficialiai paskelbė, kad HTTPS bus laikomas reitingavimo signalu, prasidėjo masinė svetainių migracija iš HTTP į saugųjį protokolą. Tačiau kaip ir su bet kokiu rimtu technologiniu pokyčiu, čia ne viskas vyksta taip sklandžiai, kaip norėtųsi. Daugelis svetainių administratorių ir SEO specialistų susiduria su įvairiomis problemomis, kurios gali sukelti ne tik techninių nesklandumų, bet ir realaus lankomumo kritimo.
Pats esu matęs ne vieną projektą, kuris po migracijų prarado reikšmingą dalį organinio trafiko. Kartais tai užtrukdavo savaites ar net mėnesius, kol pavykdavo išsiaiškinti tikrąją problemą. Todėl šiame straipsnyje noriu pasidalinti praktine patirtimi ir aptarti dažniausias klaidas, su kuriomis susiduria specialistai, perkeliant svetaines į HTTPS.
Mišrus turinys – tylus žudikas
Viena iš dažniausių ir kartu klastingiausių problemų yra mixed content arba mišrus turinys. Situacija atrodo taip: jūsų svetainė jau veikia per HTTPS, bet kai kurie resursai (paveikslėliai, CSS failai, JavaScript bibliotekos ar iframe elementai) vis dar kraunami per HTTP. Naršyklė tokiu atveju rodo įspėjimus, o kai kuriais atvejais net blokuoja nesaugų turinį.
Problema ta, kad tokią klaidą ne visada lengva pastebėti iš karto. Jūs galite patikrinti kelias pagrindines svetainės puslapius, viskas atrodo gerai, bet kažkur giliau svetainės struktūroje slypi senų nuorodų į HTTP resursus. Ypač tai aktualu didelėms svetainėms su tūkstančiais puslapių.
Kaip spręsti? Pirma, naudokite naršyklės Developer Tools konsolę – ji iš karto parodys visus mixed content įspėjimus. Antra, įdiekite Content Security Policy (CSP) antraštę su upgrade-insecure-requests direktyva. Tai automatiškai konvertuos HTTP užklausas į HTTPS. Trečia, peržiūrėkite savo duomenų bazę ir suraskite visas nuorodas, prasidedančias „http://” – daugelis CMS sistemų turi specialius įrankius tokiai paieškai.
Redirectų chaosas
Kita klasikinė klaida – netinkamai sukonfigūruoti redirectai. Teoriškai viskas paprasta: reikia nukreipti visą HTTP trafiką į HTTPS. Praktiškai gi matau tokių dalykų: redirectai veikia tik pagrindiniame domene, bet ne subdomenuose; redirectai sukurti tik tam tikriems URL; arba, dar blogiau, sukurtas redirect grandinės, kur vartotojas pirmiausia nukreipiamas iš HTTP į HTTPS, paskui iš www į ne-www, tada dar per kokį tarpinį redirectą.
Kiekvienas papildomas redirect prideda latencijos ir gali neigiamai paveikti SEO. Google rekomenduoja naudoti 301 (permanent) redirectus ir vengti grandinių. Idealus variantas – vienas tiesioginis redirectas iš senos į naują versiją.
Praktinis patarimas: patikrinkite savo redirectus naudodami tokius įrankius kaip Screaming Frog arba tiesiog curl komandą terminale. Įsitikinkite, kad visi šie variantai nukreipia tiesiai į teisingą HTTPS versiją:
- http://example.com
- http://www.example.com
- https://example.com (jei jūsų pagrindinė versija yra su www)
Ir dar vienas dalykas – nepamirškite .htaccess ar nginx konfigūracijos faile nustatyti, kad redirectai veiktų visiems URL, ne tik pagrindiniam puslapiui.
SSL sertifikato konfigūracijos problemos
Gaunate SSL sertifikatą, įdiegiate jį serveryje ir manote, kad viskas baigta? Ne taip greitai. Yra keletas niuansų, kuriuos būtina patikrinti. Pirma, ar jūsų sertifikatas apima visus reikalingus domenus ir subdomenus? Jei turite www ir ne-www versijas, abi turi būti sertifikate. Jei naudojate subdomenus (pvz., blog.example.com, shop.example.com), jiems irgi reikia atskirų sertifikatų arba wildcard sertifikato.
Antra problema – intermediate sertifikatai. Kai kurie serverių administratoriai įdiegia tik pagrindinį SSL sertifikatą, bet pamiršta intermediate (tarpinį) sertifikatą. Dėl to kai kuriose naršyklėse svetainė gali rodyti įspėjimus apie nesaugų ryšį, nors techniškai viskas sukonfigūruota teisingai.
Trečia – SSL protokolų ir cipher suites konfigūracija. Seni protokolai kaip SSLv3 ar TLS 1.0 jau nelaikomi saugiais ir turėtų būti išjungti. Naudokite SSL Labs testą (ssllabs.com/ssltest) – tai nemokamas įrankis, kuris išsamiai patikrina jūsų SSL konfigūraciją ir pateikia rekomendacijas. Siekite bent A reitingo.
Canonical tagų ir hreflang atributų problemos
Kai migruojate į HTTPS, būtina atnaujinti visus canonical tagus. Jei jūsų puslapiuose vis dar yra canonical tagai, nurodantys į HTTP versijas, pasakote paieškos sistemoms, kad HTTP versija yra pagrindinė. Tai sukelia painiavą ir gali lemti, kad Google indeksuos ne tą versiją, kurią norite.
Panašiai ir su hreflang atributais daugiakalbėms svetainėms. Visi hreflang tagai turi būti atnaujinti, kad nurodytų į HTTPS versijas. Mačiau atvejų, kai po migracijos tarptautinės svetainės prarado reikšmingą dalį trafiko tam tikrose šalyse būtent dėl šios priežasties.
Patarimas: sukurkite paprastą skriptą arba naudokite „find and replace” funkciją savo duomenų bazėje, kad automatiškai pakeistumėte visas „http://” nuorodas į „https://” canonical ir hreflang atributuose. Bet prieš tai – darykite backup!
Google Search Console ir Analytics konfigūracija
Daug kas pamiršta, kad HTTPS versija Google Search Console yra laikoma atskira svetaine. Tai reiškia, kad turite pridėti naują property savo Search Console paskyroje ir perkelti visas nuostatas, įskaitant disavow failus, geografinį targetingą ir kitus parametrus.
Taip pat rekomenduoju pateikti naują XML sitemap su HTTPS URL. Nors Google teoriškai turėtų automatiškai perskanavoti ir atnaujinti indeksą, praktikoje tai gali užtrukti. Pateikdami sitemap pagreitinate procesą.
Google Analytics atveju situacija šiek tiek paprastesnė – dažniausiai pakanka pakeisti nustatymuose default URL iš HTTP į HTTPS. Tačiau patikrinkite, ar neturite hardcoded HTTP nuorodų savo tracking kode ar custom kampanijose. Taip pat peržiūrėkite visus filtrus ir tikslus (goals) – kartais jie būna sukurti su konkrečiomis HTTP nuorodomis.
CDN ir third-party servisų integracija
Jei naudojate CDN (Content Delivery Network), turite įsitikinti, kad jis pilnai palaiko HTTPS. Dauguma šiuolaikinių CDN provaiderių tai daro, bet reikia teisingai sukonfigūruoti. Kai kurie CDN reikalauja, kad įkeltumėte savo SSL sertifikatą, kiti suteikia shared sertifikatą.
Ypač daug problemų kyla su trečiųjų šalių servisais – reklamos tinklais, analytics įrankiais, chat widgetais, social media įskiepiais. Ne visi jie palaiko HTTPS, o jei ir palaiko, gali reikėti atnaujinti integracijos kodą. Prieš migraciją sudarykite visų trečiųjų šalių servisų sąrašą ir patikrinkite kiekvieno HTTPS palaikymą.
Yra buvę atvejų, kai po migracijos nustodavo veikti kritiniai funkcionalumai – pavyzdžiui, mokėjimo gateway arba CRM integracija – būtent dėl to, kad trečiosios šalies servisas nebuvo tinkamai sukonfigūruotas HTTPS aplinkoje.
Performance ir kešavimo niuansai
HTTPS teoriškai prideda nedidelį overhead dėl SSL handshake proceso, bet šiuolaikiniuose serveriuose su HTTP/2 palaikymu tai beveik nepastebima. Tačiau yra keletas dalykų, į kuriuos verta atkreipti dėmesį.
Pirma, įsitikinkite, kad jūsų serveris palaiko HTTP/2 – tai gerokai pagerina HTTPS svetainių greitį. Antra, sukonfigūruokite OCSP stapling, kad sumažintumėte SSL sertifikato validacijos laiką. Trečia, įjunkite HSTS (HTTP Strict Transport Security) header – tai ne tik pagerina saugumą, bet ir šiek tiek paspartina puslapių įkėlimą, nes naršyklė iš karto žino, kad turi naudoti HTTPS.
Kešavimo atveju – patikrinkite, ar jūsų kešavimo taisyklės veikia ir HTTPS versijoje. Kartais cache plugins ar serverio konfigūracija būna sukurta specifiškai HTTP URL ir gali neveikti po migracijos. Tai gali lemti dramatišką puslapių įkėlimo laiko padidėjimą.
Kai viskas atrodo gerai, bet vis tiek kažkas ne taip
Atliekate migraciją, viską patikrinat, viskas atrodo puiku, bet po kelių dienų pastebite, kad organinis trafikas krenta. Kas nutiko? Yra keletas subtilių dalykų, kuriuos lengva praleisti.
Vienas iš jų – internal linking. Jei jūsų vidaus nuorodos vis dar rodo į HTTP versijas, tai nėra kritinė klaida (nes turite redirectus), bet sukuriate nereikalingą redirect grandinę kiekviename puslapyje. Geriau atnaujinti visas vidaus nuorodas, kad jos iš karto rodytų į HTTPS versijas.
Kitas dalykas – išoriniai backlinkai. Nors jūsų redirectai perduoda link juice, idealiu atveju norėtumėte, kad svarbiausi backlinkai būtų atnaujinti ir rodytų tiesiai į HTTPS versijas. Susisiekite su svarbiausių svetainių administratoriais ir paprašykite atnaujinti nuorodas.
Taip pat nepamirškite atnaujinti nuorodų socialiniuose tinkluose, email kampanijose, offline reklamose, vizitinėse kortelėse ir kitur. Nors techniškai redirectai viską išspręs, geriau turėti tiesioginę nuorodą.
Dar viena subtili problema – robots.txt failas. Jei jūsų robots.txt turi absoliučias nuorodas su HTTP, jas reikia atnaujinti. Taip pat patikrinkite, ar robots.txt failas pasiekiamas per HTTPS – kartais serverio konfigūracija gali blokuoti prieigą.
Galiausiai, stebėkite savo svetainės veikimą bent kelias savaites po migracijos. Naudokite Google Search Console, kad matytumėte, kaip vyksta reindeksavimas. Tikėtina, kad pirmosiomis dienomis pamatysite svyravimų – tai normalu. Bet jei po 2-3 savaičių trafikas vis dar žemiau nei buvo, reikia giliau ieškoti problemų.
HTTPS migracija nėra rocket science, bet reikalauja dėmesio detalėms ir kruopštaus planavimo. Geriausia strategija – atlikti migraciją etapais, jei įmanoma. Pirmiausia išbandykite staging aplinkoje, paskui migruokite mažiau svarbius subdomenus, ir tik tada – pagrindinę svetainę. Turėkite aiškų rollback planą, jei kažkas nepavyktų. Ir svarbiausia – nepanikuokite, jei po migracijos pamatote laikinų problemų. Dauguma jų išsisprendžia per kelias savaites, kai paieškos sistemos pilnai perskanavoja ir reindeksuoja jūsų svetainę naujoje HTTPS versijoje. Svarbu tik užtikrinti, kad visos techninės detalės būtų tvarkingos, ir tada laikas padarys savo darbą.