ကိုယ်ပိုင်ဆိုဒ်ကို SEO ပြင်ဆင်ရာမှ သင်ခန်းစာများ

ရှာဖွေရေး စက်ရုပ်တစ်ခု ဖတ်သကဲ့သို့ ကျွန်ုပ်တို့ ဆိုဒ်ကို ရက်အနည်းငယ် ဖတ်ကြည့်ခဲ့ပြီး ပြင်သင့်သော အချက် ဆယ်ခုကျော် တွေ့ခဲ့သည်။ စာမျက်နှာတိုင်းတွင် FAQ block နှစ်ခု ကြေညာထားသည်။ Google က ကျွန်ုပ်တို့ရဲ့ အလှဆင်ထားသော နောက်ခံ glow ပုံကို thumbnail အဖြစ် သုံးနေသည်။ Template စာမျက်နှာအချို့က မေးခွန်းမဖြေသော ရှာဖွေမှုများအတွက် ရှာဖွေခံနေရသည်။ Staging ပေါ်ရှိ ဆိုဒ်အသစ်တစ်ခုကို ကျွန်ုပ်တို့၏ edge က ပိတ်ထားသည်။ ဘာမှ ဒရမ်တစ်တိုက် မဟုတ်ပေမယ့် အားလုံးက မြင်နိုင်မှုကို တိတ်တဆိတ် ထိခိုက်စေခဲ့သည်။

ဆိုဒ်ကို အတိုချုပ်

mythex.ai သည် build အချိန်တွင် prerender လုပ်သော single-page app ဖြစ်သည်။ Script တစ်ခုက route တိုင်းကို လျှောက်ပြီး static HTML ဖိုင်တစ်ခုစီ ရေးကာ စာမျက်နှာ၏ title၊ description နှင့် structured data (ရှာဖွေရေးစက်များက စာမျက်နှာကို ဘာလဲဆိုသည်ကို ပြောသော JSON-LD block—structured data ဆိုသည်မှာ ဘာလဲ ကို ကြည့်ပါ) ကို ထည့်သည်။ အောက်ပါအရာအများစုသည် prerender အဆင့်တွင် ရှိသည်၊ ဘာကြောင့်ဆိုသော crawler ဖတ်သော HTML သည် ထိုအဆင့်မှ ထွက်လာသောကြောင့် ဖြစ်သည်။

1. စာမျက်နှာတိုင်းက FAQ စာမျက်နှာ ဖြစ်သည်ဟု ဆိုနေသည်

ဖြစ်ရပ်။ ကျွန်ုပ်တို့၏ HTML template တွင် ဆိုဒ်တစ်ခုလုံးအတွက် FAQPage block တစ်ခု ပါသည်။ URL က /faq ကို ညွှန်သည်။ ထို့နောက် prerender က စာမျက်နှာတစ်ခုချင်းစီ၏ FAQPage ကို အပေါ်မှ ထည့်သည်။ ထို့ကြောင့် စာမျက်နှာတိုင်းတွင် နှစ်ခုစီ ပါနေသည်။ privacy policy ကပင် Google ကို ၎င်းသည် FAQ စာမျက်နှာဟု ပြောနေခဲ့သည်။

အရေးကြီးပုံ။ Google က စာမျက်နှာတစ်ခုလျှင် FAQPage တစ်ခုသာ မျှော်လင့်သည်။ အခြားနေရာကို ညွှန်သော ဒုတိယတစ်ခုသည် စာမျက်နှာ၏ markup ကို လျော့တန်ဖိုးထားခံရစေနိုင်သည်၊ လျစ်လျူရှုခံရခြင်းထက်ပင် ဆိုးသည်။

ပြင်ဆင်ချက်။ ဆိုဒ်တစ်ခုလုံး block ကို ဖယ်ရှားလိုက်ပြီ။ စာမျက်နှာတစ်ခုချင်း၏ FAQ markup ကို တစ်နေရာတည်းမှ ထုတ်သည်၊ /faq ကိုယ်တိုင်အပါအဝင်၊ မေးခွန်းအပြည့်အစုံမှ တည်ဆောက်သည်။ FAQ မရှိသော စာမျက်နှာများက FAQ ကြေညာခြင်း မရှိတော့ပါ၊ ၎င်းက အမှန်တကယ် အဖြေဖြစ်သည်။ စာမျက်နှာတစ်ခုတွင် FAQPage တစ်ခုထက်ပို ပါလာပါက prerender က build ကို ကျရှုံးစေသည်။ တစ်ယောက်ယောက်၏ မှတ်ဉာဏ်တွင်သာ ရှိသော စည်းမျဉ်းကို လူတွေ ချိုးဖောက်တတ်သည်၊ build က တားဆီးသော စည်းမျဉ်းကို မချိုးဖောက်နိုင်ပါ။

2. Google က ကျွန်ုပ်တို့အတွက် မှားသော ပုံကို သုံးခဲ့သည်

ဖြစ်ရပ်။ ရှာဖွေမှုရလဒ်များတွင် Mythex thumbnail သည် share card အစား ပင်မစာမျက်နှာ hero နောက်ကွယ်ရှိ လှုပ်ရှားနေသော glow ဖြစ်နေသည်။

ဘာကြောင့် ဖြစ်ခဲ့သလဲ။ စာမျက်နှာတစ်ခုကို ကိုယ်စားပြုသော ပုံကို Google အား ဘယ်တော့မှ မပြောခဲ့ပါ၊ ထို့ကြောင့် တွေ့သော ပုံကို ရွေးခဲ့သည်။

ပြင်ဆင်ချက်။ ပြဿနာတစ်ခု၏ ဘက်နှစ်ဖက်:

• ဘယ်ပုံက စာမျက်နှာ၏ ဖြစ်သည်ကို ပြောပါ။ ပင်မစာမျက်နှာတွင် WebPage node ရှိပြီး primaryImageOfPage က share card ကို ညွှန်သည်။ Prerender လုပ်ထားသော စာမျက်နှာတိုင်း၏ structured data တွင် ကိုယ်ပိုင်ပုံ (စာမျက်နှာ၏ share image သို့မဟုတ် မူလပုံ) ပါသည်။
• အလှဆင်ချက်ကို ဖုံးကွယ်ပါ။ နောက်ခံပုံများကို robots.txt တွင် ပိတ်ထားပြီး noindex, noimageindex header ဖြင့် ပေးသည်။ ထို့ကြောင့် ပုံရှာဖွေမှုနှင့် thumbnail များတွင် မပေါ်ပါ။

3. ရှာဖွေရေးစက်များက ကျွန်ုပ်တို့၏ လိုဂိုကိုသာ သိသည်

ကျွန်ုပ်တို့၏ Organization markup တွင် အမည်၊ လိုဂို နှင့် social link အနည်းငယ်သာ ပါသည်။ ဘရင်းဒ်ဆိုင်ရာ အချက်အလက်သာ ဖြစ်သည်။ ရှာဖွေရေးစက်များသည် ကုမ္ပဏီ၏ knowledge panel ကို မှတ်ပုံတင်အချက်အလက်ပုံစံဖြင့် တည်ဆောက်သည်။ ထို့ကြောင့် ကျွန်ုပ်တို့၏ ကုန်သွယ်လိုင်စင်မှ အချက်အလက်များ ထည့်ခဲ့သည်: ဥပဒေအရ အမည်၊ တည်ထောင်သည့်ရက်၊ တည်ထောင်သူနှင့် မှတ်ပုံတင်လိပ်စာ။ ဖုန်းနံပါတ်ကို ရည်ရွယ်ချက်ဖြင့် မထည့်ခဲ့ပါ။

4. Template စာမျက်နှာများက မေးထားသော မေးခွန်းနှင့် မဆိုင်သော အဖြေ ပေးနေသည်

ဖြစ်ရပ်။ Search Console က template စာမျက်နှာ သုံးခုတွင် impression ရှိပြီး click မရှိကြောင်း ပြသည်။ တစ်ခုက "content strategist portfolio" နှင့် ကွဲပြားမှုများအတွက် ရှာဖွေခံရပြီး၊ တစ်ခုက "best italian restaurant website design" အတွက်၊ နောက်တစ်ခုက "agile board" အုပ်စုအတွက် ဖြစ်သည်။ ထိုရှာဖွေမှုများ၏ တဝက်ခန့်တွင် "free" ပါဝင်သည်။ အဆင့်များမှာ အလယ် ၂၀ မှ ၅၀ အကြားရှိသည်။

ဘာကြောင့်လဲ။ စာမျက်နှာတစ်ခုစီက မေးထားသော မေးခွန်းနှင့် မတူသော မေးခွန်းကို ဖြေနေသည်။ အီတလီ စားသောက်ဆိုင် ဒီဇိုင်းကောင်းကို ကြည့်ချင်သူသည် builder ကို ရောင်းနေသော စာမျက်နှာသို့ ရောက်သွားသည်။

ပြင်ဆင်ချက်။ ပစ္စည်းသုံးခုစလုံးတွင် ထုတ်ကုန်အတွက် မဟုတ်ဘဲ ရှာဖွေသူအတွက် ရေးထားသော အပိုင်းတစ်ခု ထည့်ခဲ့သည်။ လူတွေ ရိုက်သော စကားလုံးများဖြင့် title နှင့် description ကို ပြင်ဆင်သည်။ ရှိပြီးသား markup အတွက် တန်ဖိုးရှိသော FAQ များ ထည့်သည်။

တူညီသော commit တွင် ပိုတိတ်ဆိတ်သော ပြဿနာတစ်ခုကိုလည်း ပြင်ခဲ့သည်။ "related templates" block က အမျိုးအစားတစ်ခုရှိ ပထမဆုံး template လေးခုကို ယူသဖြင့် portfolio template တိုင်းက portfolio လေးခုတည်းကိုသာ ညွှန်ပြနေပြီး၊ ကျန်အမျိုးအစားတွင် internal link မရှိပါ။ ၎င်းကို subcategory အလိုက် စီထားသော ring ဖြင့် အစားထိုးခဲ့သည်။ Template စာမျက်နှာ တိုင်းတွင် link ဝင် လေးခုနှင့် ထွက် လေးခု အတိအကျရှိသည်။ Prerender HTML တွင် ထို link များကို ယခု ပုံနှိပ်ပေးသည်။ ယခင်က JavaScript run ပြီးမှသာ ရှိခဲ့ပြီး crawler က ဘယ်တော့မှ မလုပ်နိုင်ပါ။

5. Deploy တိုင်း စာမျက်နှာအသစ်များကို Bing သို့ ချက်ချင်း အကြောင်းကြားခြင်း

Google သည် IndexNow ကို လျစ်လျူရှုသည်။ IndexNow သည် URL ပြောင်းလဲသည့်အခါ ရှာဖွေရေးစက်များကို အကြောင်းကြားသော protocol ဖြစ်သည်။ Bing၊ Yandex နှင့် Seznam က သုံးသည်၊ Bing ၏ index ကို ChatGPT search က ဖတ်သည်။ AI assistant များက ရှာမတွေ့နိုင်သော AI app builder သည် အမျိုးအစားတစ်မျိုး၏ ပျက်ကွက်မှု ဖြစ်သည်။

Deploy တိုင်း sitemap တစ်ခုလုံးကို တင်ခြင်းသည် key ကို rate limit ဖြစ်စေသော နည်းလမ်းဖြစ်သည်။ Deploy အများစုသည် ရှာဖွေရေးစက်များ စိတ်ဝင်စားသည့် အရာကို ပြောင်းလဲခြင်း မရှိပါ။ ထို့ကြောင့် script တစ်ခုက ဆိုဒ်က ယခု ပေးနေသော sitemap နှင့် ယခုမှ build လုပ်ထားသော sitemap ကို နှိုင်းယှဉ်ပြီး ကွာခြားချက်ကိုသာ တင်သည်။

အလုပ်ဖြစ်စေသော အသေးစိတ် နှစ်ခု:

• Deploy မလုပ်မီ snapshot ယူပါ။ Baseline ကို build အသစ် live မဖြစ်မီ ယူရမည်။ နောက်မှ ယူလျှင် "live" sitemap သည် အသစ်ဖြစ်နေပြီဖြစ်ပြီး ကွာခြားချက်အားလုံး ဗလာ ထွက်လာမည်။
• အခု စာမျက်နှာအသစ်များကိုသာ။ ကျွန်ုပ်တို့၏ sitemap တွင် lastmod ရက်စွဲ မရှိသဖြင့် script က စာမျက်နှာအသစ်များကို ကြေညာသည်၊ ပြန်ရေးထားသောအရာများကို မကြေညာပါ။ URL တိုင်းကို build ရက်စွဲဖြင့် မှတ်သားလျှင် deploy တိုင်း ဆိုဒ်တစ်ခုလုံး ပြောင်းလဲသွားသည် ဟု ထင်မည်ဖြစ်ပြီး ကျွန်ုပ်တို့ ရှောင်ခဲ့သော spam ပင် ဖြစ်သည်။

ဤ script သည် production deploy များတွင်သာ run ပြီး build ကို ဘယ်တော့မှ မကျရှုံးစေပါ။ ၎င်း run ချိန်တွင် ဆိုဒ်သည် live ဖြစ်နေပြီးဖြစ်ပြီး ရှာဖွေရေးစက် ping တစ်ခုသည် deploy အနီရောင် ဖြစ်စေရန် တန်ဖိုးမရှိပါ။

6. ကိုယ်ပိုင် edge က "not found" ပြနေသည်

/ai စာမျက်နှာများ (ထိုအကြောင်းကို ကုန်လုပ်ငန်းအမျိုးအစား တိုင်းအတွက် landing page တွင် ရေးထားသည်) ကို စတင်သောအခါ staging တွင် အားလုံးက "Not found" ပြနေပြီး static host က ပုံမှန် ပေးနေသည်။

ကျွန်ုပ်တို့၏ marketing host များရှေ့ရှိ ဝန်ဆောင်မှုသည် လမ်းကြောင်း allowlist ကိုသာ forward လုပ်သည်။ ကျန်သည်များအားလုံး hard 404 ရသည်။ /ai သည် အသစ်ဖြစ်ပြီး list ထဲ မရှိပါ။ /ai နှင့် /ai/* ကို ထည့်ပြီး ၎င်းတို့ ဖြတ်သွားသည်ကို စစ်သော test တစ်ခု ထည့်ခဲ့သည်။ သေးငယ်သော bug ဖြစ်သော်လည်း တစ်ယောက်ယောက်မသတိထားမိဘဲ အသစ်ပိုင်းကို crawler များအတွက် မမြင်ရအောင် ဖြစ်စေနိုင်သည့် အမျိုးအစား ဖြစ်သည်။

ကျွန်ုပ်တို့ ရရှိခဲ့သည့်အရာ

• Crawler ဖတ်သော HTML ကို ဖတ်ပါ။ ဤအရာအများစုသည် browser တွင် မြင်ရခဲပြီး prerender ဖိုင်တွင် ထင်ရှားသည်။
• SEO စည်းမျဉ်းများကို build စစ်ဆေးမှုများအဖြစ် ပြောင်းပါ။ "စာမျက်နှာတစ်ခုလျှင် FAQPage တစ်ခု" ကို ယခု တင်းကျပ်စွာ အသုံးချထားသည်၊ မှတ်မိခြင်းမဟုတ်တော့ပါ။
• ရှာဖွေရေးစက်များအား သင်ဆိုလိုသည်ကို ပြောပါ။ သင့်ကို ကိုယ်စားပြုသော ပုံ သို့မဟုတ် အချက်အလက်ကို မပြောပါက ၎င်းတို့က ခန့်မှန်းလိမ့်မည်။
• Search Console က လူတွေမေးခဲ့သော မေးခွန်းကို ပြောပြသည်။ Click မပါဘဲ impression များက စာမျက်နှာသည် အခြားမေးခွန်းကို ဖြေနေသည်ဟု များသောအားဖြင့် ဆိုလိုသည်။
• အားလုံးမဟုတ်ဘဲ ကွာခြားချက်များကိုသာ တင်ပါ။ ပြောင်းလဲခဲ့သည်များကိုသာ ping လုပ်ခြင်းက rate limit အတွင်း ရှိစေသည်။

သင် တည်ဆောက်ခဲ့သော ဆိုဒ်အတွက် အလားတူ လုပ်လိုပါက AI ဖြင့် တည်ဆောက်ထားသော ဝဘ်ဆိုဒ်များအတွက် SEO နှင့် Google Search Console သတ်မှတ်ခြင်း လမ်းညွှန်များတွင် အခြေခံကို ရှာနိုင်သည်။