WordPress HTTPS käyttöön: SSL, ohjaukset ja SEO

WordPress HTTPS kannattaa ottaa käyttöön vasta, kun varmuuskopio on otettu ja SSL-varmenne toimii palvelimella. Oikea järjestys on: varmuuskopio ensin, sitten varmenne, HTTPS-testaus, WordPressin URL-asetukset, 301-uudelleenohjaukset, mixed content -korjaus ja lopuksi SEO-tarkistus Search Consolessa.

Jos järjestys menee väärin, sivusto voi näyttää selaimessa SSL-virheen, kirjautuminen wp-adminiin voi rikkoutua ja Google voi nähdä HTTP- ja HTTPS-versiot epäselvinä rinnakkaisina osoitteina.

Tämä ohje on kirjoitettu pk-yrityksen näkökulmasta. Tavoite ei ole vain saada osoiteriville lukko, vaan tehdä HTTPS-siirto niin, että lomakkeet, analytiikka, sisäinen linkitys ja hakukonenäkyvyys pysyvät kunnossa.

Tässä artikkelissa

1. Mitä HTTPS ja SSL tarkoittavat WordPressissä?
2. Mikä on oikea järjestys HTTPS-siirtoon?
3. Mitä pitää tehdä ennen WordPressin URL-asetusten muuttamista?
4. Miten SSL-varmenteen vanhenemista valvotaan?
5. Miten WordPressin URL-asetukset muutetaan HTTPS-muotoon?
6. Miten HTTP ohjataan HTTPS:ään 301-uudelleenohjauksella?
7. Miten mixed content korjataan?
8. Mitä SEO-asioita pitää tarkistaa HTTPS-siirrossa?
9. Lisäosa vai hostingin oma SSL-työkalu?
10. Mitä jos HTTPS-muutos rikkoo sivuston?
11. Tarkistuslista

Mitä HTTPS ja SSL tarkoittavat WordPressissä?

HTTPS tarkoittaa, että selaimen ja palvelimen välinen yhteys on salattu. WordPressin kohdalla tämä suojaa kirjautumisia, lomakkeita, evästeitä ja kaikkea muuta liikennettä käyttäjän selaimen ja sivuston välillä.

Arkikielessä puhutaan usein SSL-varmenteesta. Teknisesti nykyinen salaus perustuu TLS:ään, mutta hostingien hallintapaneeleissa ja WordPress-ohjeissa termi “SSL” on yhä yleinen. Käytännössä molemmilla tarkoitetaan tässä yhteydessä varmennetta, jonka avulla sivusto voi toimia https://-osoitteessa.

WordPressin virallinen HTTPS-ohje sanoo olennaisen selvästi: WordPress toimii HTTPS:llä, kun TLS- tai SSL-varmenne on asennettu ja web-palvelin voi käyttää sitä. Toisin sanoen WordPressin asetuksia ei voi korjata irrallaan palvelimesta. Ensin pitää olla toimiva varmenne. (WordPress Developer Resources: HTTPS)

Mikä on oikea järjestys HTTPS-siirtoon?

Oikea järjestys WordPressin HTTPS-siirtoon on tämä:

1. Ota täydellinen varmuuskopio tiedostoista ja tietokannasta.
2. Aktivoi SSL/TLS-varmenne hostingissa tai palvelimella.
3. Testaa, että https://domain.fi aukeaa ilman varmennevirhettä.
4. Muuta WordPressin URL-asetukset HTTPS-muotoon.
5. Tee 301-uudelleenohjaus HTTP-versiosta HTTPS-versioon.
6. Korjaa mixed content eli vanhat http://-alkuiset resurssit.
7. Päivitä sisäiset linkit, canonical-merkinnät, sitemap ja hreflang-merkinnät HTTPS-muotoon.
8. Lähetä uusi sitemap Search Consoleen ja seuraa indeksointia.
9. Testaa tärkeimmät sivut, lomakkeet, analytiikka ja konversioseuranta.

Tämä järjestys on tylsä, mutta se on juuri siksi hyvä. Pahin virhe on tehdä kohta 4 ennen kohtaa 2. Silloin WordPress alkaa ohjata käyttäjiä HTTPS-osoitteeseen, mutta palvelin ei välttämättä pysty tarjoamaan toimivaa salattua yhteyttä.

Käytännössä väärä järjestys voi näyttää tältä:

1. Muutat WordPressin osoitteen http://domain.fi-muodosta https://domain.fi-muotoon.
2. SSL-varmenne ei vielä toimi palvelimella.
3. Selain yrittää avata https://domain.fi/wp-admin/.
4. Palvelin ei pysty tarjoamaan validia varmennetta.
5. Selain näyttää varoituksen, kuten “Your connection is not private”.
6. Et välttämättä pääse kirjautumaan takaisin ennen kuin home- ja siteurl-arvot korjataan tietokannasta tai WP-CLI:llä.

Googlen oma sivuston siirto-ohje käsittelee HTTP:stä HTTPS:ään siirtymistä URL-muutoksena. Se tarkoittaa, että Googlelle pitää näyttää selkeästi uusi versio: uudelleenohjaukset, canonical-merkinnät, sitemap ja sisäiset linkit kuntoon. (Google Search Central: Site moves with URL changes)

Mitä pitää tehdä ennen WordPressin URL-asetusten muuttamista?

Ennen kuin muutat mitään kohdassa Asetukset > Yleinen, tee kolme asiaa.

1. Ota varmuuskopio

Ota varmuuskopio sekä tiedostoista että tietokannasta. HTTPS-siirrossa riski ei ole pelkästään varmenteessa, vaan myös tietokannan URL-muutoksissa. Jos vaihdat tuhansia vanhoja http://-osoitteita https://-muotoon ja jokin menee väärin, palautus ilman varmuuskopiota on hidasta.

Hyvä varmuuskopio sisältää vähintään:

• WordPress-tiedostot
• wp-content/uploads eli mediatiedostot
• teemat ja lisäosat
• tietokanta
• tieto nykyisistä home- ja siteurl-arvoista

2. Aktivoi SSL-varmenne hostingissa

Useimmille pk-yrityksille käytännöllisin vaihtoehto on hostingin oma automaattinen SSL, esimerkiksi Let’s Encrypt, AutoSSL, Plesk- tai cPanel-työkalu, Seravon hallittu SSL tai muun palveluntarjoajan vastaava ratkaisu.

Manuaalinen HTTP-haaste, .well-known-kansion luonti ja CRT-, Private Key- sekä CA Bundle -kenttien kopiointi toimii joissain ympäristöissä, mutta se ei ole ensisijainen suositus, jos hosting tarjoaa automaattisen varmenteen. Käsin uusittava varmenne on ylläpitovelkaa.

Let’s Encrypt on korostanut pitkään, että lyhyet varmenneajat toimivat vain, jos uusiminen on automatisoitu. Perinteiset Let’s Encrypt -varmenteet ovat olleet voimassa 90 päivää, ja Let’s Encrypt on ilmoittanut lyhentävänsä oletusvoimassaoloja asteittain. Manuaalinen uusiminen muuttuu siis entistä huonommaksi toimintamalliksi. (Let’s Encrypt: Why ninety-day lifetimes?, Let’s Encrypt: Decreasing certificate lifetimes to 45 days)

3. Testaa HTTPS ennen WordPress-muutosta

Avaa selaimessa:

https://domain.fi/
https://www.domain.fi/

Tarkista, että selain ei näytä varmennevirhettä. Jos käytät sekä www- että ei-www-versiota, päätä kumpi on ensisijainen ja ohjaa toinen siihen.

Miten SSL-varmenteen vanhenemista valvotaan?

SSL-varmenteen pitää uusiutua automaattisesti, mutta sen lisäksi vanhenemiselle kannattaa olla erillinen hälytys. Yksi unohtunut varmenne voi riittää siihen, että selain näyttää asiakkaalle ison tietoturvavaroituksen juuri silloin, kun sivuston pitäisi tuottaa yhteydenottoja.

Tarkista ainakin nämä:

• hostingin SSL- tai AutoSSL-ilmoitukset ovat päällä
• domainin tekninen yhteyshenkilö saa varmenteisiin liittyvät viestit
• uptime- tai teknisen valvonnan työkalu seuraa SSL-varmenteen vanhenemispäivää
• hälytys tulee ennen vanhenemista, ei vasta sivuston rikkoutuessa

Työkalu voi olla hostingin oma valvonta, Better Stack, UptimeRobot, Little Warden tai muu vastaava palvelu. Tärkeintä ei ole työkalun nimi, vaan se, että joku saa hälytyksen ajoissa ja tietää, kuka korjaa tilanteen.

Miten WordPressin URL-asetukset muutetaan HTTPS-muotoon?

Kun SSL-varmenne toimii, muuta WordPressin osoitteet kohdassa:

Asetukset > Yleinen

Tarkista nämä kaksi kenttää:

• WordPressin osoite (URL)
• Sivuston osoite (URL)

Julkisella tuotantosivustolla molempien pitäisi yleensä alkaa https://.

Jos WordPress on asennettu omaan alihakemistoonsa, WordPressin osoite ja sivuston osoite voivat olla eri arvoja. Älä muuta tätä rakennetta sokkona. Tarkista ensin, miten sivusto on asennettu.

Paikallisessa kehitysympäristössä, stagingissa tai testisivustolla sama sääntö pätee eri tavalla: älä vaihda HTTP:tä HTTPS:ksi ennen kuin kyseisessä ympäristössä on toimiva paikallinen tai staging-varmenne. Esimerkiksi LocalWP osaa hallita paikallista SSL:ää omalla tavallaan, mutta se ei tarkoita, että tuotantosivuston HTTPS-asetukset voi kopioida sellaisenaan paikalliseen ympäristöön.

Miten HTTP ohjataan HTTPS:ään 301-uudelleenohjauksella?

Kun WordPress käyttää HTTPS-osoitetta, vanhat HTTP-osoitteet pitää ohjata uusiin HTTPS-osoitteisiin 301-uudelleenohjauksella.

Hyvä uudelleenohjaus tekee tämän:

http://domain.fi/palvelu/
-> https://domain.fi/palvelu/

Huono uudelleenohjaus tekee tämän:

http://domain.fi/palvelu/
-> https://domain.fi/

Jälkimmäinen hukkaa sivukohtaisen relevanssin ja heikentää käyttäjäkokemusta. Jokaisen vanhan URL-osoitteen pitäisi ohjautua vastaavaan uuteen URL-osoitteeseen.

Tarkista ohjaus myös käytännössä. Avaa tärkeä alasivu HTTP-versiona ja varmista selaimen lisäosalla, komentoriviltä tai auditointityökalulla, että ketju on mahdollisimman lyhyt:

http://domain.fi/palvelu/
-> 301
https://domain.fi/palvelu/
-> 200

Jos ketju näyttää tältä, sitä kannattaa korjata:

http://domain.fi/palvelu/
-> 301
http://www.domain.fi/palvelu/
-> 301
https://www.domain.fi/palvelu/
-> 200

Tavoite on yksi pysyvä 301-ohjaus suoraan kanoniseen HTTPS-osoitteeseen. 302-ohjaus kertoo väliaikaisesta ohjauksesta, eikä se ole normaali tavoite HTTP:stä HTTPS:ään tehtävässä sivustosiirrossa.

Vaihtoehto 1: hostingin tai palvelimen uudelleenohjaus

Tämä on usein selkein ratkaisu, jos sinulla tai teknisellä ylläpitäjällä on pääsy palvelinasetuksiin.

Apache-ympäristössä .htaccess-ohjaus voi näyttää tältä, jos ensisijainen versio on https://example.fi ilman www-alkua:

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.fi$ [NC]
RewriteRule ^ https://example.fi%{REQUEST_URI} [L,R=301]

Nginx-ympäristössä sama peruslogiikka voi näyttää tältä:

server {
  listen 80;
  server_name example.fi www.example.fi;
  return 301 https://example.fi$request_uri;
}

server {
  listen 443 ssl;
  server_name www.example.fi;
  return 301 https://example.fi$request_uri;
}

Jos ensisijainen versio on www.example.fi, vaihda esimerkin kohdeosoitteeksi https://www.example.fi. Olennaista on, että HTTP-osoitteet ja väärä host-versio ohjautuvat samaan kanoniseen HTTPS-versioon.

Älä lisää näitä mekaanisesti, jos hosting jo tekee ohjauksen. Kaksi päällekkäistä ohjausta voi aiheuttaa uudelleenohjauskierteen tai turhia lisähyppyjä.

Vaihtoehto 2: luotettava lisäosa

Jos et pääse palvelinasetuksiin, lisäosa voi olla käytännöllinen ratkaisu. Really Simple Security, aiemmalta nimeltään Really Simple SSL, voi auttaa HTTPS-ohjauksessa ja mixed content -korjauksessa.

Lisäosa ei silti poista vastuuta tarkistaa lopputulos. Se ei välttämättä löydä teemaan, sivupalkkiin, sivunrakentajaan tai kovakoodattuun HTML:ään jääneitä vanhoja HTTP-linkkejä.

Miten mixed content korjataan?

Mixed content tarkoittaa, että sivu aukeaa HTTPS-osoitteella, mutta osa resursseista latautuu edelleen HTTP:n kautta.

Tyypillisiä lähteitä ovat:

• kuvat mediakirjastossa
• logot teeman asetuksissa
• sivupalkin HTML-vimpaimet
• vanhat upotukset
• taustakuvat CSS:ssä
• fontit
• lomake- tai chat-skriptit
• sivunrakentajan tallentamat URL-osoitteet

Ongelma voi näkyä selaimen varoituksina, rikkoutuneina resursseina tai epäselvänä turvallisuustilana, vaikka SSL-varmenne on asennettu. Modernit selaimet voivat päivittää osan kuvista, videoista ja äänistä automaattisesti HTTPS-muotoon, mutta esimerkiksi skriptit, tyylit, iframe-upotukset, fontit ja monet CSS:n URL-viittaukset voidaan estää kokonaan. (MDN: Mixed content)

Korjaus etenee näin:

1. Avaa sivu selaimessa.
2. Avaa kehittäjätyökalut.
3. Katso Console- tai Security-välilehdeltä mixed content -varoitukset.
4. Etsi http://-alkuiset resurssit.
5. Korjaa linkit WordPressissä, teemassa, sivunrakentajassa tai tietokannassa.
6. Tyhjennä välimuistit.
7. Testaa uudelleen incognito-ikkunassa.

Tietokannan massakorjaukseen voi käyttää hakukorvaustyökalua, mutta ole varovainen. WordPressin tietokannassa on serialisoitua dataa, joten tavallinen tekstieditorin etsi ja korvaa -operaatio voi rikkoa asetuksia. Käytä mieluummin WordPressille tarkoitettua työkalua, WP-CLI:tä tai luotettavaa lisäosaa.

WP-CLI-esimerkki:

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

Kun testiajo näyttää järkevältä, komennon voi ajaa ilman --dry-run-valintaa. guid-sarakkeen ohittaminen on usein suositeltavaa, koska se ei ole tavallinen sivuston sisäinen linkkikenttä.

Mitä SEO-asioita pitää tarkistaa HTTPS-siirrossa?

HTTPS-siirto on SEO:n kannalta URL-muutos. Google mainitsee HTTP:stä HTTPS:ään siirtymisen esimerkkinä sivuston siirrosta, jossa URL-osoitteet muuttuvat. (Google Search Central: Site moves with URL changes)

Tarkista ainakin nämä.

1. Canonical-tagit

Jokaisen uuden HTTPS-sivun canonical-merkinnän pitää osoittaa HTTPS-versioon:

<link rel="canonical" href="https://domain.fi/palvelu/" />

Vältä tilannetta, jossa HTTPS-sivun canonical-merkintä osoittaa takaisin HTTP-versioon. Google varoittaa canonical-ohjeissaan, että HTTP-version käyttäminen sitemapissa, hreflang-merkinnöissä tai canonical-merkinnässä voi aiheuttaa ongelmia HTTPS-version ensisijaisuuden kanssa. (Google Search Central: Canonical URL)

2. Sisäiset linkit

Päivitä sisäiset linkit HTTPS-muotoon. Redirect kyllä vie käyttäjän perille, mutta sisäisen linkityksen ei kannata kierrättää Googlea ja käyttäjiä vanhan HTTP-version kautta.

Tämä koskee:

• päävalikkoa
• footer-linkkejä
• CTA-painikkeita
• blogiartikkeleiden sisäisiä linkkejä
• kuvien linkkejä
• hreflang-linkkejä
• schema-merkintöjen URL-arvoja

Jos haluat kokonaiskuvan teknisistä tarkistuksista, lue myös teknisen hakukoneoptimoinnin tarkistuslista.

3. XML-sitemap

Sitemapin pitää sisältää uudet HTTPS-osoitteet. Lähetä uusi sitemap Search Consoleen, kun uudelleenohjaukset ja canonical-merkinnät ovat kunnossa.

Google suosittelee uuden sitemapin lähettämistä sivuston siirron yhteydessä, koska se auttaa löytämään uudet URL-osoitteet nopeammin. HTTP:stä HTTPS:ään siirrossa Search Consolen Change of Address -työkalua ei käytetä, mutta sitemap ja seuranta ovat silti tärkeitä. (Google Search Central: Site moves with URL changes)

4. Search Console

Jos sinulla on Domain-omaisuus, se kattaa saman domainin alidomainit, polut ja protokollat, kuten HTTP- ja HTTPS-versiot. Jos käytät URL-prefix-omaisuutta, vahvista HTTPS-versio erikseen. (Search Console Help: Add a website property)

Seuraa muutoksen jälkeen:

• indeksoitujen URL-osoitteiden määrää
• sitemapin hyväksyntää
• 404-virheitä
• uudelleenohjausvirheitä
• vanhan HTTP-version liikenteen laskua
• uuden HTTPS-version liikenteen nousua

Pieni vaihtelu on normaalia. Jos orgaaninen liikenne putoaa selvästi eikä palaudu, yleensä syy löytyy uudelleenohjauksista, canonical-merkinnöistä, noindex-asetuksista tai sitemapista.

5. GA4, Tag Manager ja konversioseuranta

Tarkista myös analytiikka:

• GA4:n datastreamin sivuston URL
• Google Tag Managerin tagien triggerit
• lomakkeiden kiitossivut
• mainonnan konversio-URL-osoitteet
• CRM- tai webhook-integraatiot

HTTPS-siirto on pieni tekninen muutos vain paperilla. Käytännössä se voi katkaista mittauksen, jos kiitossivun URL tai triggeri on kovakoodattu HTTP-versioon.

Lisäosa vai hostingin oma SSL-työkalu?

Yleissääntö: käytä ensisijaisesti hostingin omaa automaattista SSL-ratkaisua, kun se on saatavilla. Käytä WordPress-lisäosaa täydentävänä työkaluna, jos hosting ei tarjoa kaikkea tarvittavaa tai et pääse palvelinasetuksiin.

YouTube-ohjeissa näkee usein mallin, jossa WP Encryption luo varmenteen, käyttäjä tekee HTTP-haasteen, lataa tiedostot .well-known-kansioon ja kopioi CRT-, Private Key- sekä CA Bundle -tiedot cPaneliin. Se voi toimia, mutta pk-yrityksen tuotantosivustolle automaattisesti uusiutuva varmenne on yleensä vähemmän hauras pitkäaikainen ratkaisu.

Jos varmenne pitää uusia käsin 60-90 päivän välein, prosessi on liian hauras. Yksi unohtunut uusinta riittää siihen, että sivusto näyttää asiakkaalle varoituksen.

Jos käytössä on Cloudflare tai muu CDN, tarkista erikseen, miten HTTPS toimii käyttäjän selaimen, CDN:n ja origin-palvelimen välillä. Cloudflaren Flexible SSL voi saada selaimen ja Cloudflaren välisen yhteyden näyttämään suojatulta, vaikka Cloudflaren ja oman palvelimen välinen yhteys ei ole samalla tavalla suojattu. Yrityssivustolla turvallisempi lähtökohta on yleensä se, että myös origin-palvelimella on toimiva varmenne ja CDN:n SSL-tila vastaa tätä rakennetta.

Mitä paikallisessa kehityksessä ja stagingissa pitää huomioida?

Paikallinen WordPress, staging-sivusto ja tuotantosivusto ovat eri asioita. Älä tee niissä HTTPS-muutoksia samalla logiikalla.

Paikallisessa ympäristössä:

• http://example.local voi olla täysin normaali osoite
• HTTPS vaatii paikallisen varmenteen
• selaimen SSL-virhe ei kerro samaa asiaa kuin tuotantosivustolla
• paikallinen URL ei saa päätyä tuotannon tietokantaan

Staging-ympäristössä:

• estä indeksointi
• käytä salasanasuojausta tai noindex-asetusta
• varmista, että canonical-merkinnät eivät osoita staging-domainiin
• älä lähetä staging-sitemapia Search Consoleen
• älä kopioi stagingin home- ja siteurl-arvoja tuotantoon

Tämä liittyy suoraan WordPress-hakukoneoptimointiin: hyvä sisältö ei auta, jos Google löytää vahingossa testiversion tai tuotantosivuston URL-osoitteet osoittavat paikalliseen ympäristöön.

Mitä jos HTTPS-muutos rikkoo sivuston?

Jos vaihdoit WordPressin URL-asetukset HTTPS-muotoon liian aikaisin ja wp-admin ei enää aukea, ensimmäinen tavoite on palauttaa home ja siteurl toimivaan osoitteeseen.

WP-CLI:llä korjaus voi näyttää tältä:

wp option update home 'http://example.local'
wp option update siteurl 'http://example.local'
wp cache flush

Tuotantosivustolla käytä oikeaa domainia:

wp option update home 'https://example.fi'
wp option update siteurl 'https://example.fi'
wp cache flush

Jos WP-CLI:tä ei ole käytössä, saman voi tehdä tietokannasta:

1. Avaa phpMyAdmin, Adminer tai hostingin tietokantatyökalu.
2. Etsi wp_options-taulu. Etuliite voi olla muu kuin wp_.
3. Etsi rivit siteurl ja home.
4. Palauta niihin toimiva osoite.
5. Tyhjennä välimuisti.
6. Kirjaudu uudelleen.

Jos sivusto menee uudelleenohjauskierteeseen, tarkista nämä:

• onko hostingissa HTTPS-pakotus päällä
• onko lisäosassa HTTPS-pakotus päällä
• onko .htaccess-tiedostossa oma uudelleenohjaus
• onko CDN:ssä, kuten Cloudflaressa, oma SSL-tila tai uudelleenohjaus
• tunnistaako WordPress proxy-ympäristössä HTTPS-yhteyden oikein

WordPressin virallinen HTTPS-ohje mainitsee erikseen reverse proxy -tilanteet, joissa väärä HTTPS-tunnistus voi aiheuttaa uudelleenohjauskierteen. (WordPress Developer Resources: HTTPS)

Tarkistuslista

Käy tämä lista läpi ennen ja jälkeen siirron.

Ennen muutosta

• Täysi varmuuskopio otettu.
• Pääsy hostingiin, tietokantaan ja wp-adminiin varmistettu.
• SSL-varmenne aktivoitu hostingissa.
• SSL-varmenteen vanhenemiselle asetettu hälytys.
• HTTPS-versio testattu selaimessa.
• Päätetty, käytetäänkö www- vai ei-www-versiota.
• Kehitys- ja staging-ympäristöt erotettu tuotannosta.

Muutoksen aikana

• WordPressin osoite ja Sivuston osoite vaihdettu HTTPS-muotoon vasta varmenteen jälkeen.
• HTTP -> HTTPS -ohjaus tehty 301-ohjauksena.
• Vanha HTTP-URL ohjaa vastaavaan HTTPS-URLiin.
• Tärkeät HTTP-osoitteet ohjautuvat yhdellä 301-hypyllä suoraan kanoniseen HTTPS-osoitteeseen.
• Ei uudelleenohjausketjuja tai uudelleenohjauskierteitä.
• Mixed content -varoitukset korjattu.
• Välimuistit tyhjennetty.

SEO-tarkistus

• Canonicalit osoittavat HTTPS-versioon.
• Sitemap sisältää HTTPS-URL-osoitteet.
• Sisäiset linkit päivitetty.
• Hreflang-merkinnät päivitetty, jos sivusto on monikielinen.
• Schema-merkinnöissä käytetään HTTPS-osoitteita.
• Search Consoleen lähetetty uusi sitemap.
• Tärkeimmät URL-osoitteet tarkistettu URL Inspection -työkalulla.

Liiketoiminnan tarkistus

• Yhteydenottolomakkeet toimivat.
• Kiitossivut toimivat.
• GA4 kerää dataa.
• Google Tag Manager toimii.
• Mainonnan konversioseuranta toimii.
• Verkkokaupan kassapolku toimii, jos kyseessä on verkkokauppa.

Yhteenveto

WordPress HTTPS -siirron tärkein sääntö on yksinkertainen: älä muuta WordPressin URL-asetuksia ennen kuin SSL-varmenne toimii palvelimella.

Kun teet siirron oikeassa järjestyksessä, HTTPS parantaa luottamusta, suojaa kirjautumisia ja lomakkeita sekä antaa Googlelle selkeän version sivustostasi. Kun teet sen väärässä järjestyksessä, seurauksena voi olla SSL-virhe, rikkinäinen wp-admin, mixed content -ongelmia ja SEO-signaalien hajautuminen.

Jos haluat varmistaa, että HTTPS, canonical-merkinnät, sitemap, sisäinen linkitys ja Search Console ovat samassa linjassa, tutustu SEO-konsultointiin. Käytännössä HTTPS-siirto kannattaa käsitellä osana teknistä SEO:ta, ei pelkkänä hosting-asetuksena.