สร้างเว็บธุรกิจ 5 หน้าด้วย AI agent: เทียบ MCP ของ WordPress.com, Storyblok, Sanity และ Webflow

โดย Nokka (นก-กา) | 19 กันยายน 2026

บทความนี้เขียนโดย AI (โมเดล glm-5.3 ของผู้ให้บริการ ollama-cloud) ผ่าน Hermes Agent จาก Nous Research ตรวจสอบและเรียบเรียงโดย Nokka (นก-กา)

ตอนที่ 2 ของชุด MCP · ตอนก่อนหน้า: "MCP ในเว็บไซต์ 13 ระบบ: ตัวไหนออกแบบ tool ดี ตัวไหนยังหลงทาง"

ในตอนก่อนหน้าเราให้คะแนนการออกแบบ tool ของ MCP server จาก 13 ระบบ โดยมี 4 ตัวที่คะแนนนำคือ WordPress.com, Storyblok, Sanity และ Webflow [1] คราวนี้เราจะเอา 4 ตัวนั้นมาลงสนามจริงด้วยโจทย์เดียวกัน: สร้างเว็บไซต์หนึ่งเว็บสำหรับธุรกิจหนึ่งธุรกิจ แล้วดูว่า AI agent ต้องเรียก tool อะไร ตามลำดับไหน กี่ครั้ง และเจอจุดที่ต้องระวังตรงไหน

ธุรกิจตัวอย่างคือสตูดิโอเซรามิกชื่อ "ดินดี" มีงานหลักคือสอนทำเซรามิกและขายงานฝีมือ เว็บที่ต้องการมี 5 หน้า:

• Home หน้าแรกเล่าว่าสตูดิโอทำอะไร มีภาพบรรยากาศชั้นเรียน
• Product & Service รายการคอร์สเรียนและชิ้นงานขาย พร้อมราคา
• About Us เรื่องของผู้ก่อตั้งและปรัชญางาน
• Contact Us ที่อยู่ แผนที่ เบอร์โทร และฟอร์มฝากข้อความ
• Blog บันทึกจากชั้นเรียน อัปเดตเป็นระยะ

ทั้ง 4 ระบบเชื่อมด้วยมาตรฐาน MCP เหมือนกัน คือเปิดให้ AI agent เรียกใช้ tool ผ่านโปรโตคอลเดียวกัน แต่พอลงมือทำงานจริง เส้นทางของแต่ละบ้านต่างกันอย่างมีนัยสำคัญ เพราะแต่ละเจ้าออกแบบ "คำต้อนรับ" ที่ agent เห็นตอนเชื่อมต่อไม่เหมือนกัน

วิธีอ่านบทความนี้

แต่ละระบบจะเล่าเป็นลำดับการทำงานจริง ตั้งแต่เชื่อมต่อครั้งแรกจนทั้ง 5 หน้าพร้อมเผยแพร่ โดยยกชื่อ tool และ operation ตามเอกสารทางการของแต่ละเจ้า ท้ายแต่ละตอนจะสรุปจำนวนการเรียกโดยประมาณกับข้อควรระวังเฉพาะตัว

ตัวเลขจำนวนครั้งเป็นการประเมินจากขั้นตอนในเอกสาร ไม่ใช่ผลวัดจากการรันจริง หากระบบมี action รวมหลายขั้นในการเรียกครั้งเดียว ผมนับเป็นหนึ่งครั้ง

WordPress.com: ประตูเดียว ย่อยเป็นสามจังหวะ

WordPress.com ใช้ tool ชื่อ wpcom-mcp-content-authoring เป็นศูนย์กลาง ทุก operation เข้าถึงผ่าน action สามแบบคือ list เพื่อดูว่ามีอะไรให้ใช้, describe เพื่อดูรูปแบบข้อมูล, และ execute เพื่อทำงานจริง [3]

ขั้นที่ 1: อ่านบริบทเว็บก่อนแตะเนื้อหา

การเริ่มงานที่ดีของ WordPress.com คือเรียก tool คู่หูชื่อ wpcom-mcp-site-editor-context ก่อนเลย เพราะ operation อย่าง theme.presets จะบอกว่าธีมปัจจุบันใช้สีและฟอนต์อะไร ส่วน blocks.allowed จะบอกว่าบล็อกชนิดไหนใช้ได้บนเว็บนี้ [3] คู่มือของทางการเขียนไว้ตรง ๆ ว่าควรใช้ข้อมูลนี้ก่อนสร้างหรือแก้เนื้อหา เพื่อให้สิ่งที่เขียนเข้าไปเข้ากับดีไซน์ที่ตั้งไว้

ขั้นที่ 2: หน้าทั้ง 4 ที่เป็นหน้าเดี่ยว

สี่หน้าแรกคือ Home, Product & Service, About Us และ Contact Us สร้างด้วย operation เดียวกันคือ pages.create ซึ่งโดยค่าเริ่มต้นจะสร้างเป็น draft ก่อน ไม่เผยแพร่ทันที และรองรับการซ้อนหน้าลูกด้วย [3]

ทริกจากคู่มือที่ช่วยให้หน้าสวยเร็วคือใช้ patterns.list กับ patterns.get ดึงบล็อกพาเทิร์นสำเร็จรูปมาประกอบเป็นหน้าเต็ม ๆ แทนการเขียนบล็อกทีละชิ้น เช่น หน้า Product & Service อาจประกอบจากพาเทิร์นแกลเลอรีราคาบวกพาเทิร์นเรียงคอร์ส แล้วค่อยเติมข้อความจริงของดินดีลงไป [3]

ขั้นที่ 3: Blog และระบบหมวด

Blog เป็นหน้าจดบันทึกที่โครงมาจากโพสต์ งานเริ่มจากสร้างหมวดเรื่องด้วย categories.create และแท็กด้วย tags.create แล้วจึงสร้างหน้าประตูบล็อกด้วย pages.create และโพสต์ชุดแรกด้วย posts.create ซึ่งได้สถานะ draft เช่นกัน [3]

ขั้นที่ 4: รูปภาพและสื่อ

ภาพบรรยากาศชั้นเรียนอัปโหลดผ่าน media.create และหากต้องแก้ข้อมูลไฟล์ทีหลังใช้ media.update [3] ที่น่าสนใจคือเอกสารระบุว่า tool นี้มีการสร้างภาพด้วย AI ในตัวเพื่อยัดลงคลังสื่อ ซึ่งเป็นทางลัดสำหรับภาพประกอบที่ไม่ต้องใช้ภาพจริง

ขั้นที่ 5: เผยแพร่เมื่อพร้อม

ทุกอย่างยังเป็น draft จนกว่าเจ้าของเว็บจะอนุมัติ การเผยแพร่ใช้การอัปเดตสถานะของแต่ละชิ้น และหากต้องเผยแพร่หน้าเดียวทับงานเก่าทั้งหน้าให้ทำผ่าน pages.update ส่วนการแก้เฉพาะส่วนใดส่วนหนึ่งของหน้าที่มีอยู่แล้ว คู่มือแนะให้ใช้ชุด page-sections.list เพื่อหาบล็อกเป้าหมายตามลำดับ แล้วเลือก page-sections.replace หรือ page-sections.insert หรือ page-sections.remove เท่านั้น แทนการเขียนทับทั้งหน้า [3]

จุดที่ต้องระวังของ WordPress.com

• ทุก operation ที่เขียนหรือลบต้องส่งพารามิเตอร์ user_confirmed เสมอ หากลืมระบบจะไม่ลงมือ และการลบถาวรของหมวดและแท็กต้องยืนยันอีกชั้น [3]
• หลังทุกการสร้างหรือแก้ไข ให้อ่านฟิลด์ _content_warnings ที่ติดมากับผลลัพธ์ เพราะ WordPress อาจตัดบล็อกหรือ HTML ที่ไม่รองรับออกโดยไม่ถาม [3]
• การลบข้อมูลทั้งหกแบบ ได้แก่ posts, pages, comments, media, categories และ tags จะบังคับให้ agent ดึงข้อมูลชิ้นที่จะลบมาแสดงก่อนเสมอ ทั้งชื่อ ผู้เขียน และจำนวนเรื่องที่กระทบ [3]

ประมาณการเรียกทั้งเว็บ: ประมาณ 15-20 ครั้ง โดยหน้าเดี่ยวหนึ่งหน้าใช้ราว 2-3 ครั้งรวมการเรียกดูพาเทิร์น

Storyblok: ค้นก่อนเรียก และประตูสามบานตามความอันตราย

Storyblok ตั้งใจไม่ห่อ endpoint ทั้ง 160 กว่าตัวของ Management API เป็น tool ทีละอัน แต่เปิด tool 7 ตัวที่ทำงานเป็นวงจรสามขั้น: search ค้นว่ามี operation ตรงกับความต้องการไหม, describe ดูพารามิเตอร์ทั้งหมดของ operation นั้นพร้อมรูปแบบข้อมูล แล้วจึงเลือกประตูเรียกใช้จริง [4]

ประตูสามบานของ Storyblok แยกตามความเสี่ยง ซึ่งสอดคล้องกับแนวปฏิบัติความปลอดภัยของ MCP ที่แนะให้แยกระดับการเขียนและการลบออกจากกัน [2] ได้แก่ execute_readonly สำหรับอ่าน, execute_mutating สำหรับสร้างและแก้ไข และ execute_destructive สำหรับลบซึ่งต้องได้รับการยืนยันจากผู้ใช้ทุกครั้ง [4]

ขั้นที่ 1: เชื่อมพื้นที่ทำงาน

การเชื่อมต่อผูกกับ space ID เดียว และบทบาทผู้ใช้ถูกฝังใน URL ของการเชื่อมต่อ ทำให้ agent ทำงานได้เท่าที่สิทธิ์ของบัญชีนั้นมีเท่านั้น ขยับขยายเองไม่ได้ [4]

ขั้นที่ 2: ออกแบบโครงเนื้อหาก่อนสร้างหน้า

Storyblok เป็น CMS แบบบล็อกประกอบ หน้าหนึ่งหน้าคือ story หนึ่งเรื่องที่ประกอบจาก component หลายชิ้น ก่อนสร้างหน้าไหน agent จึงต้องไล่ search หา operation เกี่ยวกับ component และ story ก่อนว่ามีอะไรให้ใช้ เช่น หา operation สร้าง component ประเภท hero, แกลเลอรี และฟอร์มติดต่อ แล้วจึง describe ตัวที่จะใช้จริงเพื่อดูโครงข้อมูลของแต่ละ component [4]

ขั้นที่ 3: สร้างหน้าทั้ง 5

Home, About Us และ Contact Us เป็น story หนึ่งเรื่องต่อหน้า สร้างด้วย execute_mutating ที่เรียก operation สร้าง story พร้อม component ที่ออกแบบไว้ ส่วน Blog สร้างเป็น story หน้าประตูบวกโพสต์แรก และ Product & Service อาจใช้ story ร่วมกับ content type ที่เก็บรายการสินค้าแบบมีโครงชัดเจน [4]

ขั้นที่ 4: อัปโหลดภาพสองเฟส

ภาพของดินดีอัปโหลดผ่านคู่ upload_asset กับ upload_asset_finish ขั้นแรกสร้างระเบียน asset และรับ URL ที่เซ็นไว้พร้อมคำสั่ง cURL สำเร็จรูป ขั้นที่สองยืนยันเมื่อไฟล์ขึ้นที่เก็บแล้ว เอกสารระบุตรง ๆ ว่าขั้นส่งไฟล์ต้องใช้ shell จริง จะเรียกผ่าน tool เพียงอย่างเดียวไม่พอ [4]

จุดที่ต้องระวังของ Storyblok

• ทำงานช้ากว่าเพื่อนเล็กน้อยเพราะ operation หนึ่งอย่างใช้ 2-3 การเรียก (search แล้ว describe แล้วจึง execute) แลกกับความแม่นที่ตรวจสอบได้ทุกขั้น [4]
• MCP ของ Storyblok เปิดแต่ Management API คือทำงานกับฝั่งจัดการเท่านั้น ไม่อ่านเนื้อหาที่เผยแพร่แล้วผ่าน Content Delivery API [4]
• คู่มือแนะนำสามข้อที่คนมองข้าม: จำกัดสิทธิ์ให้แคบที่สุด, ให้ agent อ่านแผนกลับมาก่อนเรียกทุกครั้งที่จะแก้ไข และตรวจ identifier ทุกครั้งก่อนอนุมัติการลบ [4]
• การอัปโหลดไฟล์ใหญ่ติดขั้น shell อาจต้องมีมนุษย์หรือสคริปต์ช่วยระยะสั้น

ประมาณการเรียกทั้งเว็บ: ประมาณ 25-35 ครั้งเพราะทุก operation มีขั้นค้นหาและดูรายละเอียดนำหน้า

Sanity: ชุดเครื่องมือครบที่สุดแต่ต้องเขียน query เป็น

Sanity เปิด tool มากที่สุดในสี่ตัวนี้ กว่า 40 ตัว แบ่งเป็นงานเนื้อหา โครงข้อมูล โครงการ และเอกสารของ Sanity เอง [7] การทำเว็บดินดีใน Sanity คือการทำงานกับ Content Lake ที่เก็บ document เป็นหน่วยหลัก

ขั้นที่ 1: โครงข้อมูลก่อนเนื้อหา

หัวใจของ Sanity คือ schema ที่ต้องมาก่อนเนื้อหา ลำดับคือ list_workspace_schemas ดูว่ามีโครงอะไรอยู่แล้ว, get_schema อ่านโครงละเอียด และถ้าต้องสร้างใหม่ใช้ deploy_schema ลงคลาวด์โดยตรง [7] สำหรับดินดีต้องมี type อย่างน้อย 4 แบบ: หน้าเว็บ, คอร์สหรือสินค้า, โพสต์บล็อก และข้อมูลติดต่อ

ขั้นที่ 2: สร้างเนื้อหาเป็น draft

เนื้อหาทุกชิ้นเริ่มจาก create_documents ซึ่งสร้างเป็น draft โดยอัตโนมัติ ยกเว้นกรณีที่ระบุ release เพื่อทำเวอร์ชัน [7] ที่แปลกและต้องจำคือกติกาเรื่อง release: ถ้าจะแก้เอกสารที่อยู่ใน release ต้องเรียก create_version ก่อนเสมอ แล้วค่อย patch_documents ที่เวอร์ชันนั้น ห้ามแก้ที่ draft ID หรือ published ID ตรง ๆ เพราะจะกลายเป็น draft ที่ไม่เกี่ยวกับ release กลาย ๆ [7]

ขั้นที่ 3: เชื่อมหน้าเว็บกับเนื้อหา

Sanity เป็น headless CMS ไม่ได้เก็บหน้าเว็บเป็นหน้าสมบูรณ์ แต่เก็บเป็นข้อมูลที่ frontend ดึงไปแสดง ดินดีจึงต้องมี type หน้าเว็บที่เก็บชื่อหน้ากับเนื้อหาอ้างอิง แล้ว frontend จะใช้ query_documents ด้วยภาษา GROQ ดึงข้อมูลแต่ละหน้าไปเรนเดอร์ [7] หน้า Home คือ query ดึง hero กับคอร์สแนะนำ หน้า Blog คือ query โพสต์ล่าสุด เป็นต้น

รายละเอียดที่บอกว่าทำไม Sanity ได้คะแนน description สูงสุดอยู่ตรงนี้: tool query_documents เขียนไว้ว่าถ้าไม่คุ้น GROQ ให้ไปดึงกฎจาก get_sanity_rules มาอ่านก่อนเสมอ และผลลัพธ์ไม่ถูกตัด จึงควรใช้การเลือกฟิลด์และ slice ใน query คุมปริมาณเอง [7]

ขั้นที่ 4: ภาพและการเผยแพร่

ภาพอัปโหลดผ่าน dataset_assets_upload_from_url ถ้าไฟล์อยู่บนอินเทอร์เน็ตแล้ว หรือใช้ media_assets_upload_from_url สำหรับคลังสื่อ ทั้งคู่คืน operationId ที่ต้องเช็คสถานะด้วย assets_upload_status ก่อน [7] การเผยแพร่ใช้ publish_documents ซึ่งทำให้ draft กลายเป็นเนื้อหาสด และถ้าต้องการจัดกลุ่มการเปลี่ยนแปลงหลายชิ้นให้พร้อมกันใช้ create_release กับ list_releases [7]

จุดที่ต้องระวังของ Sanity

• ห้ามแก้ published document โดยตรง ทุกแก้ไขต้องผ่าน draft หรือเวอร์ชันของ release เท่านั้น [7]
• คำสั่ง query_documents คืนผลลัพธ์แบบไม่ตัด หน้าที่โพสต์เยอะจะกิน context ของ agent รัว ๆ ต้องคุ้นเรื่อง projection และ slice ของ GROQ [7]
• อัปโหลดเป็นงานแบบไม่รอผลตอบ (async) ต้องเช็คสถานะเป็นระยะ และถ้าเรียกซ้ำโดยไม่เช็คก่อนอาจได้ไฟล์ซ้อนกัน [7]
• เครื่องมือสร้างภาพ AI อย่าง generate_image กับ transform_image ใช้ AI credit แยกจากการใช้ tool ปกติ [7]

ประมาณการเรียกทั้งเว็บ: ประมาณ 20-28 ครั้ง เพราะ tool จับคู่งานไว้ชัด แต่บวกเพิ่มจากการเช็คสถานะอัปโหลด

Webflow: ชัดเจนที่สุดในบรรดาทั้งสี่ แต่แยกเป็น tool ละเอียด

Webflow ออกแบบเป็นกลุ่ม tool ตามหน้าที่ อ่านแล้วเข้าใจงานที่สุด: data_sites_tool จัดการเว็บ, data_pages_tool จัดการหน้า, data_cms_tool จัดการคอลเลกชัน, data_assets_tool จัดการไฟล์แนบ [5] ทุก action ของแต่ละ tool ระบุพารามิเตอร์ที่ต้องส่งไว้ในตารางชัดเจน

ขั้นที่ 1: หา site ID

เริ่มจาก list_sites ใน data_sites_tool เพื่อหาเว็บดินดีและเก็บ site ID ที่จะใช้กับงานทั้งหมดต่อไป [5]

ขั้นที่ 2: สร้างหน้าเว็บทั้ง 5

หน้าเดี่ยวทั้งสี่หน้าสร้างด้วย create_page ใน data_pages_tool ที่ต้องส่ง site ID พร้อมชื่อและ slug เป็นขั้นต่ำ มีตัวเลือกเพิ่มเช่นสถานะ draft โฟลเดอร์ และการทำสำเนาจากหน้าที่มีอยู่ [5] ทริกสำหรับงานจำนวนมากคือ bulk_update_pages ที่อัปเดตการตั้งค่าได้ถึง 100 หน้าต่อครั้ง รวมถึงข้อมูล SEO และ Open Graph [5]

ขั้นที่ 3: คอลเลกชันสำหรับสินค้าและบล็อก

งานขายของดินดีใช้ data_cms_tool เริ่มจาก create_collection สร้างคอลเลกชันสินค้า แล้วเติมโครงด้วย create_collection_static_field สำหรับฟิลด์ราคาและรายละเอียด และ create_collection_reference_field ถ้าต้องเชื่อมสินค้ากับคอลเลกชันคอร์ส [5] รายการสินค้าแต่ละชิ้นเข้าผ่าน create_collection_items ซึ่งสร้างเป็น draft ก่อนเช่นกัน และการเผยแพร่แยกเป็นอีก action คือ publish_collection_items [5]

สำหรับ Blog ใช้คอลเลกชันบทความ โดย action ชุดเดียวกัน ต่างกันแค่โครงฟิลด์

ขั้นที่ 4: เติมเนื้อหาหน้าด้วยชุดสร้าง element

หน้าที่สร้างไว้ยังเปล่า การเติมเนื้อหาใช้ชุด tool สร้าง element อย่าง data_element_tool สำหรับจัดการส่วนประกอบในหน้า, data_style_tool สำหรับสร้างสไตล์ และ data_variable_tool สำหรับตัวแปรสีกับขนาด [5] เอกสารระบุตรง ๆ ว่าชุด tool สร้างหน้าทั้งเก้าตัวทำงานกับหน้าเว็บเฉพาะหน้า ต้องระบุหน้าที่ทำงานด้วยเสมอ [5]

ข้อจำกัดที่ต้องรู้ก่อนใช้: MCP ของ Webflow ยังทำ Interactions ซึ่งเป็นเอฟเฟกต์เคลื่อนไหวไม่ได้ ต้องทำใน Designer ด้วยมือ และการสร้าง item ที่มี locale ใหม่ไม่รองรับ อ่านกับแก้ item ที่มี locale ได้เท่านั้น [5][6]

ขั้นที่ 5: ภาพและการเผยแพร่ทั้งเว็บ

ภาพเข้าผ่าน data_assets_tool ที่มีทั้งจัดระเบียนโฟลเดอร์และสั่งบีบอัดไฟล์ [5] ปลายทางคือ publish_site ใน data_sites_tool ที่เผยแพร่การเปลี่ยนแปลงล่าสุดทั้งเว็บขึ้นโดเมนในคำสั่งเดียว [5] และถ้าต้องการเผยแพร่เฉพาะกลุ่ม item ก็ใช้ publish_collection_items ได้โดยไม่ต้องแตะทั้งเว็บ

จุดที่ต้องระวังของ Webflow

• สิทธิ์ผูกกับ workspace หนึ่งต่อการอนุญาตหนึ่งครั้ง ถ้าจะทำงานกับ workspace อื่นต้องอนุญาตใหม่ [5]
• บางงานต้องเปิดหน้าจอ Designer พร้อม Bridge App เช่น อ่านสิ่งที่กำลังเลือกอยู่หรือเปลี่ยนหน้าบน canvas ส่วนอื่นทำงานหัวหลังได้เลย [5]
• การทำงานเกิดขึ้นบน branch ของหน้าก็ได้ผ่าน create_branch กับ list_branches เหมาะกับงานทดลองที่ไม่อยากกระทบหน้าจริง [5]

ประมาณการเรียกทั้งเว็บ: ประมาณ 25-40 ครั้ง เพราะ tool แยกละเอียดแต่ละ action ชัด งานเล็ก ๆ ก็ยังเรียกแยก

ตารางเทียบสี่ระบบจบในหน้าเดียว

มิติ	WordPress.com	Storyblok	Sanity	Webflow
จำนวน tool หลักที่ใช้	1 รวมทุก operation	7 ครอบคลุมทั้ง API	40+ แยกงาน	4-5 กลุ่มหลัก
รูปแบบการเรียก	3 จังหวะ: list, describe, execute	3 ขั้น: search, describe, execute	เรียกตรงแต่ต้องคุ้น GROQ	เรียกตรงตาม action
สถานะเริ่มของเนื้อหาใหม่	draft อัตโนมัติ	draft อัตโนมัติ	draft อัตโนมัติ	draft อัตโนมัติ
ด่านกันการลบ	ต้องแสดงข้อมูลก่อน + user_confirmed	ประตูลบแยก ยืนยันทุกครั้ง	แก้ draft เท่านั้น published ห้ามแตะ	สิทธิ์ตาม role ของผู้ใช้
จุดแข็งเฉพาะตัว	อ่านธีมก่อนเขียน + patterns ประกอบหน้า	ค้น operation ก่อนเสมอ ไม่หลง	schema และ release สำหรับงานเป็นทีม	action ชัดที่สุด ตารางพารามิเตอร์ครบ
ข้อแลกที่ต้องยอม	ต้องเรียนรู้ action 3 จังหวะ	ช้ากว่าเพราะค้นหาก่อน	ต้องเขียน query เป็น	แยก tool เยอะ เรียกบ่อยกว่า
เหมาะกับใคร	ร้านที่อยากเว็บเดียวจบ ไม่แตะโค้ด	ทีมที่ต้องการความปลอดภัยสูงและโครงยืด	ทีมที่มี frontend ของตัวเอง	ทีมที่ใช้ Webflow อยู่แล้ว

สรุปว่าควรเลือกตามสถานการณ์ไหน

สี่ระบบนี้ล้วนผ่านเกณฑ์การออกแบบ tool ในระดับดีจนถึงดีมากตามที่เราเทียบไปตอนก่อน แต่เส้นทางการทำงานจริงเหมาะกับคนละแบบ

• ถ้าธุรกิจอยากได้เว็บเดียวจบในตัวและไม่มีทีมเทคนิค WordPress.com น่าจะสั้นที่สุด เพราะ tool เดียวครอบคลุมตั้งแต่หน้าไปโพสต์ไปสื่อ แถมมีพาเทิร์นสำเร็จรูปช่วยประกอบหน้า
• ถ้าทีมให้ความสำคัญกับความปลอดภัยของข้อมูลและความยืดหยุ่นของโครงเนื้อหา Storyblok เป็นทางที่ด่านกันชัดที่สุด ทุกการลบผ่านประตูเฉพาะที่ต้องยืนยัน
• ถ้าเว็บมี frontend เฉพาะและเนื้อหาซับซ้อนมีหลายภาษาหรือหลายเวอร์ชัน Sanity ให้อิสระเชิงโครงข้อมูลมากที่สุด แลกกับความต้องเรียนรู้ GROQ
• ถ้าทีมใช้ Webflow อยู่แล้ว MCP ของเขาทำให้ agent ทำงานต่อได้ทันทีโดยไม่ต้องเปลี่ยนระบบ และ action ที่เขียนไว้ละเอียดที่สุดในสี่ตัว

สำหรับดินดีที่เป็นธุรกิจเล็กหนึ่งร้าน ในมุมมองของผมแล้วเลือก WordPress.com สำหรับงานสร้างเว็บจริง แล้วใช้ Webflow เป็นตัวเทียบเวลาอยากคุมดีไซน์เองละเอียด ส่วน Storyblok กับ Sanity คือทางที่เหมาะเมื่อธุรกิจโตจนต้องแยกทีมดูแลเนื้อหากับทีมดูแลหน้าตาเว็บออกจากกัน

ปัญหาที่สี่ระบบยังไม่ตอบเหมือนกันคือการวัดผลหลังเปิดเว็บ WordPress.com มีสถิติในตัวผ่าน operation สถิติของเว็บ ส่วน Webflow มีข้อมูลวิเคราะห์ผ่าน tool แยกที่ต้องมีแพ็กเกจเสริม ดังนั้นก่อนตัดสินใจเลือก ควรถามต่อว่าแพ็กเกจที่เราจะจ่ายรวมส่วนนี้มาด้วยหรือเปล่า

ข้อจำกัดของการเปรียบเทียบนี้

ข้อมูลทั้งหมดมาจากเอกสารทางการของแต่ละระบบ ณ กันยายน 2026 ตัวเลขจำนวนการเรียกเป็นการประเมินจากขั้นตอนในเอกสาร ผมไม่ได้รันงานจริงทั้งหมดทุกขั้น การใช้งานจริงอาจเร็วกว่าหรือช้ากว่าที่ประเมิน ขึ้นกับความซับซ้อนของหน้าและข้อมูล นอกจากนี้ Webflow ยังมีชุด tool งานดีไซน์ที่ต้องเปิด Designer ซึ่งผมไม่ได้นับในงานหน้าเดี่ยวทั้งหมด ส่วน Sanity ต้องมี frontend ของตัวเองจึงเห็นหน้าเว็บจริง ซึ่งการเทียบในหน้านี้จึงเทียบถึงชั้นข้อมูลพร้อมเผยแพร่เท่านั้น

สิ่งที่บทความนี้ตั้งใจทิ้งไว้ให้ผู้อ่านคือแผนที่คร่าว ๆ ว่าเมื่อบอกให้ AI สร้างเว็บให้ธุรกิจ เส้นทางที่มันเดินบนแต่ละระบบหน้าตาเป็นอย่างไร ถ้าทีมกำลังเลือกระบบ ลองเอาโจทย์ห้าหน้านี้ไปถามผู้ขายของแต่ละเจ้าดูว่า agent ของเขาจะเดินทางแบบไหน คำตอบที่ชัดเจนเป็นสัญญาณที่ดีว่าเอกสารของระบบนั้นเขียนดูแลจริง

แหล่งอ้างอิง

[1] การให้คะแนน 8 เกณฑ์ของทั้งสี่ระบบเป็นการประเมินของผมเอง แนวคิดเกณฑ์มาจาก Anthropic, Writing effective tools for agents: with agents, 11 กันยายน 2025. https://www.anthropic.com/engineering/writing-tools-for-agents

[2] MCP Security Best Practices, Model Context Protocol, 2026. https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices

[3] WordPress.com MCP Tools Reference, Automattic, 2026. https://developer.wordpress.com/docs/mcp/tools-reference/

[4] MCP Server, Storyblok Documentation, 2026. https://www.storyblok.com/docs/libraries/mcp-server

[5] Webflow MCP Reference: Data Tools, Webflow, 2026. https://developers.webflow.com/mcp/tools

[6] Webflow MCP Server Overview, Webflow, 2026. https://developers.webflow.com/mcp/reference/overview

[7] Sanity MCP Server Documentation, Sanity, 2026. https://www.sanity.io/docs/ai/mcp-server