Zatiaľ som povolil Google Search Console na tomto blogu, hlavne preto, že nemám ešte vyhľadávanie, ale rád odkazujem na svoje predchádzajúce príspevky súvisiace s témou, o ktorej práve píšem. A zatiaľ som používal Google vyhľadávanie, aby som rýchlo našiel, kde som o tom či onom písal.

Problémy začali, keď som zistil, že niektoré príspevky, obzvlášť tie, do ktorých som vložil veľa energie, sa nezobrazujú. No prečo by ma to malo zaujímať? Záleží mi na bezpečnosti a súkromí, prečo by ma malo trápiť, čo si myslí Google? Google nerešpektuje súkromie svojich používateľov, takže ich názor by nemal mať váhu.

Google Search Console #

Google Search Console je nástroj, ktorý pomáha s viacerými vecami, ako je importovanie sitemap, odhaľovanie problémov ako obsah mimo viditeľnej oblasti na mobilných zariadeniach, odstraňovanie stránok z výsledkov vyhľadávania a samozrejme zisťovanie dôvodov, prečo niektorá stránka nie je indexovaná. A niekedy je indexovaná, ale niečo iné jej bráni zobrazovať sa vo výsledkoch vyhľadávania. A zdá sa, že dôvodov je kopu.

Kým Console zobrazí niečo užitočné, musím preukázať vlastníctvo domény. Dá sa to viacerými spôsobmi, napríklad sprístupnením čitateľného súboru z webu alebo nastavením TXT záznamu domény, pričom niektoré sú dosť podobné spôsobom, akými ACME overuje vlastníctvo domény pred vydaním TLS certifikátu. O tom som už niečo napísal tiež.

Ďalší spôsob, ako povoliť funkcionalitu Console, je zapnúť Google Analytics, napríklad vložením riadku do HTML zdrojového kódu. Chcel som sa práve tejto možnosti vyhnúť, aby som zachoval súkromie kohokoľvek, kto na stránku narazí. Nakoniec som začal písať pre seba, bez cieľa zahrnúť reklamu, takže analytika na cielenie nebola potrebná.

TXT záznam zapína aj Analytics #

Zvolil som TXT záznam pre jeho jednoduchosť, nenápadnosť z pohľadu verziovania kódu (žiadne zmeny súborov) a okamžité pokrytie domény aj subdomén.

Bez môjho vedomia táto možnosť zapne Analytics aj tak, bez zdanlivej možnosti to vypnúť. Prosím, kedykoľvek skontrolujte, či je stále zapnutá cez:

dig peterbabic.com TXT | grep -i google

Ak výstup zobrazuje reťazec google-site-verification, Analytics sú stále zapnuté, tak pozor.

Indexované, ale neuvedené stránky #

Po aktivácii Console som začal skúmať stránky chýbajúce vo výsledkoch vyhľadávania. Väčšina z nich nemala žiadny skutočný problém, boli už prehľadávané (navštívené Google botom) a zahrnuté v indexe. Dôvod, prečo asi 28 stránok, čo v čase písania bolo asi tretina všetkých príspevkov, sa nezobrazovalo, bol uvedený ako page with redirect. Vedel som, čo je presmerovanie, ale nevedel som, čo to znamená v tomto kontexte.

Nastavoval som snáď niekde v aplikácii trvalé 301 alebo dočasné 302 HTTP presmerovanie? A ak áno, kde? Je to v konfigurácii Nginxu alebo je za to zodpovedný router Single Page App (SPA)? To boli otázky, na ktoré som nevedel, že potrebujem odpovede, a zostal by som slepo ignorantný, keby som Console nezapol.

Na vine Nginx alebo SPA router #

Lepšiu časť večera som strávil skúmaním konfigurácie Nginxu, keďže bola oveľa kratšia ako kód aplikácie, takže problém tam mohol byť vylúčený oveľa skôr. Žiaľ, to nikam neviedlo. Alebo to skôr viedlo k záveru, že problém definitívne nie je v konfigurácii Nginxu. Problém musel byť v page routeri.

Router v SPA mapuje vzory v URL na rôzne časti aplikácie. To znamená, že aj keď aplikácia je len jedna stránka, router napriek tomu zvládne zmeniť URL po kliknutí na odkaz. Tým sa zaistí, že pri obnovení stránky sa používatelia ocitnú tam, kde boli pred obnovením. Bez routera by sa URL nemenilo a vždy by to bolo len doménové meno ako https://example.com, čo by znamenalo, že pri každom obnovení by sa používatelia ocitli na koreňovej stránke.

Toto smerovanie je nevyhnutné aj pre optimalizáciu pre vyhľadávače (SEO). Aby SEO mohlo prehľadávať, indexovať a zobrazovať stránku, musí mať vlastnú jedinečnú URL. Možnosť len klikať a dostať sa k požadovanému obsahu v aplikácii nestačí pre SEO, jedinečná URL je nevyhnutnou podmienkou.

Nekonzistentnosť lomky na konci URL so SPA #

Keďže toto smerovanie sa robí v kóde aplikácie, presmerovania sú tam tiež zakotvené a práve tam leží problém. Ak router vykazuje nekonzistentné správanie, nie je to dobré pre SEO. Problém, ktorý som objavil, je nekonzistentnosť v lomke na konci URL.

Router vytvárala URL spôsobom, ktorý im chýbal lomka na konci:

https://example.com/blog/my-glorious-unlisted-post

Tiež všetky odkazy na stránke boli konštruované presne rovnakým spôsobom. Ale plné URL sú napriek tomu 301 presmerované, pravdepodobne routerom, na verziu s lomkou na konci:

https://example.com/blog/my-glorious-unlisted-post/

Tieto dve adresy vyzerajú rovnako, ale z pohľadu vyhľadávača sú v skutočnosti rozdielne. V minulosti bola konvencia, že URL bez lomky na konci predstavuje súbor, zatiaľ čo URL s lomkou na konci predstavuje priečinok. Bolo to veľmi podobné prehliadačom súborov v tej dobe.

To, že nejaká URL predstavuje súbor, podporoval tiež fakt, že zobrazovala príponu, napríklad .html, ale zobrazovanie prípon v URL je dnes celkom minulosťou a priame výpisy obsahu priečinka tiež nie sú súčasťou SEO stratégie, pretože výpis obsahu priečinka ukazuje len ďalšie priečinky a názvy súborov, čo nie je veľmi užitočný obsah na indexovanie.

Takže v minulosti dávalo zmysel, aby tieto dve adresy zobrazovali rôzny obsah (obsah súboru, dokonca bez prípony v prvom príklade, zatiaľ čo obsah priečinka v druhom). Teraz chceme, aby obe adresy reprezentovali rovnaký obsah, a aby si to SEO uvedomovalo, malo by byť konzistentné presmerovanie a budovanie odkazov.

Záver #

Zapol som funkcionalitu, ktorú ponúka Google Search Console, preukázaním vlastníctva domény zahrnutím TXT záznamu medzi ostatné DNS záznamy. Tým som neúmyselne zapol Google Analytics a cítim sa podvedený, pretože to vyzerá tak, že nemám možnosť Analytics vypnúť, alebo aspoň nie s DNS možnosťou, pričom súčasne stále používam ostatné funkcie Console, hlavne kontrolovanie, či sú jednotlivé odkazy indexované.

Kontrolou detailov odkazov som zistil, že mám nekonzistentnosť v presmerovaní s lomkou na konci, o ktorej som predtým nevedel, a že za to je pravdepodobne zodpovedný router v SPA. Bez jednoduchej opravy v dohľade nechávam tento problém v backlogu.

Toto je 59. príspevok #100daystooffload.