സ്വന്തം സൈറ്റ് ശരിയാക്കിയതിൽ നിന്നുള്ള SEO പാഠങ്ങൾ

ഒരു search engine വായിക്കുന്ന രീതിയിൽ ഞങ്ങളുടെ സ്വന്തം സൈറ്റ് കുറച്ചു ദിവസം വായിച്ചു, പരിഹരിക്കേണ്ട ആറ് കാര്യങ്ങൾ കണ്ടെത്തി. ഓരോ പേജും രണ്ട് FAQ ബ്ലോക്കുകൾ പ്രഖ്യാപിച്ചിരുന്നു, Google ഞങ്ങളുടെ തംബ്നെയിലായി ഹീറോയുടെ അലങ്കാര പശ്ചാത്തല ഗ്ലോ ഉപയോഗിച്ചിരുന്നു, ചില ടെംപ്ലേറ്റ് പേജുകൾ അവ ഉത്തരം നൽകാത്ത തിരയലുകൾക്ക് റാങ്ക് ചെയ്തിരുന്നു, സ്റ്റേജിംഗിൽ ഒരു പുതിയ വിഭാഗം ഞങ്ങളുടെ തന്നെ edge തടഞ്ഞിരുന്നു. ഒന്നും നാടകീയമായിരുന്നില്ല. എല്ലാം നിശബ്ദമായി ദൃശ്യതയ്ക്ക് വില കൊടുക്കുകയായിരുന്നു.

ഒരു ഖണ്ഡികയിൽ സൈറ്റ്

mythex.ai ഒരു single-page app ആണ്, അത് ബിൽഡ് സമയത്ത് ഞങ്ങൾ prerender ചെയ്യുന്നു: ഒരു സ്ക്രിപ്റ്റ് ഓരോ route-ഉം നടന്ന് അതിനായി ഒരു static HTML ഫയൽ എഴുതുന്നു, പേജിന്റെ title, description, structured data (ഏത് പേജാണെന്ന് search engine-കളോട് പറയുന്ന JSON-LD ബ്ലോക്ക് — structured data എന്താണ് കാണുക) എന്നിവ കുത്തിവെക്കുന്നു. താഴെ പറയുന്നവയിൽ മിക്കതും ആ prerender ഘട്ടത്തിലാണ്, കാരണം crawler യഥാർത്ഥത്തിൽ വായിക്കുന്നത് ആ HTML ആണ്.

1. ഓരോ പേജും FAQ പേജാണെന്ന് അവകാശപ്പെട്ടു

ലക്ഷണം. ഞങ്ങളുടെ HTML ടെംപ്ലേറ്റിൽ സൈറ്റ് മുഴുവനുമുള്ള ഒരു FAQPage ബ്ലോക്ക് ഉണ്ടായിരുന്നു, അതിന്റെ URL /faq ലേക്ക് ചൂണ്ടി. Prerender പിന്നീട് ഓരോ പേജിന്റെയും സ്വന്തം FAQPage അതിന് മുകളിൽ ചേർത്തു. അതുകൊണ്ട് സൈറ്റിലെ ഓരോ പേജും രണ്ടെണ്ണം അയച്ചു — ഞങ്ങളുടെ പ്രൈവസി പോളിസി പോലും Google-നോട് അത് FAQ പേജാണെന്ന് പറഞ്ഞിരുന്നു.

എന്തുകൊണ്ട് പ്രധാനം. ഒരു പേജിന് Google പരമാവധി ഒരു FAQPage മാത്രമാണ് പ്രതീക്ഷിക്കുന്നത്. മറ്റൊരിടത്തേക്ക് ചൂണ്ടുന്ന രണ്ടാമത്തേത് അവഗണിക്കപ്പെടുക മാത്രമല്ല, പേജിന്റെ മാർക്ക്അപ്പ് വിലകുറച്ച് കാണാൻ കാരണമാകുന്ന തരത്തിലുള്ളതാണ്.

പരിഹാരം. ആഗോള ബ്ലോക്ക് ഒഴിവാക്കി. ഓരോ പേജിന്റെയും FAQ മാർക്ക്അപ്പ് ഇപ്പോൾ ഒരിടത്ത് നിന്നാണ് വരുന്നത്, /faq ഉൾപ്പെടെ — അത് ചോദ്യങ്ങളുടെ പൂർണ്ണ പട്ടികയിൽ നിന്ന് അത് നിർമ്മിക്കുന്നു. FAQ ഇല്ലാത്ത പേജുകൾ ഇപ്പോൾ ഒന്നും പ്രഖ്യാപിക്കുന്നില്ല, അതാണ് സത്യസന്ധമായ ഉത്തരം. ഏതെങ്കിലും പേജിൽ ഒന്നിലധികം FAQPage വീണ്ടും വന്നാൽ prerender ബിൽഡ് പരാജയപ്പെടുത്തുന്നു. ആരുടെയെങ്കിലും ഓർമ്മയിൽ മാത്രമുള്ള ഒരു നിയമം ലംഘിക്കപ്പെടും; ബിൽഡ് നിർബന്ധിക്കുന്ന നിയമം ലംഘിക്കപ്പെടില്ല.

2. Google ഞങ്ങൾക്ക് തെറ്റായ ചിത്രം ഉപയോഗിച്ചു

ലക്ഷണം. തിരയൽ ഫലങ്ങളിൽ Mythex തംബ്നെയിൽ ഞങ്ങളുടെ ഷെയർ കാർഡ് ആയിരുന്നില്ല, ഹോംപേജ് ഹീറോയ്ക്ക് പിന്നിലുള്ള മൃദുവായി മിന്നുന്ന ഗ്ലോ ആയിരുന്നു — ഒരു അലങ്കാര പശ്ചാത്തല ചിത്രം.

ഇത് എങ്ങനെ സംഭവിച്ചു. ഏത് ചിത്രം ഒരു പേജിനെ പ്രതിനിധീകരിക്കുന്നു എന്ന് ഞങ്ങൾ Google-നോട് പറഞ്ഞിരുന്നില്ല, അതിനാൽ അത് കണ്ടെത്തിയ ഒന്ന് തിരഞ്ഞെടുത്തു.

പരിഹാരം. ഒരേ പ്രശ്നത്തിന്റെ രണ്ട് വശങ്ങൾ:

• ഏത് ചിത്രം പേജിന്റേതെന്ന് പറയുക. ഹോംപേജിൽ ഇപ്പോൾ ഒരു WebPage നോഡ് ഉണ്ട്, അതിന്റെ primaryImageOfPage ഷെയർ കാർഡിലേക്ക് ചൂണ്ടുന്നു, കൂടാതെ prerender ചെയ്ത ഓരോ പേജിന്റെയും structured data-യിൽ സ്വന്തം ചിത്രമുണ്ട് (പേജിന്റെ ഷെയർ ചിത്രം, അല്ലെങ്കിൽ ഡിഫോൾട്ട് ഒന്ന്).
• അലങ്കാരം മറയ്ക്കുക. പശ്ചാത്തല ചിത്രങ്ങൾ ഇപ്പോൾ robots.txt-ൽ അനുവദനീയമല്ല, noindex, noimageindex ഹെഡറിനൊപ്പം നൽകുന്നു, അതിനാൽ അവ ഇമേജ് തിരയലിലും തംബ്നെയിലുകളിലും വരില്ല.

3. Search engine-കൾക്ക് ഞങ്ങളുടെ ലോഗോ മാത്രമേ അറിയാമായിരുന്നുള്ളൂ

ഞങ്ങളുടെ Organization മാർക്ക്അപ്പിൽ പേരും ലോഗോയും ചില സോഷ്യൽ ലിങ്കുകളും മാത്രമായിരുന്നു — ബ്രാൻഡിംഗ്, മറ്റൊന്നുമില്ല. Search engine-കൾ ഒരു കമ്പനിയുടെ knowledge panel നിർമ്മിക്കുന്നത് രജിസ്ട്രി പോലുള്ള വസ്തുതകളിൽ നിന്നാണ്, അതിനാൽ ഞങ്ങളുടെ ട്രേഡ് ലൈസൻസിൽ നിന്നുള്ള വസ്തുതകൾ ചേർത്തു: നിയമപരമായ പേര്, സ്ഥാപിതമായ തീയതി, സ്ഥാപകൻ, രജിസ്റ്റർ ചെയ്ത വിലാസം. ഫോൺ നമ്പർ മനഃപൂർവം ഒഴിവാക്കി.

4. ടെംപ്ലേറ്റ് പേജുകൾ തെറ്റായ ചോദ്യത്തിന് ഉത്തരം നൽകി

ലക്ഷണം. Search Console-ൽ മൂന്ന് ടെംപ്ലേറ്റ് പേജുകൾക്ക് ഇംപ്രഷനുകൾ ഉണ്ടായിരുന്നു, പക്ഷേ ക്ലിക്കുകൾ ഇല്ല. ഒന്ന് "content strategist portfolio" എന്നതിനും അതിന്റെ വകഭേദങ്ങൾക്കും, ഒന്ന് "best italian restaurant website design"-നും, ഒന്ന് "agile board" ചുറ്റുമുള്ള ഒരു കൂട്ടത്തിനും റാങ്ക് ചെയ്തു — ആ തിരയലുകളിൽ പകുതിയിലും "free" എന്ന വാക്ക് ഉണ്ടായിരുന്നു. സ്ഥാനങ്ങൾ 20-കളുടെ മധ്യം മുതൽ 50-കൾ വരെയായിരുന്നു.

എന്തുകൊണ്ട്. ഓരോ പേജും ചോദിച്ച ചോദ്യത്തിൽ നിന്ന് വ്യത്യസ്തമായ ഒന്നിന് ഉത്തരം നൽകി. ഇറ്റാലിയൻ റെസ്റ്റോറന്റ് ഡിസൈൻ നല്ലതെങ്ങനെയെന്ന് കാണാൻ ആഗ്രഹിച്ച ഒരാൾ എത്തിയത് ഒരു ബിൽഡർ വിൽക്കുന്ന പേജിലാണ്.

പരിഹാരം. മൂന്നിലും ഇപ്പോൾ ഉൽപ്പന്നത്തിന് വേണ്ടിയല്ല, തിരയലിന് വേണ്ടി എഴുതിയ ഒരു വിഭാഗമുണ്ട്, ആളുകൾ ടൈപ്പ് ചെയ്യുന്ന വാക്കുകളിലുള്ള title, description, അതേ മാർക്ക്അപ്പ് പുറപ്പെടുവിച്ചിരുന്ന FAQ-കൾ എന്നിവയും.

അതേ commit ഒരു നിശ്ശബ്ദ പ്രശ്നവും പരിഹരിച്ചു. "Related templates" ബ്ലോക്ക് ഒരു വിഭാഗത്തിലെ ആദ്യത്തെ നാല് ടെംപ്ലേറ്റുകൾ എടുത്തിരുന്നു, അതിനാൽ ഓരോ portfolio ടെംപ്ലേറ്റും ഒരേ നാല് portfolio-കളിലേക്ക് ചൂണ്ടി, ആ വിഭാഗത്തിലെ ബാക്കിയുള്ളവയ്ക്ക് ആന്തരിക ലിങ്കുകൾ ഇല്ലായിരുന്നു. അതിന് പകരം ഉപവിഭാഗം അനുസരിച്ച് ക്രമീകരിച്ച ഒരു റിംഗ് വെച്ചു: ഓരോ ടെംപ്ലേറ്റ് പേജിനും കൃത്യമായി നാല് ലിങ്കുകൾ അകത്തേക്കും നാല് പുറത്തേക്കും. Prerender ചെയ്ത HTML ഇപ്പോൾ ആ ലിങ്കുകളും അച്ചടിക്കുന്നു — മുമ്പ് അവ JavaScript പ്രവർത്തിച്ചതിന് ശേഷം മാത്രമേ ഉണ്ടായിരുന്നുള്ളൂ, അത് crawler ഒരിക്കലും പ്രവർത്തിപ്പിച്ചേക്കില്ല.

5. പുതിയ പേജുകൾ deploy ചെയ്ത ഉടൻ Bing-നെ അറിയിക്കുന്നു

Google IndexNow അവഗണിക്കുന്നു, ഒരു URL മാറുമ്പോൾ search engine-കളെ അറിയിക്കാനുള്ള പ്രോട്ടോക്കോൾ ആണത്. Bing, Yandex, Seznam എന്നിവ അത് ഉപയോഗിക്കുന്നു — ChatGPT search വായിക്കുന്നത് Bing-ന്റെ index ആണ്. AI assistant-കൾക്ക് കണ്ടെത്താനാകാത്ത ഒരു AI ആപ്പ് ബിൽഡർ ഒരു പ്രത്യേക തരം പരാജയമാണ്.

ഓരോ deploy-ലും മുഴുവൻ sitemap സമർപ്പിക്കുന്നത് ഒരു കീ throttle ചെയ്യപ്പെടുന്ന വഴിയാണ്, മിക്ക deploy-കളും search engine ശ്രദ്ധിക്കുന്ന ഒന്നും മാറ്റുന്നില്ല. അതിനാൽ, സൈറ്റ് ഇപ്പോൾ നൽകുന്ന sitemap-ഉം പുതുതായി നിർമ്മിച്ചതും താരതമ്യം ചെയ്യുന്ന ഒരു സ്ക്രിപ്റ്റ് വ്യത്യാസം മാത്രം സമർപ്പിക്കുന്നു.

അത് പ്രവർത്തിപ്പിച്ച രണ്ട് വിശദാംശങ്ങൾ:

• Deploy ചെയ്യുന്നതിന് മുമ്പ് സ്നാപ്പ്ഷോട്ട് എടുക്കുക. പുതിയ build തത്സമയമാകുന്നതിന് മുമ്പ് അടിസ്ഥാനം പിടിച്ചെടുക്കണം. അതിനുശേഷം "live" sitemap ഇതിനകം പുതിയതായിരിക്കും, ഓരോ വ്യത്യാസവും ശൂന്യമായി തിരിച്ചുവരും.
• ഇപ്പോൾ പുതിയ പേജുകൾ മാത്രം. ഞങ്ങളുടെ sitemap-ൽ lastmod തീയതികളില്ല, അതിനാൽ സ്ക്രിപ്റ്റ് പുതിയ പേജുകൾ അറിയിക്കുന്നു, പുനരെഴുത്തുകൾ അറിയിക്കുന്നില്ല. ഓരോ URL-നും ബിൽഡ് തീയതി ചേർത്താൽ, ഓരോ deploy-ലും മുഴുവൻ സൈറ്റും മാറിയതായി അടയാളപ്പെടും — ഒഴിവാക്കാൻ ശ്രമിച്ചിരുന്ന അതേ സ്പാം.

ഇത് production deploy-കളിൽ മാത്രം പ്രവർത്തിക്കുന്നു, ഒരിക്കലും ബിൽഡ് പരാജയപ്പെടുത്തുന്നില്ല: സ്ക്രിപ്റ്റ് പ്രവർത്തിക്കുമ്പോഴേക്കും സൈറ്റ് തത്സമയമായിരിക്കും, search engine പിംഗിന് ചുവന്ന deploy വിലമതിക്കില്ല.

6. ഞങ്ങളുടെ edge "not found" എന്ന് പറഞ്ഞു

ഞങ്ങളുടെ /ai പേജുകൾ ലോഞ്ച് ചെയ്തപ്പോൾ (ഓരോ തരം ബിസിനസിനുമുള്ള ഒരു ലാൻഡിംഗ് പേജ് എന്നതിൽ കൂടുതൽ), static ഹോസ്റ്റ് അവ ശരിയായി നൽകുമ്പോഴും സ്റ്റേജിംഗ് എല്ലാറ്റിനും "Not found" കാണിച്ചു.

ഞങ്ങളുടെ മാർക്കറ്റിംഗ് ഹോസ്റ്റുകൾക്ക് മുന്നിലുള്ള സേവനം ഒരു allowlist-ലെ പാതകൾ മാത്രമേ കൈമാറുന്നുള്ളൂ; മറ്റെന്തും കടുത്ത 404 ആകുന്നു. /ai പുതിയതായിരുന്നു, ആ list-ൽ ഉണ്ടായിരുന്നില്ല. ഞങ്ങൾ /ai, /ai/* എന്നിവ ചേർത്തു, അവ കടന്നുപോകുന്നുവെന്ന് ഉറപ്പിക്കുന്ന ഒരു ടെസ്റ്റും. ചെറിയ ബഗ് ആയിരുന്നു, പക്ഷേ ആരും ശ്രദ്ധിക്കാതെ ഒരു പുതിയ വിഭാഗത്തെ crawler-കളിൽ നിന്ന് മറയ്ക്കുന്ന തരത്തിലുള്ള ഒന്ന്.

ഞങ്ങൾ പഠിച്ചത്

• ഒരു crawler വായിക്കുന്ന HTML വായിക്കുക. ഇവയിൽ മിക്കതും ബ്രൗസറിൽ അദൃശ്യമായിരുന്നു, prerender ചെയ്ത ഫയലിൽ വ്യക്തമായിരുന്നു.
• SEO നിയമങ്ങൾ ബിൽഡ് പരിശോധനകളാക്കുക. "ഒരു പേജിന് ഒരു FAQPage" ഇപ്പോൾ ഓർത്തുവെക്കുന്നതല്ല, നിർബന്ധിക്കുന്നതാണ്.
• Search engine-കളോട് നിങ്ങൾ എന്താണ് അർത്ഥമാക്കുന്നതെന്ന് പറയുക. ഏത് ചിത്രമോ ഏത് വസ്തുതകളോ നിങ്ങളെ പ്രതിനിധീകരിക്കുന്നതെന്ന് പറഞ്ഞില്ലെങ്കിൽ, അവ ഊഹിക്കും.
• Search Console ആളുകൾ ഏത് ചോദ്യമാണ് ചോദിച്ചതെന്ന് പറയുന്നു. ക്ലിക്കില്ലാത്ത ഇംപ്രഷനുകൾ സാധാരണയായി പേജ് മറ്റൊരു ചോദ്യത്തിന് ഉത്തരം നൽകി എന്നാണ് അർത്ഥമാക്കുന്നത്.
• എല്ലാം അല്ല, വ്യത്യാസങ്ങൾ സമർപ്പിക്കുക. മാറിയതുമാത്രം പിംഗ് ചെയ്യുന്നത് rate limit-കളുടെ ശരിയായ വശത്ത് നിർത്തുന്നു.

നിങ്ങൾ നിർമ്മിച്ച ഒരു സൈറ്റിനും ഇതേ കാര്യം ചെയ്യുന്നുണ്ടെങ്കിൽ, AI-നിർമ്മിത വെബ്സൈറ്റുകൾക്കുള്ള SEO, Google Search Console സജ്ജമാക്കുന്നത് എന്നീ ഗൈഡുകൾ അടിസ്ഥാനകാര്യങ്ങൾ വിശദീകരിക്കുന്നു.