Meil on hõivatud veebisait, kus me ei kasutanud kunagi SSL-i. Hiljuti indekseeris Google seda kui https://www.example.com. Kasutajad saavad turvasertifikaadi vigu.

Google'i veebimeistri tööriistades saame eemaldada ainult suhtelise URL-i. Näiteks mis tahes asi pärast http://www.example.com.

Kasutan saidi .net veebisaidi majutamiseks IIS 6.0-d.

Olen näinud sarnaseid postitusi siin ja seal ning peaaegu kõik soovitavad ümbersuunamist. Ma ei taha ümbersuunamist seadistada, kuna see aeglustab saidi laadimist. Peaks vist ka IIS-is uue veebisaidi HTTPS-protokolliga seadistama ja siis suunama HTTP-saidile?

  • Tundub, et teie server töötab tegelikult juba HTTPS-protokolli. Kui seda ei oleks, ei töötaks sait HTTPS-i ajal üldse. Teil peab olema installitud mõni SSL-i vaikekonfiguratsiooni, näiteks ise allkirjastatud sertifikaat. See seletaks vead kasutajatele, pakkudes sisu siiski kasutajatele (või roomuritele), kes on valmis eirama hirmutavaid turvahoiatusi.
  • 4 See oleks teile palju väärtuslikum ja lihtsam oleks oma sertifikaadiprobleemi lahendada.
  • "Google'i veebimeistri tööriistades saame eemaldada ainult suhtelise URL-i." - Jah, aga peaksite vara kontrollima https://www... - siis on see selle atribuudi suhteline URL. Tõenäoliselt ei soovi te neid URL-e "eemaldada", välja arvatud juhul, kui mitte-HTTPS-leht on juba indekseeritud.
  • Ütlete, et teil on hõivatud veebisait. Osta endale 9,99 dollarit SSL-sertifikaati aastas NameCheapist või midagi muud sarnast ja olge sellega valmis!
  • HTTPS-st ei piisa tavaliselt selle kasutamise vältimiseks ning privaatsuse kasv on tohutu. Ja see on põhimõtteliselt nõutud kui hakkama saad mis tahes tundlik teave, sealhulgas paroolid. Mitu taotlust sekundis saate?

Olen väga üllatunud, et Google indekseerib katkise sertifikaadiga HTTPS-lehti. Google eelistab tavaliselt HTTPS-i saiti, kui mõlemad töötavad, kuid ma pole kunagi näinud, et see eelistaks HTTPS-i, kui katkine sert on olemas.

Teine lahendus oleks rel-kanooniliste linkide siltide juurutamine, mis osutavad HTTP-versioonile. Igal saidi lehel peaks olema silt, mis osutab selle HTTP URL-ile:

<link rel='canonical' href='http://example.com/my/page.html'> 

Kui need sildid on paigas, ütlevad nad Google'ile, et indekseeritava lehe URL on HTTP-versioon. Üks minu saitidest kasutab neid HTTP-le osutavaid silte. Google indekseerib HTTP versiooni.

  • Pole küsimusega täielikult seotud, kuid mis põhjusel oleks teil nii http kui ka https (küsin, sest ma tõesti ei tea). Kas kõigil 301 lehel on probleeme?
  • @riseagainst kujutlege, et juhite saidil myblogservice.com hostitud ajaveebiplatvormi. Iga ajaveebi URL on midagi sellist nagu userblog.blogservice.com ja te turvate need kõik ühe metamärgiga. Muidugi soovivad mõned blogijad kohandatud domeeni, mida saate hõlpsalt teha, kui nad lisavad veebisaidil www.userblog.com CNAME-kirje, osutades kasutajaleblog.blogservice.com. Kuid nüüd, kui ajaveebi lugeja läheb aadressile https: // www.userblog.com, proovib server teenindada ühendust * .blogservice.com -sertifikaadi abil, mis põhjustab nime mittevastavuse tõrke. Kuid 301 rikuks "kohandatud domeeni" kogemuse.

Kui soovite, et Google viskaks SERP-idest https-versiooni, peate 301 ümbersuunama õigele saidile või viskama 404-i https-päringute jaoks.

Ümbersuunamised on mõnevõrra paremad, sest teie kasutajad saavad selle, mida nad tahavad, isegi kui nad üritavad teie saidile pääseda https-linkide kaudu. „Mõnevõrra”, sest teie eesmärk peaks olema oma saidi teisaldamine ainult https-i ja 301-e http-i.

Parim juhtum oleks käivitada oma veebisaidi peegliversioon https-is, lisada kanoonilised sildid http-lehtedele (osutades nende kolleegidele https-is), seejärel tehke kõvasti 301, kui googlebot võtab teadmiseks kanoonika

  • "Ümbersuunamised on mõnevõrra paremad, sest teie kasutajad saavad selle, mida nad tahavad" - kuigi kasutaja näeb ikkagi esmalt brauseri kehtetu sertifikaadi hoiatust.
  • Ainult seni, kuni Google värskendab indeksit ja lõpetab külastajate saatmise HTTPS-i. 301 ümbersuunamise tõttu lõpetab Googlebot peagi HTTPS-i versiooni indekseerimise.

Nii on Google indekseerinud teie veebisaidi lehed HTTPS-iga, mis tähendab, et kasutate kas HTTPS-iga jagatud hostimist või võite olla oma serveris kasutanud iseenese allkirjastatud SSL-sertifikaati.

HTTPS vähendab veebisaidi kiirust on lihtsalt müüt, kuid tegelikult suurendab see veebisaidi kiirust võrreldes selle HTTP-versiooniga. Tehke HTTP vs HTTPS kiiruse test.

Kontrollige oma konfiguratsiooni, kui teie jagatud majutusse on installitud SSL, peate selle kas eemaldama või muundama kõik oma HTTP URL-id HTTPS-iks.

Kui olete kasutanud mõnda enda allkirjastatud SSL-i sertifikaati, eemaldage see oma serverist, hankige SSL-sertifikaat usaldusväärsest SSL-i sertifikaadi asutusest ja installige see oma serverisse.

Rakendage kindlasti 301 ümbersuunamine.

Leidsin selle küsimuse, kuna mul on sama täpne probleem ja sama täpne veebihost, meediatempel. Tundub, et seda juhtub nende teenustega palju, kuid nad eitavad järjekindlalt, et sellel oleks midagi pistmist nende või nende seadistustega.

Igatahes parandan, lisades kanoonilised URL-id oma dokumentide päisesse ja soovitan teil sama teha.

Edit: kes mu sõnastust parandas, palun ärge. Teie „parandus” oli vale.

Palju nutikam oleks kinnitada turvaliste pistikupesade sertifikaat kui selle eemaldamine analüüsist ja on palju tasuta ssl-valikuid, näiteks certbot.eff.org, mis võimaldab teil paljudel platvormidel tasuta töötada. Ma pole IIS-is kindel, kuna see on aegunud Windowsi tehnoloogia, mida tänapäeval ei soovitata. Kui teil on asp-lehti, soovitan migreeruda WordPressi või kui teil on vaja rohkem programmeerimist, siis kasutage PHP-d. Head kodeerimist

Alates 2018. aasta juulist Chrome 68 väljaandmisega märgib Chrome kõik HTTP-saidid kui „mitte turvalised”.

Chromiumi ajaveeb, turvaline veeb on siin, et jääda

Kui eemaldate HTTPS-i saidi Google'i otsinguindeksist, on teie kasutajatel rohkem raskusi. Väga varsti. Soovitaksin parandada sertifikaadivea ja edastada ainult HTTPS-i. Niipea kui võimalik.

none: Charles Robertson | none