Prin august 2014 Google anunta ca site-urile securizate ar putea beneficia de o prezenta mai buna la cautari. Lucru oarecum normal, securizarea e importanta de cand lumea.
Dar ce te faci cu site-urile care nu au nevoie de asa ceva? Aparent Google ar trebui sa stie sa faca diferenta intre un site ce necesita securizare si altul care nu necesita asa ceva. Asta ar fi asteptarea, pretentia pe care multi o au.
Uimitor se pare ca nu prea stie. Revenit dintr-o vacanta am observat ca indexul acestui blog nu mai este indexat de Google, desi restul paginilor sint bine mersi la cautari. Deci nu e o problema de penalizare generala, ci punctuala pe index. Stiind ca acest blog a crescut natural, nu mi-am pus problema de penalizare sau filtrare a site-ului.
Am inceput analiza retroactiva ptr a vedea ce s-a intamplat. Am descoperit urmatoarele:
1. Dupa propagarea acestui factor/semnal de ranking/pozitionare indexul a disparut de la cautari. M-am uitat pe niste ranking reports (Georanker si CognitiveSEO) si am vazut data cand s-a intamplat asta: pe 21 august. Bune si ranking reporturile astea, desi vorba umbla ca sint inutile. Ptr necunoscatori si creduli sunt inutile.
Un cache din 23 imi arata indexul ca fiind 302 Found, ca apoi pe 24 cand am verificat sa fie cu 404 Not Found.
2. Apoi am zis sa vad daca exista vreo legatura intre dezindexarea indexului si alte pagini ce ar fi putut fi afectate. Am descoperit in WMT ca articolele listate pe index erau automat marcate cu Soft 404. Erau in numar de 15, asta insemnand 10 articole din listarea de pe index + 5 pagini din header.
3. Am trecut rapid la a da Fetch as Google in WMT si a reindexa paginile marcand ca rezolvata „problema”. La 2 ore dupa retrimiterea spre indexare indexul e vazut de catre Google cu 302 Found. Ceea ce e un pas bun si rapid. Ma astept ca indexul sa fie readaugat in SERPs si in timp sa imi recapat pozitiile la cautari.
Problema descoperita de mine a fost urmatoarea: Google mi-a „gasit” un HTTPS ptr index. La cautarea site:krumel.ro el gaseste un URL indexistent, neactivat de mine, inutil ptr un blog existenta unui HTTPS (cu mici exceptii).
Nu e prima data cand Google gaseste link-uri inexistente, de multe ori link-urile sint create de el in SERPs, paginile nefiind create nicaieri.
Ca multe alte actualizari de SERPs sau algoritmi si acesta pare sa aiba o eroare ce sper sa o rezolve cat mai repede. Uneori oamenii isi dau seama de aceste probleme, dar de cele mai multe ori oamenii nu stiu ce se intampla. Nu m-ar mira sa nu reuseasca sa rezolve „problema” ajungand sa plateasca cu „mii de euro” un SEOist vanitos, plin de secrete.
Acum urmeaza sa vad ce se intampla dupa reidexare, „problema” e descoperita, sper ca Google sa priceapa ca a inventat/indexat o pagina doar ptr a manipula un algoritm propriu.
In Martie Google a adaugat o optiune speciala ptr HTTPS in WMT pentru indexari mai precise. Am verificat Webmaster Tools si datele inca exista, deci nu exista motive ptr a considera blogul avand versiune HTTPS.
Cred ca am indeajuns de multe motive sa cred ca e o eroare de la Google, versiunea HTTPS nu e activa, nu era indexata si nici nu cred ca ar fi avut vreun motiv ptr a fi. Cu toate astea care ar fi motivul ptr care a scos indexul de la cautari in favoarea versiunei HTTPS? Mi se pare ca a creat o problema indexistenta si care evident in multe cazuri poate fi paguboasa.
Gresesc?
–-
Voi actualiza articolul ptr a sti ce s-a intamplat intr-un final. Lucrurile au fost facute azi, 25 august 2014.
Actualizarea 1
Dupa sapaturi si discutii am aflat urmatoarele:
1. Hostul a avut dintotdeauna portul ptr SSL deschis, nu mi-l pot inchide ptr ca sint pe un host shared. Nu se justifica luarea unui VPS sau server dedicat ptr 1 blog. Ceea ce inseamna ca nu pot rezolva cu ei nimic. In plus, din .htaccess nu pot face redirect de pe HTTPS catre HTTP. E o necunoscuta ptr mine de ce nu, hostingul zice ca nu se poate.
2. Google are o problema totusi cu HTTPS-urile pe shared, sper sa rezolve problema. Momentan il las pe el sa se prinda, daca nu voi incerca altceva. Nu stiu inca ce.
Actualizarea 2
Mutat pe alt host, care aparent are rezolvata problema HTTPS-ului. Site-ul e reindexat, pozitiile la cautari au revenit.
Actualizare 3
Pe Seopedia cineva a venit cu o rezolvare data de alti hosteri: certificat SSL „Self-signed”. Aparent la el a mers.
E o galma tehnica. Chiar daca ar cauta din proprie initiativa versiunile SSL ale domeniilor, primul pas cand raspunde ceva pe portul 443 al acelui IP si nu e vorba de SNI, ar trebui sa verifice CN-ul certificatului si sa-l valideze cu numele domeniului accesat. Daca nu se valideaza, ar trebui sa le lase in pace fiindca e probabil un IP shared si un alt domeniu configurat sa raspunda prin SSL decat cel pe care incearca el sa-l acceseze.
In screenshot-ul de mai jos, daca CN-ul ar fi fost https://www.krumel.ro, *.krumel.ro sau derivate, atunci ar fi avut un motiv valid sa-l indexeze pe-ala. Altfel nu.
http://cl.ly/image/232k3c1Y2S1Y
Mi se pare complet inutil HTTPS-ul, daca site-ul nu e un magazin, sau e „lipsit de formulare” care pot fi completate de catre user, pentru a justifica o criptare prin SSL.
Minusuri: viteza de incarcare a paginilor scazuta, pierzi toate link-urile incoming existente, se schimba toate link-urile interne. Chiar daca faci redirect 301, o sa fie o scadere vizibila in serps. Merita?
Merita doar daca incepi cu un site de la 0, sau ai un magazin online care oricum deja ar trebui sa aiba paginile vitale (autentificare, cos, date cont, etc.) pe HTTPS.
Vorbesti din auzite. Viteza de incarcare e egala in cazul SSL clasic, overhead-ul fiind neglijabil la vitezele de procesare actuale, atat server-, cat si client-side. E chiar mai mare decat HTTP daca serverul stie SPDY care e SSL-only.
Iar despre „doar magazine si formulare”, tie chiar iti place sa stie ISP-ul ce site-uri vizitezi zi de zi si ce descarci? SSL-ul e un pas in directia buna. Folosirea altui/altor servere DNS si nu ale ale ISP-ului (ex OpenDNS, Google etc) ar fi trebuit sa o faci deja.
Comentariile sunt închise.