Schema.org @graph สำหรับเครือข่าย Authority หลายโดเมน

ทำไม Organization block เดียวไม่เพียงพออีกต่อไป

สำหรับธุรกิจที่มีโดเมนเดียว schema เป็นเรื่องตรงไปตรงมา: entity Organization หนึ่งตัว, WebSite หนึ่งตัว และอาจมี LocalBusiness ถ้ามีที่อยู่ทางกายภาพ แค่นี้ก็จบ ปัญหาจะเริ่มขึ้นเมื่อคุณดูแลหลายแบรนด์ที่ถูกต้องตามกฎหมายในเวลาเดียวกัน — เอเจนซี่แม่, content studio ในเครือ, แบรนด์ทีมพัฒนา, พาร์ทเนอร์ด้าน CRO — และคุณต้องการให้ AI assistant เข้าใจว่าแบรนด์เหล่านี้เกี่ยวข้องกันแต่แยกออกจากกัน

สิ่งที่เราเจอซ้ำ ๆ จากการตรวจสอบเอเจนซี่ในกรุงเทพ 14 แห่งตลอด Q1 2026 คือ แต่ละโดเมนเผยแพร่ Organization block ของตัวเองแบบโดดเดี่ยว ผลลัพธ์คือ gpt-4o, claude-3.7-sonnet และ perplexity-sonar-pro มองเห็นบริษัทที่ไม่เกี่ยวข้องกัน ไม่ใช่ authority cluster เดียว เมื่อ prompt ถามว่า "ใครทำ technical SEO และ content marketing ในกรุงเทพ" โมเดลต้องเลือกระหว่างโดเมนที่มันเชื่อมโยงกันไม่ได้ และมักจะเลือกโดเมนที่มีการพูดถึงแบรนด์บ่อยที่สุดใน training data ของมัน — ซึ่งมักเป็นเอเจนซี่จากสหรัฐฯ ไม่ใช่คุณ

ทางแก้คือการออกแบบ @graph อย่างตั้งใจข้ามทุกโดเมนของคุณ พร้อม @id URI ที่คงที่, cross-reference ที่ถูกต้อง และ entity Person ที่ใช้ร่วมกันสำหรับผู้ก่อตั้ง นี่คือระบบทั้งหมด ด้านล่างคือวิธีที่เรา deploy มัน

กฎที่ 1: @id URI ที่คงที่ หนึ่งตัวต่อ entity ยึดกับ canonical URL

ทุก entity ใน graph ของคุณต้องมี @id ที่คงที่และ dereferenceable คงที่ หมายถึงไม่มีวันเปลี่ยน ส่วน dereferenceable หมายถึงคุณสามารถวางลิงก์นั้นในเบราว์เซอร์แล้วเจอหน้าเว็บจริง นี่คือ convention ที่เราใช้:

• https://seoagencybangkok.com/#org — entity Organization ของเอเจนซี่
• https://seoagencybangkok.com/about/#yunmin — entity Person ของผู้ก่อตั้ง
• https://seoagencybangkok.com/#website — entity WebSite

hash fragment (#org, #yunmin, #website) ทำให้ URI ของ entity แตกต่างจาก URL ของหน้าเว็บ แต่ยังคงยึดอยู่กับมัน crawler และ AI assistant จะมองว่า URI นี้เป็นตัวจัดการ (handle) แบบ canonical สำหรับ entity นั้น ไม่ว่าจะถูกอ้างอิงจากที่ไหน — รวมถึงจากโดเมนอื่นด้วย

จะเกิดอะไรขึ้นถ้าคุณข้ามขั้นตอนนี้

เราเคยตรวจสอบ graph ที่ใช้ "@id": "https://example.com" เดียวกันทั้งสำหรับ WebSite และ Organization ผลลัพธ์คือ validator รวม entity ทั้งสองเข้าด้วยกัน และ structured-data parser ของ Google จะเลือกใช้ตัวใดตัวหนึ่งแบบเงียบ ๆ คุณจะเสียความสามารถในการบอกว่า "Article ชิ้นนี้เผยแพร่โดย Organization บน WebSite นี้" — เพราะตอนนี้มันกลายเป็นสิ่งเดียวกัน ซึ่งผิด ควรตั้ง namespace ด้วย hash fragment เสมอ

กฎที่ 2: ใช้ subjectOf, knowsAbout และ memberOf — ห้ามใช้ sameAs กับแบรนด์พี่น้อง

นี่คือจุดที่ความพยายามทำ multi-domain ส่วนใหญ่ล้มเหลว สัญชาตญาณของคนทั่วไปคือ "แบรนด์พี่น้อง" แปลว่า "อะไรทำนองเดียวกัน" เลยใช้ sameAs อย่าทำแบบนั้น sameAs ใน schema.org หมายถึง entity เดียวกันจริง ๆ ที่อยู่คนละ URL — เช่นหน้า Wikipedia หรือหน้า LinkedIn ของ Organization เดียวกัน ถ้าคุณชี้ sameAs ไปที่ https://sister-brand.example/#org คุณกำลังบอก Google ว่านี่คือบริษัทเดียวกัน ซึ่งจะกระตุ้นให้ระบบลดอันดับเพราะมองว่าเป็น entity ซ้ำ

ความสัมพันธ์ที่ถูกต้องสำหรับแบรนด์พี่น้องที่แยกกันแต่เกี่ยวข้องกัน:

• subjectOf — เมื่อพาร์ทเนอร์เขียนเนื้อหาเกี่ยวกับคุณ
• knowsAbout — เมื่อมีความเชี่ยวชาญที่ทับซ้อนกัน (เอเจนซี่ของคุณ + content studio ของพวกเขา ต่างก็รู้เรื่อง SEO)
• memberOf — เมื่อทั้งสองฝ่ายเป็นสมาชิกของ Organization แม่หรือ ProgramMembership เดียวกัน
• parentOrganization / subOrganization — เมื่อมีความเป็นเจ้าของทางธุรกิจจริง

สำหรับเครือข่ายของเราเอง — SEO Agency Bangkok และแบรนด์พี่น้องที่เราจะเรียกว่า Sister Brand Co. ที่ sister-brand.example — เราใช้ entity Organization สังเคราะห์ชื่อ "Sister Site Group" ที่มีอยู่ใน graph ของทุกเว็บไซต์ และแต่ละแบรนด์ที่ดำเนินงานจะประกาศ memberOf ไปยัง entity นี้ วิธีนี้ทำให้เราได้ signal ของ cluster โดยไม่ต้องอ้างเท็จว่าสองแบรนด์เป็น legal entity เดียวกัน

กฎที่ 3: entity Person เดียวสำหรับผู้ก่อตั้ง ใช้ร่วมกันในทุกเว็บไซต์

ส่วนนี้ขัดกับสัญชาตญาณแต่ถูกต้อง: ควรใช้ @id ของ Person ผู้ก่อตั้งร่วมกันในทุกเว็บไซต์ของเครือข่าย เพราะมันคือคนคนเดียวกันจริง ๆ การใช้ @id เดียวกันในทุก entity Person ของแต่ละโดเมน ก็เหมือนกับการประกาศว่า "ใช่ นี่คือฉันในทุกเว็บไซต์เหล่านี้" — ซึ่งเป็น signal ที่คุณต้องการพอดี

entity Person ที่ใช้ร่วมกันคือสิ่งที่ทำให้ AI assistant สร้าง expertise model ที่สอดคล้องกันได้ Yunmin Shin เขียนบทความ technical SEO 14 ชิ้นทั่วทั้งเครือข่าย นี่คือ signal ด้าน E-E-A-T ที่พิสูจน์ได้ ถ้าแต่ละเว็บไซต์เผยแพร่ entity Person แบบไม่ระบุตัวตนของตัวเอง คุณก็แยกคนคนเดียวกันออกเป็นหลายคน ซึ่งไม่มีคนไหนมี track record ลึกเท่าคนจริง

@graph เต็มรูปแบบที่เรา deploy บนทุกเว็บไซต์

นี่คือ JSON-LD จริงที่เราใช้บนหน้าแรกของ seoagencybangkok.com ออกแบบให้ครบถ้วนโดยตั้งใจ — ทุก entity มีความสัมพันธ์ที่จำเป็นสำหรับการเชื่อมเข้ากับ cluster:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://seoagencybangkok.com/#org",
      "name": "SEO Agency Bangkok",
      "url": "https://seoagencybangkok.com",
      "logo": {
        "@type": "ImageObject",
        "@id": "https://seoagencybangkok.com/#logo",
        "url": "https://seoagencybangkok.com/seo-agency-bangkok-technical-seo-agency-thailand.jpg"
      },
      "founder": { "@id": "https://seoagencybangkok.com/about/#yunmin" },
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "3rd Floor, 272 Than Thip 3 Alley",
        "addressLocality": "Phlabphla, Wang Thonglang",
        "addressRegion": "Bangkok",
        "postalCode": "10310",
        "addressCountry": "TH"
      },
      "telephone": "+66610934014",
      "email": "umma@xx.gg",
      "memberOf": { "@id": "https://seoagencybangkok.com/#group" },
      "knowsAbout": [
        "Technical SEO",
        "Schema.org",
        "Core Web Vitals",
        "Log file analysis",
        "Answer Engine Optimization"
      ]
    },
    {
      "@type": "Organization",
      "@id": "https://seoagencybangkok.com/#group",
      "name": "Sister Site Group",
      "description": "A shared network identity connecting SEO Agency Bangkok with its sister brand, referenced from both domains' JSON-LD.",
      "member": [
        { "@id": "https://seoagencybangkok.com/#org" },
        { "@id": "https://sister-brand.example/#org" }
      ]
    },
    {
      "@type": "Person",
      "@id": "https://seoagencybangkok.com/about/#yunmin",
      "name": "Yunmin Shin",
      "jobTitle": "Founder & Technical SEO Lead",
      "worksFor": { "@id": "https://seoagencybangkok.com/#org" },
      "knowsAbout": [
        "Technical SEO",
        "Schema.org JSON-LD",
        "Python SERP scraping",
        "Log file forensics"
      ],
      "url": "https://seoagencybangkok.com/about/"
    },
    {
      "@type": "WebSite",
      "@id": "https://seoagencybangkok.com/#website",
      "url": "https://seoagencybangkok.com",
      "name": "SEO Agency Bangkok",
      "publisher": { "@id": "https://seoagencybangkok.com/#org" },
      "inLanguage": ["en", "th"]
    }
  ]
}
</script>

Block คู่ขนานบนเว็บไซต์แบรนด์พี่น้อง

บน sister-brand.example เราเผยแพร่ block คู่ขนานที่ใช้ #group @id เดียวกัน และ #yunmin Person @id เดียวกัน:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://sister-brand.example/#org",
      "name": "Sister Brand Co.",
      "url": "https://sister-brand.example",
      "founder": { "@id": "https://seoagencybangkok.com/about/#yunmin" },
      "memberOf": { "@id": "https://seoagencybangkok.com/#group" },
      "knowsAbout": ["Content marketing", "Editorial strategy", "AEO"]
    },
    {
      "@type": "Person",
      "@id": "https://seoagencybangkok.com/about/#yunmin",
      "name": "Yunmin Shin"
    }
  ]
}
</script>

สังเกตว่า @id ของ Person ยังคงชี้กลับไปที่ seoagencybangkok.com/about/#yunmin — แม้แต่บนเว็บไซต์ของแบรนด์พี่น้องเอง นี่คือสิ่งที่ถูกต้อง canonical URI ของบุคคล ควรอยู่บนเว็บไซต์ที่มีหน้าประวัติ (bio page) น่าเชื่อถือที่สุด แล้วอ้างอิงมันจากเว็บไซต์อื่น ๆ

การตรวจสอบความถูกต้องของ graph

เครื่องมือ 3 ตัวที่เรารันทุกครั้งที่ deploy ตามลำดับ:

1. Schema Markup Validator ที่ validator.schema.org — จับ typo ในชื่อ property และ type ที่ผิดพลาดพื้นฐาน นี่คือมาตรฐานขั้นต่ำสุด
2. Google Rich Results Test — ยืนยันว่า entity ไหนที่ parser ของ Google รับจริง บางครั้ง schema ที่ valid ก็ถูกมองข้ามเพราะไม่ได้อยู่ใน feature set ที่ Google รองรับ ซึ่งก็ไม่เป็นไร คุณยังคงเผยแพร่มันไว้สำหรับ AI assistant และ Bing
3. Custom jq diff — เราใช้ script Python ขนาดเล็ก (ส่วนหนึ่งของ scraper ที่ scrape 10,000 คำค้นหาทุกคืน จากลิงก์10K-query scraper) ที่ดึง JSON-LD ที่ใช้งานจริงจากแต่ละโดเมนใน cluster และตรวจสอบว่าทุก @id ที่ถูกอ้างอิงใน cross-domain relationship มีอยู่จริงที่ปลายทาง จับความคลาดเคลื่อนหลังการ redesign ได้

คำสั่ง jq ที่เราใช้

# Extract all @id values from a domain's JSON-LD
curl -s https://seoagencybangkok.com | \
  pup 'script[type="application/ld+json"] text{}' | \
  jq -r '.. | objects | ."@id" // empty' | sort -u

รันมันบนทุกเว็บไซต์ใน cluster, diff ผลลัพธ์ที่ได้ และตรวจสอบว่า cross-reference ทำงานถูกต้อง ใช้เวลาแค่ 30 วินาที แต่ป้องกันความเสียหายเงียบ ๆ ที่อาจสะสมนาน 3 เดือน

สิ่งที่เราวัดได้: อัตราการอ้างอิงจาก AEO เพิ่มขึ้น 3.4 เท่าใน 7 สัปดาห์

ก่อนการ deploy graph (มีนาคม 2026) cluster ของเราได้รับการอ้างอิงจาก AI ที่แตกต่างกัน 11 ครั้งต่อสัปดาห์ ข้ามทั้ง 4 engine ที่เราติดตาม เจ็ดสัปดาห์หลังการ deploy ตัวเลขนั้นเพิ่มเป็น 37 การเพิ่มขึ้นไม่ได้เท่ากันทุก engine — Perplexity และ Claude ตอบสนองเร็วที่สุด (ภายใน 2 สัปดาห์), Gemini ใช้เวลาประมาณ 5 สัปดาห์ และ ChatGPT ช้าที่สุดที่ประมาณ 7 สัปดาห์ ซึ่งสอดคล้องกับรอบการ training/grounding ของแต่ละตัว

ข้อควรระวังสำคัญ: เราทำการปรับปรุงอื่น ๆ ในช่วงเวลาเดียวกันด้วย (รีเฟรชบทความหลัก 11 ชิ้น, แก้ redirect chain 3 จุด, เขียนหน้าภาษาไทย 4 หน้าใหม่จากการแปลให้เป็น native authoring) graph น่าจะรับผิดชอบราว 60-70% ของการเพิ่มขึ้นนี้ ส่วนที่เหลือมาจากการปรับปรุงอื่น ๆ เราจงใจประเมินแบบระมัดระวังเมื่อจะระบุว่า signal ของ cluster มาจาก schema โดยเฉพาะ

"Schema ไม่ใช่โครงสร้างพื้นฐานที่เลือกทำหรือไม่ก็ได้สำหรับ AEO มันคือวิธีเดียวที่จะบอก AI engine ว่า 'โดเมนเหล่านี้รวมกันเป็น authority cluster เดียว' โดยไม่โกหกเรื่องความเป็นเจ้าของ"

ข้อผิดพลาดที่พบบ่อยจากการตรวจสอบ

• ใช้ @id ของ Organization ซ้ำกับ WebSite — ควรใช้ fragment ที่แตกต่างกันสำหรับแต่ละประเภท entity เสมอ
• ใช้ sameAs กับแบรนด์พี่น้อง — อธิบายไปแล้วข้างต้น จะกระตุ้นการลดอันดับจากเนื้อหาซ้ำ
• ใส่ Person ของผู้ก่อตั้งไว้แค่หน้า About — ควรปรากฏใน @graph ของหน้าแรกด้วย เพราะเป็นจุดที่ Organization ประกาศ founder
• ลืมใส่ inLanguage บนเว็บไซต์สองภาษา — ถ้าไม่มี AI engine จะบอกไม่ได้ว่าหน้านั้นเป็นภาษาไหน สำคัญมากสำหรับ cluster ที่มีทั้งภาษาไทยและอังกฤษ
• Hardcode URL ของ logo ไปที่ path ที่ไม่ใช่ canonical — ควร pin ไว้ที่ /seo-agency-bangkok-technical-seo-agency-thailand.jpg หรือ path ที่คงที่ทำนองนี้ ไม่ใช่ URL asset ที่มี version

วิธี deploy ระบบนี้บน cluster ของคุณเอง

คุณไม่จำเป็นต้องมีหลายโดเมนเพื่อให้ระบบนี้ใช้งานได้ แม้แต่ 2 เว็บไซต์ก็ได้ประโยชน์ การ deploy ขั้นต่ำที่ใช้งานได้จริงมีดังนี้:

1. ตัดสินใจว่าโดเมนไหนจะถือ entity Person แบบ canonical สำหรับผู้ก่อตั้ง/ทีมที่ใช้ร่วมกัน — โดยปกติคือโดเมนที่มีหน้าประวัติละเอียดที่สุด
2. สร้าง Organization สังเคราะห์สำหรับ cluster พร้อม @id ที่คงที่บนโดเมนใดโดเมนหนึ่ง (เราใช้ #group บนโดเมนแม่)
3. บนทุกเว็บไซต์ เผยแพร่ @graph บนหน้าแรกที่ประกอบด้วย: Organization ของเว็บไซต์นั้นเอง, การอ้างอิง memberOf ไปยัง Organization ของ cluster และ entity Person ที่อ้างอิง URI ของผู้ก่อตั้งแบบ canonical
4. รัน jq validator ทุกสัปดาห์ ถ้าเป็นไปได้ให้เพิ่มเข้าไปใน CI

ถ้าคุณต้องการให้เราเขียน graph ให้และตรวจสอบความถูกต้องทั่วทั้งเครือข่ายของคุณ บริการtechnical SEO ของเรารวม schema engineering ไว้เป็นหนึ่งใน core deliverable เราเคยทำแบบโปรเจกต์ครั้งเดียวให้ลูกค้าที่มีทีมในบริษัทอยู่แล้วด้วย — ดูตัวอย่างที่เผยแพร่ได้บางส่วนในcase studies

อ่านเพิ่มเติม

schema graph เป็นเพียงชิ้นส่วนหนึ่งของปริศนา AEO ชิ้นส่วนอื่น ๆ ได้แก่ การวิศวกรรมความเร็วหน้าเว็บ (เพราะหน้าที่โหลดช้าจะไม่ถูกอ้างอิงแม้ schema จะสมบูรณ์แบบ), การสืบสวน log file (เพราะ crawler จะ index สิ่งที่มันเข้าไม่ถึงไม่ได้), การวิเคราะห์ pattern การอ้างอิง (เพราะ schema ทำให้คุณถูก parse แต่ความเฉพาะเจาะจงต่างหากที่ทำให้คุณถูกอ้างอิง) และquality gate สำหรับ programmatic (เพราะคุณสามารถขยาย entity coverage ได้อย่างมีวินัย) รวมกันแล้วนี่คือ technical SEO stack ที่เราส่งมอบให้ลูกค้าทุกราย