Audit technického SEO je předaný. Devadesát nálezů seřazených podle závažnosti, ke každému screenshot, všechno v jednom čtyřicetistránkovém PDF.
Po osmi měsících někdo ten dokument zase otevře. Dvanáct z devadesáti je hotových. Zbylých sedmdesát osm pořád leží v souboru, do kterého už nikdo nesahá.
Na tom auditu nebylo nic špatně. Problémy s crawlem tam opravdu byly. Konflikty v canonicalech taky. Jenom se to nikdy nedostalo z toho PDF ven.
Sestavit audit nikdy nebylo to nejtěžší. Většina odborníků se potichu dohodla, že bude předstírat opak.
Ten seznam sestaví kdokoli
Screaming Frog, Search Console, pár dalších nástrojů a týden práce stačí na to, abyste zmapovali, co je rozbité skoro na jakémkoli webu. Obsahově slabé šablony. Řetězce přesměrování. Nafouklá mapa stránek. Nic z toho už dneska není žádné umění.
Nástroje se zlepšily. Checklist se ustálil.
To, co vám neřeknou, je příčina.
Crawler seskupuje nálezy podle příznaku, ne podle příčiny. Dvě stě URL adres, jejichž canonical míří na přesměrování, vypadne z nástroje jako jeden nález. Ten nález sedí. Jenom neumí říct, jestli je za tím jedna rozbitá šablona, nebo dvacet samostatných chyb.
Funguje to i obráceně. Jedna komponenta, která se nevykreslí na serveru, se projeví jako chybějící canonicaly a jako stránky bez obsahu. Dva řádky v reportu. Pod nimi jedna chyba.
Takže opravujete dvě stě URL adres jednu po druhé místo šablony, která je generuje. Nebo opravujete dva řádky zvlášť a ta chyba pod nimi chrlí další.
Za tuhle hranici se dostane jenom někdo, kdo si kromě reportu čte i kód. A ani to není náročné.
Náročné je proměnit nálezy v uzavřené tikety. Devadesát nálezů přistane na stole týmu, který má v tomhle sprintu čtyři jiné priority a o SEO sám neví nic.
To je ta skutečná práce. Většina konzultantů končí těsně předtím, než na ni dojde.
Nález není totéž co priorita
Audit končí u nálezů. Crawler jim přiřadí závažnost – vysokou, střední, nízkou – a v tom pořadí se seznam vyexportuje.
To není prioritizace. To je názor nástroje vydávaný za odborný úsudek.
Štítek závažnosti netuší, jakou má oprava cenu. Chyba 404 na stránce, na kterou vedou tři odkazy, dostane vysokou. Stejně tak noindex v šabloně kategorie se čtyřmi sty URL adresami. Stejný štítek. Dopad úplně jiný.
Závažnost popisuje problém. Priorita říká, co s ním dál. Málokdy z toho vyjde stejné pořadí.
Ten rozdíl vyplňují věci, na které žádný crawler nevidí:
Kolik má projekt vývojářů a co už mají na příští dva sprinty zabrané.
Jestli je ta oprava změna v šabloně, kterou jeden člověk nasadí za odpoledne, nebo zásah do CMS, který sežere celý sprint.
Jestli je web uprostřed přechodu na novou platformu. Pokud ano, půlka nálezů zmizí sama a druhou půlku postaví znovu se stejnou chybou – ledaže na ni teď někdo upozorní.
Jestli ta šablona vydělává, nebo existuje jenom proto, že ji někdo v roce 2019 postavil a zapomněl na ni.
Dva weby můžou mít skoro totožný report z crawlu a potřebovat úplně jiné pořadí práce.
Problém s vysokou závažností, na který v tomhle kvartálu nikdo nemá kapacitu, patří v seznamu níž než ten se střední, jehož oprava se nasadí příští týden. To není kompromis. To je přesně to, co znamená prioritizace.
Většina specialistů na technické SEO tenhle krok přeskočí. Pošlou seznam podle závažnosti dál, jako by řadit podle toho, jak vážně něco vypadá, bylo totéž co řadit podle toho, co to stojí.
Proč audit umírá v backlogu
Ten vzorec se opakuje moc často na to, aby to byla smůla.
Konzultant, který audit napsal, nesedí na plánování sprintu. Vývojář, který ho čte, nebyl na hovoru s klientem, kde se to vysvětlovalo.
Z opravy pravidla pro přesměrování se tak stane dvouřádkový tiket v Jiře bez kontextu. Vezme si ho ten, kdo má zrovna čas. A opraví to podle toho, jak si vyloží, co tím konzultant myslel.
Ve vývojovém týmu si výsledek nikdo nebere za svůj, protože ve vývojovém týmu u toho rozhodnutí nikdo nebyl.
Pak dostane redesign přednost před opravou crawl budgetu. Nová podoba domovské stránky vyhraje ten spor pokaždé. Jedno je vidět na demu. Druhé ne.
Audit neumírá na nesouhlas. Umírá na ticho. Nikdo proti němu aktivně nestojí. A nikdo za něj ani neodpovídá.
O rok později se dělá nový audit. Půlka starých nálezů tam pořád je a přibude k nim tucet nových. Nikdo ty dva seznamy nespojí, protože nikdo nesledoval, které opravy se nasadily a co se po nich stalo.
Backlog se jenom prodlužuje. Seřazený pořád stejně.
Jak to vypadá, když u té práce zůstanu
Nic z toho se do čtyřicetistránkového PDF nevejde. Takže u PDF nekončím.
Pořadí priorit, které předávám, není seznam, který podle závažnosti seřadil crawler. Stavím to pořadí na tom, co tým reálně nasadí, a na tom, co mi na podobných webech pohnulo pozicemi ve vyhledávání a tržbami.
Vychází to z let, kdy jsem sledoval, které opravy opravdu něco změnily a které jenom vypadaly naléhavě. Seznam priorit, podle kterého nikdo nejedná, má přesně takovou cenu jako ten, který nikdo nenapsal.
A ani ten můj nepřežije první kontakt s kódem. Vývojář se podívá na třetí opravu v pořadí a řekne, že je to triviální, půlka toho už je hotová kvůli něčemu jinému. Ještě ten den se posune na první místo.
Jiná oprava nakonec sahá na sdílenou komponentu, kterou před releasem nikdo otevírat nechce. Ta spadne dolů a na její místo přijde něco zdola.
Mimo tým tohle není vidět. Dostanete se k tomu jedině tak, že jste u toho, když se ta práce dělá.
Takže sedím na plánování sprintu, kde ten tiket soupeří se vším ostatním o stejné dva vývojáře.
Tiket píšu sám. Jazykem vývojáře, ne žargonem, kterému rozumím jenom já.
Když se vývojář ozve, že mu ta oprava přijde zbytečná, vysvětlím mu mechanismus, ne jenom doporučení. „Věřte mi“ nepřežije kontakt s vývojářem, který má pět dalších tiketů a jedno odpoledne.
Nevysvětluju to jenom vývojářům. Zakladatel chce vědět, proč oprava, která zní jako maličkost, stojí za dva dny kapacity ve sprintu. Marketér chce vědět, proč má redesign počkat. Oběma to vysvětlím stejně, jenom jinými slovy.
A když se tiket označí za uzavřený, zkontroluju to na živém webu. Ne stav tiketu. Tu skutečnou stránku.
Viděl jsem, jak se oprava canonicalu nasadila se špatnou URL adresou, protože vývojář zkopíroval kód z vedlejší šablony. Viděl jsem, jak změna v robots.txt zablokovala víc než ten jeden adresář, na který mířila.
Uzavřeno neznamená správně. Správně znamená jedině zkontrolováno.
Odejít po předání něco stojí
Když po tom PDF odejdete, nejde jenom o to, jak rychle se věci nasadí. Jde o to, kolikrát se to bude opravovat znovu.
Špatně pochopené doporučení sedí na živém webu měsíce. Přijde se na to až ve chvíli, kdy se návštěvnost nehne tak, jak měla. A tou dobou si už nikdo nepamatuje, která oprava měla způsobit který výsledek.
Klient svalí vinu na doporučení. To doporučení nikdy špatné nebylo. Jenom nikdo nezůstal dost blízko, aby to zachytil včas.
Vídám to tak často, že jsem přestal audit brát jako produkt s datem ukončení. Je to začátek procesu, ve kterém zůstávám, dokud nejsou problémy uzavřené, ověřené a na živém webu.
Ne proto, že se to dá víc fakturovat. Ale proto, že audit, který nikdo nenasadí, neudělal nic, ať byl na první straně jakkoli správný.
Výstupem nikdy nebyl dokument. Vždycky to byl opravený web.
Původní verze tohoto článku je anglická. Do češtiny je přeložená automaticky.

Martin Štěpánek
Konzultant enterprise technického SEO
Jsem konzultant enterprise technického SEO a vývojář. Přes deset let jsem web stavěl, než jsem ho začal opravovat, a produkční kód píšu dodnes. Čtu odpovědi, které váš web skutečně vrací, řeknu vám, které nálezy stojí za sprint, a opravu vašim vývojářům předám sám.
Newsletter o technickém SEO, který vývojáři i SEO specialisté opravdu dočtou
Jeden konkrétní problém rozebraný do konce a jasný názor, co s ním — porovnané s primární dokumentací i s tím, co vidím v auditech. A k tomu tři zprávy z posledních dvou týdnů, vybrané a vysvětlené.



Přihlásit se k odběru
Nové vydání každé dva týdny. Odhlásíte se jedním kliknutím.
Newsletter je pouze v angličtině