Google neredz lapas saturu: kā diagnosticēt JavaScript renderēšanas problēmu

Ja Google neredz JavaScript saturu, salīdziniet vienu konkrētu lapu trīs vietās: sākotnējā servera HTML, pārlūka renderētajā saturā un Google Search Console URL pārbaudē. Atrodiet pirmo posmu, kurā pazūd vajadzīgais teksts vai saite. Tukšs meklēšanas rezultāts vien vēl nepierāda renderēšanas kļūmi, un redzams saturs pārlūkā negarantē tā indeksēšanu.

Mājaslapas īpašnieks atver produktu katalogu un visu redz: aprakstu, specifikāciju, cenu pieprasījuma saiti. Izstrādātājam tas arī darbojas. Tomēr Google pārbaudē ir tikai navigācija un tukšs satura bloks. Lai šo atšķirību atrisinātu, komandai nepieciešams kopīgs pārbaudes objekts un pierādījumi no katra posma.

Šī ir satura pieejamības diagnostika. Tā neaizstāj pilnu SEO auditu un nav Core Web Vitals optimizācijas plāns. Ātra lapa var neparādīt meklētājam svarīgo tekstu, savukārt lēnai lapai tas var būt pieejams. Vispirms noskaidrojiet, ko konkrētais rīks faktiski ir saņēmis.

Rāpošana, renderēšana un indeksēšana ir atsevišķi posmi

Google dokumentācija izšķir URL saņemšanu, JavaScript izpildi un satura apstrādi indeksēšanai. Google spēj izpildīt JavaScript, bet tas nenozīmē, ka katras vietnes lietotāja sesija tiks atkārtota bez atšķirībām. Bloķēti resursi un servera atbildes var ietekmēt rezultātu. JavaScript SEO pamati.

Tāpēc jautājumu “kāpēc lapa nav Google?” sadaliet precīzāk. Vai pārbaudīts tieši vajadzīgais URL? Vai tas tika saņemts? Vai renderētajā HTML ir vajadzīgā rindkopa? Vai indeksēšanas pārskatā nav atsevišķa iemesla, kas neattiecas uz JavaScript? Katram jautājumam ir cits pierādījums un iespējamais labojums.

Sākumā izvēlieties vienu problemātisku lapu un vienu līdzīgas veidnes lapu, kas darbojas. Pierakstiet abu pilnos URL, valodu un pārbaudes laiku. Ja vienā pārbaudē izmantojat filtra adresi, otrā pamatlapu un trešajā citu valodu, rezultāti nebūs tieši salīdzināmi.

Izvēlieties konkrētu tekstu, kuru meklēt

Vispārīgs iespaids par tukšu lapu ir grūti pārbaudāms. Paņemiet raksturīgu apraksta teikumu un vienu svarīgu iekšējo saiti. Fiksējiet, kur tiem vajadzētu atrasties. Pārbaudes tabulā atzīmējiet klātbūtni katrā posmā, nevis tikai kopējo lapas ekrānattēlu.

Neizvēlieties navigācijas tekstu, kas atkārtojas visā vietnē. Tas var būt servera atbildē arī tad, kad produkta saturs nav ielādēts. Meklējiet pašu redzamo tekstu vai saites elementu. Datu esamība skriptā vēl nenozīmē, ka tie nonākuši lapas saturā.

Pierakstiet arī sagaidāmā teksta versiju. Ja CMS labojums tikko publicēts, bet servera kešā vēl ir iepriekšējais saturs, var rasties cita problēma nekā renderēšana. Diagnostikai jāspēj atšķirt pazudušu tekstu no novecojušas, bet veiksmīgi attēlotas versijas.

Pirmais salīdzinājums: servera HTML un pārlūka DOM

Sākotnējā HTML pārbaudiet dokumenta atbildi, pirms JavaScript papildinājis lapu. Pārlūka elementu panelī savukārt redzams pašreizējais DOM — struktūra, kas var būt mainījusies pēc skriptu izpildes. Šīs abas reprezentācijas nedrīkst saukt vienā vārdā “avots”, ja ar tām pamato atšķirīgus secinājumus.

Ja teikums ir abās, konkrētajam tekstam nav vajadzīga klienta renderēšana, lai tas būtu sākotnējā atbildē. Ja teikums ir tikai DOM, noskaidrojiet, kura darbība to ievieto. Tā var būt automātiska datu ielāde, klikšķis, ritināšana vai iepriekš saglabāta lietotāja izvēle.

Pārbaudiet arī tīru, nepieslēgtu sesiju. Redaktora pārlūkā var būt autentifikācija, saglabātas piekrišanas vai iepriekš ielādēti dati. Tas, ko redz šāda sesija, nav drošs paraugs publiskai lapai. Tomēr privātu saturu nevajag padarīt publisku tikai SEO dēļ; vispirms jānosaka, kurai informācijai vispār jābūt publiski pieejamai.

Ja saturs parādās tikai pēc lietotāja darbības, pārbaudiet ieviešanas pieņēmumu. Google norāda, ka meklētājs neveic tādas darbības kā klikšķināšana un ritināšana, lai ielādētu saturu. Atliktās ielādes prasības. Svarīga teksta pieejamībai nevajadzētu balstīties uz šādu obligātu darbību.

Otrais salīdzinājums: ko saņem Google pārbaude

Search Console URL pārbaudē nošķiriet informāciju par indeksā zināmo versiju no pašreizējā URL tiešsaistes testa. Tas var būt saturs no dažādiem brīžiem. Veiksmīgs aktuālais tests pats par sevi nenozīmē, ka lapa jau pārmeklēta no jauna vai noteikti tiks indeksēta. URL Inspection dokumentācija.

Atveriet rīka pieejamo renderēto HTML un meklējiet iepriekš izvēlēto teikumu. Apskatiet ekrānattēlu, bet neapstājieties pie tā: attēls viens pats neapliecina visas saites vai neredzamu tehnisku norāžu stāvokli. Saglabājiet arī informāciju par neielādētiem resursiem un kļūdām, ja rīks to piedāvā.

Ja teikums ir pārlūka DOM, bet Google renderētajā HTML nav, atšķirība jāmeklē starp šo sesiju ievades nosacījumiem un izpildi. Google problēmu novēršanas dokumentācija iesaka izmantot renderētā satura pārbaudi un analizēt JavaScript kļūdas. JavaScript problēmu diagnostika.

Ja teikums ir arī Google pārbaudē, nav pamata turpināt apgalvot, ka šis tests to neredz. Tad atsevišķi jāvērtē indeksēšanas statuss, izvēlētā kanoniskā adrese un citi SEO apstākļi. Renderēšanas labojums nav universāla atbilde uz jebkuru redzamības trūkumu.

Kur pārbaudīt resursus un kļūdas

Izstrādātājam nododiet konkrēto datu pieprasījumu, kas aizpilda trūkstošo bloku. Pārbaudē jānoskaidro, vai tas pabeidzas, kāda ir atbilde un vai skripts pēc tās saņemšanas turpina darbu. Viena kļūda kopīgā komponentē var pārtraukt vairākus šķietami nesaistītus satura blokus.

Atsevišķi nošķiriet lapas dokumentu, skripta failu un datu pieprasījumu. Lapa var atgriezt veiksmīgu statusu, kamēr produkta datu ielāde neizdodas. Ekrānā tad paliek vizuāli korekta čaula. Pieraksts “serveris strādā” nav pietiekams, ja pārbaudīts tikai pirmais no šiem pieprasījumiem.

Ja konstatēta piekļuves vai autentifikācijas atšķirība, to fiksējiet kā atsevišķu diagnostikas zaru. Šis raksts neparedz drošības aizsardzības atslēgšanu. Jānosaka, vai bloķēts publiskam saturam nepieciešams resurss un kā to nodrošināt, saglabājot paredzētās piekļuves robežas.

Līdzīgi rīkojieties ar nestabilu datu ielādi: saglabājiet kļūmes piemēru, laiku un tehnisko rezultātu. Veiksmīga atkārtota pārbaude neizdzēš iepriekšējo kļūmi. Tā palīdz sašaurināt apstākļus, kuros problēma rodas. Neizvēlieties tikai veiksmīgo ekrānattēlu kā labojuma pierādījumu.

Saites un HTTP statusi jāpārbauda atsevišķi

Klikšķināms elements var nebūt meklētājam uzticami nolasāma saite. Google iesaka izmantot a elementu ar href, kas norāda uz reālu adresi. Tas attiecas arī uz saitēm, kuras DOM ievieto JavaScript. Saites, kuras Google var pārmeklēt.

Pārbaudiet savu izvēlēto saiti renderētajā HTML. Vai ir mērķa URL? Vai tas atver pareizo lapu arī tiešā pieprasījumā, ne tikai pēc klikšķa lietotnē? Vai valodas versija saglabājas? Šādi var atklāt gadījumu, kad navigācija darbojas jau atvērtā vietnē, bet dziļā adrese atsevišķi neatver vajadzīgo saturu.

Pārbaudiet arī neesošu ierakstu. Ja lietotne visām adresēm atgriež vienu čaulu un kļūdu parāda tikai vēlāk, servera statuss var neatspoguļot lapas stāvokli. Google dokumentācija uzsver jēgpilnu HTTP statusu nozīmi un skaidro soft 404 risku klientā renderētās lietotnēs. Statusu nozīme.

Šajā pārbaudē nevajag sākt plašu URL pārkārtošanu. Vispirms izveidojiet sarakstu: kura adrese, kurš statuss, kurš redzamais saturs un kāds paredzētais rezultāts. Labojumam jāatrisina konstatētā neatbilstība, nesabojājot jau pareizi strādājošās lapas.

Diagnostikas lēmumu koks

Šis ir ieteikts darba rāmis vienai problēmlapai, ne konkrētas vietnes audita rezultāts.

Pie katra zara fiksējiet arī to, kas vēl nav pārbaudīts. Piemēram, “teksts nav aktuālajā testā, datu pieprasījuma kļūda vēl nav apstiprināta”. Tas ir precīzāks nodošanas rezultāts nekā “Google nesaprot mūsu CMS”.

Kad jāmaina renderēšanas arhitektūra

Ja trūkumu izraisa konkrēta kļūda, nepamatota resursa bloķēšana vai nepareizs satura ielādes nosacījums, vispirms vērtējiet mērķētu labojumu. Pilna vietnes pārbūve nav pašsaprotams pirmais solis. Pēc labojuma atkārtojiet to pašu pārbaudes secību un salīdziniet tos pašus teksta fragmentus.

Arhitektūras izvērtējums kļūst pamatotāks, ja būtisks publiskais saturs daudzās lapās pastāvīgi atkarīgs no trauslas klienta izpildes. Tad jānovērtē servera renderēšana vai iepriekš sagatavots HTML, kā arī datu aktualizēšana un kešošana. Jāsaprot, kad atjaunotā informācija nonāks publiskajā dokumentā un kas notiks kļūmes laikā.

Google dynamic rendering raksturo kā pagaidu apiešanas risinājumu, ne ieteicamu ilgtermiņa arhitektūras noklusējumu. Dynamic rendering ierobežojumi. Tāpēc piedāvājumu pasniegt atšķirīgu renderēšanas ceļu robotiem vērtējiet kopā ar uzturēšanas slodzi un satura atbilstību.

Jebkuram arhitektūras variantam vajadzīgs pieņemšanas tests. Galvenajam saturam un saitēm jābūt paredzētajā atbildē, valodu lapām jāsaglabā pareizais saturs, un kļūdām jāatspoguļo paredzētais stāvoklis. Neviens renderēšanas veids pats par sevi nesola vietu meklēšanas rezultātos.

Biežākie jautājumi

Vai Google vispār izpilda JavaScript?

Jā, bet konkrētās lapas rezultāts ir jāpārbauda. Ir svarīgi resursi, saturs un izpildes apstākļi. No tā, ka tehnoloģija ir atbalstīta, nevar secināt, ka jūsu produkta apraksts noteikti ir nonācis indeksā.

Vai labs veiktspējas vērtējums pierāda satura pieejamību?

Nē. Veiktspējas mērījums un konkrēta teksta vai saites klātbūtne ir atšķirīgas pārbaudes. Saglabājiet abus rezultātus, bet nesajauciet to nozīmi. Šeit vajadzīgs pierādījums par saturu izvēlētajā URL.

Ko darīt pēc labojuma?

Atkārtojiet pārbaudi ar to pašu URL un teksta fragmentu, saglabājiet jauno rezultātu un salīdziniet ar iepriekšējo. Turpmāko indeksēšanas stāvokli vērojiet atsevišķi. Neapgalvojiet, ka aktuālais tests jau ir Google indeksa atjaunošanas apstiprinājums.

Nododiet problēmu ar pārbaudāmiem pierādījumiem

Sagatavojiet URL, trūkstošo fragmentu, sākotnējo HTML, pārlūka DOM un Search Console pārbaudes rezultātu ar datumu. Pievienojiet konkrētas resursu kļūdas, ja tās atrastas, un skaidri nodaliet pieņēmumus. Šāda pakotne palīdz noteikt labojuma apjomu un pēc tam pierādīt, ka tas tiešām strādā.

Ja vajadzīgs tehniskā SEO un MI atrodamības izvērtējums, sāciet ar problemātisko URL un URL pārbaudes ekrānattēlu. Plašāku pārbaudes lauku skaidro SEO audita saturs, bet lietotāja veiktspēju — Core Web Vitals mērīšana.