SEO դասեր մեր սեփական կայքը շտկելուց

Մի քանի օր կարդում էինք մեր սեփական կայքը այնպես, ինչպես որոնման համակարգը, և գտանք վեց բան, որ արժեր շտկել։ Յուրաքանչյուր էջ հայտարարում էր երկու FAQ բլոկ, Google-ը մեր մանրապատկեր էր համարում դեկորատիվ ֆոնային փայլը, շաբլոնային էջերից մի քանիսը գրավում էին որոնումներ, որոնց չէին պատասխանում, և կայքի նոր բաժինը արգելափակվում էր մեր սեփական եզրային ցանցի կողմից staging-ում։ Ոչինչ դրամատիկ չէր։ Բոլորը աննկատ արժեցնում էին մեր տեսանելիությունը։

Կայքը մեկ պարբերությամբ

mythex.ai-ը մեկ էջանոց հավելված է, որը նախապես պատրաստում ենք build-ի ժամանակ․ սկրիպտը անցնում է յուրաքանչյուր երթուղու վրայով, գրում է դրա ստատիկ HTML ֆայլը և ներդնում է էջի վերնագիրը, նկարագրությունը և կառուցվածքային տվյալները (JSON-LD բլոկը, որը որոնման համակարգերին ասում է, թե ինչ է էջը՝ տե՛ս ինչ են կառուցվածքային տվյալները)։ Հետևյալի մեծ մասը ապրում է այդ նախապատրաստման քայլում, քանի որ հենց այդ HTML-ն է, որ կարդում է crawler-ը։

1. Յուրաքանչյուր էջ հայտարարում էր, որ FAQ էջն է

Սիմպտոմ։ Մեր HTML շաբլոնը կայքի մասշտաբով FAQPage բլոկ ուներ իր կառուցվածքային տվյալներում, որի URL-ը ցույց էր տալիս /faq։ Նախապատրաստումը դրան ավելացնում էր յուրաքանչյուր էջի սեփական FAQPage-ը։ Այսպիսով՝ յուրաքանչյուր էջ ուղարկում էր երկուսը, և մեր գաղտնիության քաղաքականությունը Google-ին ասում էր, որ այն FAQ էջն է։

Ինչու է սա կարևոր։ Google-ը սպասում է առավելագույնը մեկ FAQPage յուրաքանչյուր էջի համար։ Երկրորդը, որը ցույց է տալիս ուրիշ տեղ, այն տեսակն է, որից էջի նշումը գնահատվում է ցածր, ոչ միայն անտեսվում։

Շտկում։ Կայքի մասշտաբով բլոկը հանված է։ Յուրաքանչյուր էջի FAQ նշումը այժմ գալիս է մեկ տեղից, ներառյալ /faq-ը, որը այն կառուցում է բոլոր հարցերի ցուցակից։ FAQ չունեցող էջերն այժմ ոչ մեկը չեն հայտարարում, ինչը ազնիվ պատասխանն է։ Եվ նախապատրաստումը ձախողվում է build-ը, եթե որևէ էջ նորից ունենա մեկից ավելի FAQPage։ Կանոնը, որը գոյություն ունի միայն ինչ-որ մեկի հիշողության մեջ, մի օր կխախտվի․ build-ի կողմից պարտադրված կանոնը՝ ոչ։

2. Google-ը մեզ համար սխալ նկար էր օգտագործում

Սիմպտոմ։ Որոնման արդյունքներում Mythex մանրապատկերը գլխավոր էջի հերոսի հետևի փափուկ, զարկերակող փայլն էր՝ դեկորատիվ ֆոնային նկարը, այլ ոչ թե մեր կիսվելու քարտը։

Ինչու եղավ։ Մենք երբեք չէինք ասել Google-ին, թե որ նկարն է ներկայացնում էջը, և այն ընտրում էր այն, ինչ գտնում էր։

Շտկում։ Խնդրի երկու կողմը.

• Ասեք, թե որ նկարն է էջինը։ Գլխավոր էջն այժմ ունի WebPage հանգույց, որի primaryImageOfPage-ը ցույց է տալիս կիսվելու քարտին, և յուրաքանչյուր նախապատրաստված էջի կառուցվածքային տվյալները ունեն իր սեփական նկարը (էջի կիսվելու նկարը կամ լռելյայն նկարը)։
• Թաքցրեք դեկորը։ Ֆոնային նկարները այժմ արգելված են robots.txt-ում և սպասարկվում են noindex, noimageindex վերնագրով, ուստի դրանք մնում են դուրս նկարների որոնումից և մանրապատկերներից։

3. Որոնման համակարգերը գիտեին միայն մեր լոգոն

Մեր Organization նշումն ունէր անուն, լոգո և որոշ սոցիալական հղումներ՝ միայն ապրանքանիշ, ոչ ավելին։ Որոնման համակարգերը ընկերության գիտելիքի վահանակը կառուցում են ռեեստրի տիպի փաստերից, ուստի ավելացրինք այն փաստերը, որոնք կան մեր առևտրային լիցենզիայում․ օրինական անվանումը, հիմնադրման ամսաթիվը, հիմնադիրը և գրանցված հասցեն։ Հեռախոսահամարը միտումնավոր թողեցինք դուրս։

4. Շաբլոնային էջերը պատասխանում էին սխալ հարցի

Սիմպտոմ։ Search Console-ը ցույց էր տալիս երեք շաբլոնային էջ, որոնք ցուցադրումներ էին ստանում, բայց ոչ մի սեղմում։ Մեկը դասավորվում էր «content strategist portfolio» և դրա տարբերակների համար, մեկը՝ «best italian restaurant website design»-ի, մեկը՝ «agile board» խմբի համար․ այդ որոնումների կեսը պարունակում էր «free» բառը։ Դիրքերը տատանվում էին 20-ականներից մինչև 50-ականները։

Ինչու։ Յուրաքանչյուր էջ պատասխանում էր մի այլ հարցի, քան տրված հարցը։ Ով ուզում էր տեսնել, թե ինչպիսին է լավ իտալական ռեստորանի դիզայնը, հայտնվում էր էջում, որը իրեն շինարար էր վաճառում։

Շտկում։ Յուրաքանչյուրն այժմ ունի բաժին, գրված որոնման, ոչ թե արտադրանքի համար, վերնագիր և նկարագրություն՝ այն բառերով, որ մարդիկ են մուտքագրում, և FAQ-ներ, որոնք արժանի են արդեն թողարկած նշումին։

Նույն commit-ը շտկեց նաև ավելի անտեսանելի խնդիր։ «Կապված շաբլոնների» բլոկը վերցնում էր կատեգորիայի առաջին չորս շաբլոնները, ուստի յուրաքանչյուր portfolio շաբլոն ցույց էր տալիս նույն չորս portfolio-ներին, և այդ կատեգորիայի մնացածը ընդհանրապես ներքին հղումներ չուներ։ Այն փոխարինեցինք ռինգով, որը դասավորված է ըստ ենթակատեգորիայի․ յուրաքանչյուր շաբլոնային էջ այժմ ստանում է ճիշտ չորս մուտքային և չորս ելքային հղում։ Նախապատրաստված HTML-ն այժմ նաև տպում է այս հղումները․ առաջ դրանք գոյություն ունեին միայն JavaScript-ի աշխատելուց հետո, ինչը crawler-ը կարող է երբեք չկատարել։

5. Նոր էջերի մասին Bing-ին ասելը՝ հենց դրանք տեղադրվելիս

Google-ը անտեսում է IndexNow-ը, արձանագրություն, որով որոնման համակարգերը տեղեկացվում են URL-ի փոփոխության մասին։ Bing-ը, Yandex-ը և Seznam-ը օգտագործում են այն, և Bing-ի ինդեքսն է, որ կարդում է ChatGPT որոնումը։ AI հավելվածների կառուցիչ, որը AI օգնականները չեն կարողանում գտնել, այդ տեսակի ձախողում է։

Ակնհայտ մոտեցումը՝ ամբողջ sitemap-ը ուղարկել յուրաքանչյուր տեղադրման ժամանակ, այն է, ինչից բանալին սահմանափակվում է, և տեղադրումների մեծ մասը չի փոխում այն, ինչ որոնման համակարգը հոգ է տանում։ Այսպիսով, սկրիպտը համեմատում է կայքի այժմ սպասարկվող sitemap-ը նորակառուցի հետ և ուղարկում է միայն տարբերությունը։

Այն աշխատելու երկու մանրամասն․

• Նկարեք վիճակը նախքան տեղադրումը։ Հիմքը պետք է վերցվի նոր build-ը ակտիվ դառնալուց առաջ։ Դրանից հետո «ակտիվ» sitemap-ն արդեն նորն է, և բոլոր տարբերությունները դատարկ են ստացվում։
• Միայն նոր էջերը, առայժմ։ Մեր sitemap-ում lastmod ամսաթվեր չկան, ուստի սկրիպտը հայտարարում է նոր էջերը, բայց ոչ վերագրումները։ Յուրաքանչյուր URL-ին build-ի ամսաթիվ դնելը ամբողջ կայքը կնշեր որպես փոփոխված յուրաքանչյուր տեղադրման ժամանակ՝ հենց այն սպամը, որից խուսափում էինք։

Այն աշխատում է միայն production տեղադրումների ժամանակ և երբեք չի ձախողում build-ը․ երբ այն աշխատում է, կայքն արդեն ակտիվ է, և որոնման համակարգին ուղարկված հարցումը կարմիր տեղադրում չարժե։

6. Մեր սեփական եզրը ասում էր «չի գտնվել»

Երբ գործարկեցինք /ai էջերը (դրանց մասին ավելին՝ էջ յուրաքանչյուր տեսակի բիզնեսի համար), staging-ը բոլորի համար ցույց էր տալիս «Not found», մինչ ստատիկ հոսթը դրանք սպասարկում էր ճիշտ։

Ընտրողաբար, մեր մարքեթինգային հոստերի առջև գտնվող ծառայությունը փոխանցում էր միայն ուղիների թույլտվության ցուցակը, և ամեն ինչ այլ բան ստանում էր կոշտ 404։ /ai-ը նոր էր և ցուցակում չկար։ Ավելացրինք /ai և /ai/*, թեստով, որը հաստատում է, որ դրանք անցնում են։ Փոքր սխալ, բայց հենց այն տեսակը, որը նոր բաժինը անտեսանելի է դարձնում crawler-ների համար, և ոչ ոք չի նկատում։

Ինչ սովորեցինք

• Կարդացեք այն HTML-ը, որ կարդում է crawler-ը։ Դրանցից շատերը անտեսանելի էին բրաուզերում և ակնհայտ՝ նախապատրաստված ֆայլում։
• Դարձրեք SEO կանոնները build-ի ստուգումներ։ «Մեկ FAQPage յուրաքանչյուր էջի համար» այժմ պարտադրվում է, ոչ թե հիշվում։
• Ասեք որոնման համակարգերին, թե ինչ նկատի ունեք։ Եթե չասեք, թե որ նկարը կամ որ փաստերն են ներկայացնում ձեզ, նրանք կկռահեն։
• Search Console-ը ցույց է տալիս, թե ինչ հարց են տվել մարդիկ։ Ցուցադրումներ առանց սեղմումների սովորաբար նշանակում են, որ էջը պատասխանել է մեկ այլ հարցի։
• Ուղարկեք տարբերությունները, ոչ թե ամեն ինչ։ Միայն փոփոխվածի ծանուցումը պահում է ձեզ սահմանափակումների ճիշտ կողմում։

Եթե նույնն եք անում ձեր կառուցած կայքի համար, մեր ուղեցույցները՝ SEO AI-ով կառուցված կայքերի համար և Google Search Console-ի կարգավորում, ծածկում են հիմունքները։