SEO kodulehe optimeerimine: avaldamiseelne kontrollnimekiri, mida saab käskudega kontrollida

Kuidas seda nimekirja kasutada

See on avaldamiseelne kontrollnimekiri, mitte essee SEO teemal. Iga rida vastab kolmele küsimusele: mida kontrollida, miks see loeb ja millega seda kontrollida. Käsud on terminalikäsud, kuhu tuleb asendada domeen ning näidisaadress päris kontrollitava lehe aadressiga.

Järjekord ei ole juhuslik. Esimesed read on blokeerivad: kui kanooniline aadress on vale või leht on noindex, ei aita ükski hilisem rida. Keskmised read mõjutavad seda, kuidas leht otsingutulemuses välja näeb. Viimased read on mõõdetavad alles mõni nädal pärast avaldamist.

Indekseeritavus ja kanoonilised aadressid

Kanoonilise aadressi teema on Google’i dokumentatsioonis duplikaat-URLide koondamise juhendis; lühidalt, iga leht peaks ütlema ühe aadressi, mida ta esindab, ja see aadress peab olema see, millele leht ka päriselt vastab. Kui leht vastab nii /artiklid/x kui /artiklid/x/ pealt, on üks neist kanooniline ja teine suunab sinna.

Keeleversioonid ja hreflang

Kui kasutad hreflang-viiteid, peab iga keeleversioon viitama endale ja teistele versioonidele. Soovi korral lisa x-default varuversioon keelte jaoks, mida eraldi ei määrata. Nõuded on Google’i kohalike versioonide juhendis: viited peavad olema vastastikused ja absoluutsed, ja iga versioon peaks kanooniliselt viitama iseendale, mitte teisele keelele.

Kaks võimalikku viga. Esimene: hreflang on ainult ühel pool. Eestikeelne leht viitab ingliskeelsele, aga ingliskeelne mitte tagasi, ja siis ei loe kumbki viide. Teine: tõlget ei ole, aga hreflang="en" on ikkagi küljes, viidates samale lehele. See on sama sisu kahekordne kuulutamine ja ajab segadusse nii kraaleri kui lugeja.

Kolmas, praktiline: kui lehed genereeritakse skriptiga, kirjuta hreflang-plokk skripti, mitte käsitsi igasse faili. Käsitsi hoitud viited lähevad paari kuuga lahku, ja keegi ei märka, sest katkine hreflang ei anna veateadet, ta lihtsalt lakkab töötamast.

Sitemap: URL-id ja usaldusväärne lastmod

Sitemapiga saad anda otsingumootorile vihje lehe viimase sisulise muudatuse kohta. Google nimetab saatmist vihjeks, mitte käsukorralduseks, ja peale loc kasutab ta ka keele- ning pildi- ja videolaiendeid. Rea lastmod väärtus on ainult nii hea, kui hästi see vastab tõele: kui kogu sitemap saab iga avaldamisega uue kuupäeva, ei ole tal rohkem infot kui sitemapil ilma kuupäevata.

robots.txt ja Content-Signal

robots.txt ütleb kraalerile, millele tal on lubatud ligi pääseda, aga see ei ole viis lehe otsingust eemaldamiseks: Google’i robots.txt juhend ütleb otse, et robotile keelatud leht võib ikkagi indekseeruda, kui teised lehed sellele viitavad. Eemaldamiseks on noindex; robots.txt on ligipääsu piiramiseks.

Content-Signal on uuem kiht samas failis. Selle süntaks on kolm märget (search, ai-input ja ai-train), mis kirjeldavad, mida tohib sinu sisuga teha: kas ehitada otsinguregistrit, kasutada seda AI mudelite sisendina (nt vastuste koostamisel) ja kas treenida mudeleid. Seda kirjeldab contentsignals.org, mille taga on Cloudflare’i teadaanne Content Signals Policy (avaldatud 24.09.2025), ja süntaks näeb välja selline:

User-Agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=yes
Allow: /

Sama fail toetab ka tee-põhist kuju, näiteks Content-Signal: /artiklid/ ai-train=no, search=yes, ai-input=yes. Kaks ausat piirangut. Cloudflare ise ütleb, et signaalid ei ole tehniline vastumeede kraapimise vastu ja mõned ettevõtted võivad neid lihtsalt eirata. Ja ai-input=no väljendab, et sa ei luba sisu kasutada AI-vastuste koostamiseks; see ei taga tehniliselt, et kõik teenused selle kasutamise lõpetavad.

Kontroll on kahes osas, sest üks käsk ei vasta mõlemale küsimusele:

# 1. HTTP/WAF ligipääs: kas robot saab vastuse, mitte politikat
curl -sI -A "OAI-SearchBot/1.4" https://arletop.com/ | head -1
# 2. robots.txt sisu: loe ja võrdle ise, milline grupp seda user-agent'i puudutab
curl -s https://arletop.com/robots.txt

HTTP 200 ja robots.txt Disallow võivad eksisteerida korraga: vastuse saamine ei tähenda, et robot tohib lehte kasutada. Sama loogika kehtib GPTBoti kohta, aga sellel robotil on teine roll: ta kogub sisu treenimiseks, mitte ei too seda ChatGPT otsinguvastustesse.

Struktuuriandmed lehe tüübi järgi

Struktuuriandmete mõte on see, et masin saab lehe tüübi kätte ilma seda tõlgendamata. Google’i Article’i juhend ütleb otse, et kohustuslikke välju ei ole (lisa need, mis sinu sisule vastavad) ja et Google ei garanteeri, et struktuuriandmeid tarbivad funktsioonid tulemuses ilmuvad. Seega: märgenda see, mida leht päriselt on.

Üks muudatus, mida paljud ei tea: Google eemaldas küsimuste-vastuste rikkaliku tulemuse otsingust 07.05.2026 ja märgenduse dokumentatsiooni 15.06.2026 (Google’i uuenduste logi). FAQPage märgendus ei anna enam eraldi tulemust. See ei tähenda, et küsimuste plokk tuleks lehelt ära võtta. See tähendab, et seda ei tasu lisada lootuses, et see tulemust muudab.

Kontroll kahe tööriistaga: Rich Results Test näitab, mida Google märgendusest välja loeb, ja Schema Markup Validator näitab, kas süntaks on schema.org’i järgi korrektne. Need testid aitavad leida süntaksi- ja nõutud väljade vigu. Lisaks kontrolli käsitsi, et märgendus vastab lehe nähtavale sisule ja Google’i sisureeglitele. Neid kvaliteedinõudeid ei ole võimalik automaatselt hinnata.

Nähtav tekst ja märgendatud tekst peavad klappima

Kui märgendus ütleb üht ja lehel on kirjas teist, on tegu masinale antud valeandmetega. Üks võimalik struktuuriandmete viga: küsimus on JSON-LD-s ümber sõnastatud, vastus lühemaks tehtud, aga nähtav plokk jäi vanaks.

Kontrolli saab osaliselt automatiseerida. Selle saidi ehitusjada võrdleb küsimuste arvu ja iga küsimuse sõnastust nähtava plokiga; vastuste vastavust masin ei kontrolli, see tuleb eraldi käsitsi üle vaadata. Selle saidi kontroll nõuab nähtava teksti ja märgenduse täpset vastavust, mis on rangem kui Google’i üldine nõue.

curl -s https://arletop.com/artiklid/kodulehe-tegemise-hind/ \
  | python3 -c "import sys,json,re; h=sys.stdin.read(); \
    nodes=[n for blk in re.findall(r'ld\+json\">(.*?)</script>', h, re.S) \
      for d in [json.loads(blk)] for n in (d.get('@graph') or [d])]; \
    faq=[n for n in nodes if n.get('@type')=='FAQPage'][0]; \
    [print(i['name'],'|',i['acceptedAnswer']['text'][:80]) for i in faq['mainEntity']]"

Väljund annab iga küsimuse ja vastuse alguse; võrdle neid silmaga lehel nähtava plokiga. Kui nad lahknevad, paranda üks kahest. Tavaliselt on õige see, mida inimene loeb.

Sama loogika kehtib jagamiskaartide ja pealkirjade kohta: og:title võib olla lühem kui title, aga ei tohi lubada midagi, mida leht ei sisalda. Lugeja, kes klikib, peab jõudma samasse kohta, mida lubadus näitas.

Core Web Vitals: kolm arvu, üks protsentiil

Lävendeid mõõdetakse 75. protsentiili juures eraldi mobiili ja lauaarvuti lõikes. See tähendab, et vähemalt 75 % mõõdetud lehelaadimistest peab jääma hea tulemuse lävendi sisse. Labori tulemus ja päris kasutajate tulemus võivad erineda suuresti, sest labor mõõdab ühte seadet ühes võrgus. Kontroll:

• PageSpeed Insights näitab mõlemat: laboriandmeid ja päris kasutajate mõõtmisandmeid, kui neid on piisavalt.
• lighthouse https://arletop.com/ --only-categories=performance, kui tööriist on paigaldatud; hea regressioonikontrolliks, mitte tõe allikaks.
• Kolmas asi, mida sageli unustatakse: staatilise lehe puhul on suurim kiiruse risk vahemällu jäänud vana CSS või JS. Kui faili aadress ei muutu, ei tea brauser, et sisu muutus.

Sisemine lingistruktuur

Praktiline siht: iga indekseeritav leht on avalehelt kuni kolme klõpsu kaugusel ja tal on vähemalt üks kontekstuaalne sisemine link, mis ei ole navigatsioonis. Leht, kuhu ei viita ükski teine leht, on orvuks jäänud. Sitemap ütleb, et ta on olemas, aga saidi struktuur ei ütle, et ta loeb.

Kontroll on kolm sammu ja esimesed kaks ei ole veel mõõtmine. Esiteks kontrolli, et sisemised viited ei ole katki (see käsk ei loenda sissetulevaid linke, ainult lahendab sihtmärke):

node tools/check.mjs --quiet           # katkised sisemised viited

Teiseks lase saidil läbi käia, et näha, milliseid lehti üldse leitakse (see väljund on Markdown, mitte sügavusraport):

crwl https://arletop.com/ --deep-crawl bfs --max-pages 60 -o markdown

Kolmandaks loenda sissetulevad sisemised lingid ise, näiteks lehe HTML-ist lingitud aadresside kaupa ja koonda lehe kohta; lehed nulliga on orvud. Kui lehed on genereeritud failidest, saab sama loendi teha skriptiga üle kõigi HTML-failide ja seda kontrolli lisada ehitusjadasse.

Klastri struktuur aitab siin rohkem kui ükski tehniline seade: üks teenuseleht (hub) ja temalt viitavad artiklid, mis viitavad tagasi hubile ja üksteisele. Kui iga artikkel lingib kõigile kümnele teenusele, ei ütle see lingivõrk enam midagi. Selle saidi teenuselehed on hubid, näiteks kodulehed ja SEO, ja artiklid on nende laiendused.

Jagamiskaardid

og:image peab olema absoluutne aadress ja päriselt olemas. Selle saidi jagamiskaardi sihtmõõt on 1200 × 630 pikslit; see on levinud valik, mitte universaalne nõue. Katkine pilt ei anna viga, ta lihtsalt jätab kaardi tühjaks. Kontroll on kaks käsku ja üks pilk:

curl -s https://arletop.com/ | grep -o 'property="og:[^"]*" content="[^"]*"'
curl -sI "$(curl -s https://arletop.com/ | grep -o 'og:image" content="[^"]*' | cut -d'"' -f3)" | head -3

Need kaks käsku kontrollivad, et silt on olemas ja pilt vastab. Pildi tegelikud mõõtmed tuleb eraldi üle vaadata, sest HTTP-vastus ei ütle suurust. Kolmas samm on see, mida automaatne kontroll ei tee: saada link ise endale sõnumisse ja vaata, kas kaart näeb välja nii, nagu kavandasid.

llms.txt ja IndexNow: mida need teevad ja mida mitte

Kaks tehnilist asja, mille ümber on rohkem müra kui sisu, seega tasub piirid täpselt paika panna.

IndexNow on protokoll, mis teatab otsingumootorile, et URL muutus, ilma et peaks ootama kraalerit. Dokumentatsiooni järgi saab ühe POST-päringuga saata kuni 10 000 URLi, omandit tõestab juurkaustas olev võtmefail ja HTTP 200 tähendab ainult, et mootor on URLi kätte saanud. Osalejad on küsimuste-vastuste lehel loetletud: Bing, Yandex, Seznam.cz, Naver, Yep ja Amazon. Google’i selles nimekirjas ei ole ja Google’i Indexing API lubab saata ainult JobPosting-märgendusega lehti ning VideoObjecti sisse paigutatud BroadcastEvent-märgendusega otseülekande lehti. Ehk IndexNow on kiirendus Bingile ja teistele, mitte Google’ile.

llms.txt on ettepanek panna saidi juurde Markdown-fail, mis kirjeldab saidi sisu masinale loetaval kujul (llmstxt.org, autor Jeremy Howard, avaldatud 03.09.2024). Google’i AI-optimeerimise juhend ütleb selle kohta otse: „Google Search itself doesn’t use them.“ Fail võib olla kasulik arendusagentidele ja tööriistadele, kes sellest hoolivad, aga see ei ole Google’i nähtavuse hoob ja seda ei tasu müüa nähtavuse hoovana.

AI-kraalerite juures loeb see, kas nad on robots.txt-is nimeliselt lubatud: OAI-SearchBot (OpenAI kraalerite leht: kui see on välja lülitatud, ei kuvata saiti ChatGPT otsinguvastustes) ja PerplexityBot (Perplexity kraalerite leht). Kontroll on kahes osas: HTTP-vastus user-agendi päringule ütleb ainult, et WAF sind läbi laseb; robots.txt reeglid loe ise üle, sest HTTP 200 ja Disallow võivad korraga kehtida.

Otsingukonsool ja mõõtmine

1. Kinnita omand enne avaldamist

   Search Console domeeniomandi kinnitus DNS-kirjega katab kõik alamdomeenid ja mõlemad hostid. Kui kinnitad alles pärast avaldamist, kaotad esimesed nädalad andmeid.

2. Esita sitemap ja kontrolli iga uut URL-i käsitsi

   URL Inspection üksiku URLi kohta näitab, kas leht on indekseeritud ja millist kanoonilist Google kasutab. Uue saidi puhul tasub see teha iga lehe kohta, mitte loota, et sitemap kõik lahendab.

3. Vaata üle Search generative AI control

   Property seadetes Settings → Search generative AI näed, kas sait on Google’i generatiivsetest funktsioonidest välja jäetud. Kui control on välja lülitatud, ei aita ükski teine rida selles nimekirjas. Dokumentatsioon: Search generative AI control.

4. Lisa Bing Webmaster Tools ja vaata tsitaate

   Bing lisab AI Performance’i vaate (avalik eelvaade, veebruar 2026), mis näitab, kui tihti sisu Copiloti ja Bingi AI-kokkuvõtetes tsiteeritakse, sh „Total Citations“ ja „Grounding queries“. See on üks koht, kust AI-tsitaatide kohta numbrit vaadata.

5. Kirjuta baastase enne muudatusi

   Kui palju klikke ja näitamisi oli enne, kui hakkasid struktuuri muutma. Ilma selle reata ei tea sa hiljem, kas paranemine tuli sinu tööst või hooajast.

Kuidas ma ise seda kontrollin

Nimekiri on kasulik ainult siis, kui seda ei pea mälu järgi läbi käima. Selle saidi ehitusjada genereerib artiklid, chrome’i, keeleversioonid, sitemapi, feedid ja llms.txt uuesti ning jooksutab seejärel enne avaldamist node tools/check.mjs. Kontroll katkestab avaldamise, kui leiab mõne järgmistest vigadest:

• kanooniline aadress ei ühti saidi originiga ja lehe teega;
• pealkiri on pärast saidi sufiksi eemaldamist pikem kui 60 tähemärki, või kirjeldus on väljaspool 70–160 tähemärgi vahemikku;
• og:image puudub, või viitab /assets/og/ failile, mida kettal ei ole (muud pildiaadressid jäävad kontrollimata ja puuduv kaart on hoiatus, mitte viga);
• küsimuste arv või küsimuse sõnastus erineb nähtava ploki omast (vastuste teksti masin ei võrdle);
• artiklil puudub datePublished, dateModified, autori @id või vähemalt kolm tsiteeritud allikat;
• leivapuru märgendus erineb nähtavast leivapurust;
• kaks lehte kannavad sama pealkirja, mõni sisemine viide on katki või kuskile on jäänud vana domeen.

Kaks eraldi kontrolli puudutavad genereeritud faile. node tools/sitemap.mjs --check ei kirjuta midagi ja väljub triivi korral veaga. node tools/alternates.mjs --check ei kirjuta samuti midagi, aga ainult loetleb triivi väljundis ega määra veakoodi. Avaldamise jada ei kasuta neid lippe: see genereerib mõlemad failid uuesti enne kontrolli, ja just regenereerimine hoiab avaldatava seisu õigena.

Ülejäänud read (päris kasutajate Core Web Vitalsi mõõtmised, indekseerimine ja tsitaadid AI-vastustes) ei ole kontrollitavad enne avaldamist, sest neid ei ole veel olemas. Need on avaldamisjärgsed read, ja need loevad ainult siis, kui avaldamiseelne osa on korras. Kui tahad enne töö tellimist teada, mida see nimekiri üldse maksab ja mille eest sa maksad, on see kirjas artiklis kodulehe tegemise hind. Mõlemad kuuluvad sama teenuse juurde: koduleht ja SEO.