Subdomain คืออะไร? เทียบ Subdomain vs Subdirectory แบบไหนดีต่อ SEO ปี 2026 | Southern Whale

มีลูกค้ารายหนึ่งเป็นรีสอร์ตแถบอันดามัน โทรมาหาเราด้วยน้ำเสียงงง ๆ ว่า “พี่ครับ บล็อกผมเขียนมาสองปี บทความเกือบร้อยชิ้น แต่ทำไมหน้าห้องพักหน้าบริการมันไม่ขึ้นสักที” พอเปิดดูก็เจอสิ่งที่เจอบ่อยมาก — บล็อกอยู่ที่ blog.resortname.com ส่วนเว็บหลักอยู่ที่ resortname.com และทั้งสองฝั่งแทบไม่ลิงก์หากันเลย

พูดง่าย ๆ คือเขาปั้นเว็บสองเว็บพร้อมกันโดยไม่รู้ตัว แรงที่ได้จากบทความร้อยชิ้นไปกองอยู่กับ blog. ส่วน resortname.com ที่เป็นตัวทำเงินจริงยังผอมเหมือนเดิม

จุดที่ทำให้เรื่องนี้น่าปวดหัวคือ ความต่างระหว่าง blog.example.com กับ example.com/blog มันดูเหมือนแค่ “จุด” กับ “สแลช” แต่ในสายตาระบบ DNS เซิร์ฟเวอร์ และ Google มันคือคนละเรื่องกันเลย บทความนี้จะพาไล่ตั้งแต่ subdomain คืออะไร ไปจนถึงเลือกยังไงให้ไม่ต้องมานั่งย้ายทีหลัง

Subdomain คืออะไร

Subdomain (ซับโดเมน) คือส่วนที่อยู่ “หน้าสุด” ของชื่อโดเมน ทำหน้าที่แตกโดเมนหลักออกเป็นพื้นที่ย่อยที่แยกจากกันได้ทางเทคนิค เช่น

• blog.example.com — subdomain ชื่อ blog
• shop.example.com — subdomain ชื่อ shop
• www.example.com — จริง ๆ แล้ว www ก็คือ subdomain ตัวหนึ่ง แค่เราคุ้นจนลืมไป

โครงสร้างชื่อโดเมนเต็ม ๆ อ่านจากขวาไปซ้ายแบบนี้

ส่วนประกอบ	ตัวอย่าง	อธิบาย
TLD	.com	โดเมนระดับบนสุด
Root / Second-level domain	example	ชื่อที่เราจดทะเบียน
Subdomain	blog	ส่วนย่อยที่เราสร้างเองได้ไม่จำกัด

ประเด็นสำคัญคือ subdomain สร้างได้ฟรีและไม่จำกัดจำนวน เพราะเราเป็นเจ้าของโดเมนหลักอยู่แล้ว ไม่ต้องจดโดเมนใหม่ ไม่ต้องจ่ายเพิ่ม แค่เพิ่มเรคคอร์ดใน DNS แล้วชี้ไปที่เซิร์ฟเวอร์ที่ต้องการ

แล้ว Subdirectory คืออะไร

Subdirectory (หรือ subfolder) คือโฟลเดอร์ย่อยที่อยู่ “หลัง” ชื่อโดเมน คั่นด้วยเครื่องหมายสแลช เช่น

• example.com/blog/
• example.com/services/seo/
• example.com/phuket/

ความต่างเชิงเทคนิคที่ต้องเข้าใจให้ชัดคือ

• Subdomain = แยกกันที่ระดับ DNS ชี้ไปคนละ IP คนละเซิร์ฟเวอร์ คนละแอปได้ ต่างคนต่างอยู่
• Subdirectory = อยู่บนโฮสต์เดียวกัน เซิร์ฟเวอร์เดียวกัน เป็นแค่ path ที่ต่างกัน

เปรียบเทียบให้เห็นภาพ: subdomain เหมือนการเปิด “สาขาใหม่คนละตึก” ใช้ชื่อแบรนด์เดียวกันแต่มีทีมงาน มีระบบไฟ มีคีย์การ์ดของตัวเอง ส่วน subdirectory เหมือนการ “เปิดแผนกใหม่ในตึกเดิม” ใช้ลิฟต์เดียวกัน ใช้ระบบเดียวกัน ลูกค้าเดินต่อกันได้เลย

และนี่คือเหตุผลที่มันไปเกี่ยวกับ SEO อย่างเลี่ยงไม่ได้ เพราะ Google ไม่ได้ให้คะแนนเว็บแบบมองเป็นก้อนเดียวเสมอไป

วิธีสร้าง Subdomain ทีละขั้น

สร้าง subdomain ไม่ยาก แต่คนมักพลาดเพราะไม่รู้ว่าจะเลือกเรคคอร์ดแบบไหน มาไล่กันทีละขั้น

1. เข้าไปที่ระบบจัดการ DNS

จะอยู่ที่ผู้ให้บริการที่จัดการ nameserver ของคุณ ซึ่งอาจเป็นผู้จดโดเมน โฮสติ้ง หรือ Cloudflare ถ้าคุณย้าย DNS ไปฝากไว้ที่นั่น (ถ้ายังไม่แน่ใจว่า DNS ทำงานยังไง อ่านคู่มือ DNS ฉบับเข้าใจง่าย ประกอบได้)

2. เพิ่มเรคคอร์ด A หรือ CNAME

แบบ A record — ใช้เมื่อคุณรู้ IP ของเซิร์ฟเวอร์ปลายทาง

Type: A
Name: blog
Value: 203.0.113.25
TTL: 3600

ผลลัพธ์: blog.example.com ชี้ตรงไปที่ IP นั้น

แบบ CNAME record — ใช้เมื่อปลายทางเป็นชื่อโฮสต์ ไม่ใช่ IP เช่นชี้ไป Vercel, Netlify, Shopify หรือ Cloudflare Pages

Type: CNAME
Name: shop
Value: shops.myshopify.com
TTL: 3600

ผลลัพธ์: shop.example.com ชี้ไปที่บริการภายนอกโดยที่ IP ปลายทางเปลี่ยนได้เองโดยเราไม่ต้องแก้อะไร ซึ่งเป็นข้อดีใหญ่ของ CNAME

หลักการเลือกสั้น ๆ: ถ้าปลายทางเป็น IP คงที่ที่คุณคุมเอง ใช้ A ถ้าปลายทางเป็นแพลตฟอร์มของคนอื่น ใช้ CNAME

3. ตั้งค่าฝั่งเซิร์ฟเวอร์ให้รู้จักโดเมนนี้

DNS ชี้ทางได้อย่างเดียว แต่เซิร์ฟเวอร์ปลายทางต้อง “ยอมรับ” ชื่อนี้ด้วย ใน cPanel/DirectAdmin คือการเพิ่ม subdomain ในเมนู Domains ส่วนบน VPS คือการเพิ่ม server_name ใน Nginx หรือ VirtualHost ใน Apache ถ้าข้ามขั้นนี้ คุณจะเจอหน้า default ของเซิร์ฟเวอร์แทนเว็บของคุณ

4. ออก SSL ให้ subdomain

ข้อผิดพลาดยอดฮิต — คนสร้าง subdomain เสร็จแล้วลืมว่า SSL ของ example.com ไม่ครอบคลุม blog.example.com โดยอัตโนมัติ ผลคือเบราว์เซอร์ขึ้นเตือน “ไม่ปลอดภัย” ทำ Conversion พังทันที ทางออกมีสองแบบ

• ออกใบรับรองแยกทีละ subdomain — Let’s Encrypt ทำได้ฟรีและออโต้ต่ออายุ เหมาะกับ subdomain ไม่กี่ตัว
• Wildcard SSL (*.example.com) — ใบเดียวครอบทุก subdomain ระดับแรก เหมาะกับกรณีมี subdomain เยอะหรือสร้างเพิ่มบ่อย เช่นระบบที่ให้ลูกค้าแต่ละรายมี ลูกค้า.example.com เป็นของตัวเอง ข้อควรรู้: wildcard ครอบแค่หนึ่งระดับ *.example.com จะไม่ครอบ a.b.example.com และการออก wildcard ผ่าน Let’s Encrypt ต้องยืนยันด้วยวิธี DNS-01 คือเพิ่มเรคคอร์ด TXT ไม่ใช่แค่วางไฟล์

5. รอ DNS propagate แล้วทดสอบ

ปกติไม่กี่นาทีถึงไม่กี่ชั่วโมง เช็กด้วยคำสั่ง dig blog.example.com หรือ nslookup แล้วเปิดดูจริงทั้งแบบมี https และไม่มี รวมถึงลองพิมพ์ทั้งมีและไม่มี www ดูว่า redirect ถูกทางไหม เรื่องการตั้งค่า HTTPS ให้ถูกต้องมีรายละเอียดที่ควรอ่านคู่กัน

Subdomain vs Subdirectory: Google มองยังไงกันแน่

จุดนี้คือหัวใจ และเป็นจุดที่ข้อมูลบนอินเทอร์เน็ตมักสับสน เพราะมีสองความจริงที่ดูขัดกันแต่จริงทั้งคู่

ความจริงข้อที่ 1 — ในเชิงนโยบาย Google บอกว่ารองรับทั้งคู่ ตัวแทนของ Google พูดซ้ำหลายครั้งตลอดหลายปีว่าใช้แบบไหนก็จัดอันดับได้ ไม่มีบทลงโทษกับ subdomain และให้เลือกตามที่บริหารจัดการได้สะดวก คำแนะนำนี้ยังคงเป็นจริงอยู่ในปี 2026

ความจริงข้อที่ 2 — ในทางปฏิบัติ subdirectory มักได้เปรียบ เหตุผลไม่ใช่เพราะ Google “ชอบ” มากกว่า แต่เป็นผลข้างเคียงเชิงโครงสร้าง

• Authority รวมอยู่ที่เดียว ทุกลิงก์ที่ชี้เข้าบทความในบล็อกส่งผลตรงถึงโดเมนหลัก หน้าบริการที่อยู่คนละโฟลเดอร์ก็ได้อานิสงส์ด้วย ถ้าแยกเป็น subdomain แรงส่วนหนึ่งจะกระจายไปที่โฮสต์นั้นแทน
• Internal link ไหลได้ธรรมชาติกว่า ลิงก์ข้ามโฟลเดอร์ในโดเมนเดียวคือ internal link เต็มรูปแบบ ส่วนลิงก์ข้าม subdomain ถูกประเมินกึ่ง ๆ external ซึ่งแม้จะยังส่งค่าได้ แต่บริบทเชิงหัวข้อ (topical relevance) เกาะกันไม่แน่นเท่า
• สร้าง Topic Cluster ได้สมบูรณ์กว่า โครงสร้างแบบ pillar และ topic cluster ทำงานได้ดีที่สุดเมื่อทุกหน้าอยู่บ้านเดียวกัน
• จัดการง่ายกว่ามาก property เดียวใน Search Console, sitemap เดียว, robots.txt เดียว, การวัดผลใน Analytics ไม่ต้องมาไล่ตั้ง cross-domain tracking

จากงานที่เราเจอกับลูกค้า SME ภาคใต้ เว็บที่ย้ายบล็อกจาก subdomain มารวมเป็น subdirectory มักเห็นทราฟฟิกรวมของโดเมนหลักขยับขึ้นในช่วงประมาณ 3-6 เดือน (ตัวเลขนี้เป็นค่าประมาณจากประสบการณ์ ไม่ใช่การรับประกัน และขึ้นกับคุณภาพเนื้อหาเดิมด้วย)

ตารางเทียบแบบตรงไปตรงมา

ประเด็น	Subdomain (blog.example.com)	Subdirectory (example.com/blog)
การสะสม Authority	กระจาย อาจถูกมองเป็นคนละไซต์	รวมที่โดเมนเดียว ได้เปรียบ
การส่งค่าลิงก์ภายใน	กึ่ง external บริบทเกาะกันไม่แน่น	internal เต็มรูปแบบ
Search Console	ต้องเพิ่ม property แยก	property เดียวจบ
Sitemap / robots.txt	ต้องมีของตัวเองแยกไฟล์	ใช้ร่วมกันได้
SSL	ต้องออกเพิ่มหรือใช้ wildcard	ครอบคลุมอยู่แล้ว
อิสระด้าน Tech Stack	สูงมาก คนละภาษา คนละเซิร์ฟเวอร์ได้	ต้องอยู่ในระบบเดียวกันหรือทำ reverse proxy
ความยืดหยุ่นด้าน Performance	แยกโหลด แยกสเกลได้	แชร์ทรัพยากรกับเว็บหลัก
ความซับซ้อนในการดูแล	สูง มีของต้องดูสองชุด	ต่ำ
เหมาะกับ	ระบบคนละ stack, staging, แยกประเทศ	บล็อก, หน้าบริการ, หน้าจังหวัด

เมื่อไหร่ที่ควรใช้ Subdomain จริง ๆ

ถ้าอ่านมาถึงตรงนี้แล้วรู้สึกว่า subdomain แย่ไปหมด — ไม่ใช่ครับ มันมีที่ทางของมัน และในบางกรณีคือคำตอบเดียวที่สมเหตุสมผล

1. ระบบคนละ Tech Stack กันจริง ๆ

เว็บหลักเป็น Astro หรือ WordPress แต่ระบบร้านค้าเป็น Shopify ระบบจองเป็น SaaS เจ้าอื่น หรือแอปเป็น React ที่รันบนเซิร์ฟเวอร์ Node แยก การยัดทุกอย่างให้อยู่ใต้โดเมนเดียวต้องทำ reverse proxy ซึ่งซับซ้อนและพังง่าย กรณีแบบนี้ shop.example.com, app.example.com, help.example.com คือทางที่สะอาดกว่า

2. ระบบที่ไม่ได้หวังอันดับ

app. สำหรับหน้า login, api. สำหรับ API, cdn. สำหรับไฟล์สแตติก พวกนี้ไม่ต้องการทราฟฟิกจาก Google อยู่แล้ว แยกออกไปเลยดีกว่า จะได้ไม่ไปกิน crawl budget ของหน้าที่ต้องการอันดับจริง ๆ

3. แยกเวอร์ชันตามประเทศแบบจริงจัง

ถ้าคุณทำตลาดหลายประเทศที่มีทีมงาน ราคา และสกุลเงินคนละชุด เช่น th.example.com, my.example.com วิธีนี้ยอมรับได้ แต่ต้องตั้ง hreflang ให้ครบทุกคู่ อ่านรายละเอียดในคู่มือ International SEO และ hreflang ก่อนตัดสินใจ เพราะถ้าเป็นแค่เว็บสองภาษาไทย-อังกฤษของธุรกิจเดียว example.com/en/ ง่ายกว่าและได้ผลดีกว่ามาก

4. สภาพแวดล้อมทดสอบ

staging.example.com, dev.example.com, uat.example.com — เป็นเรื่องปกติและควรทำ แต่ต้องระวังเรื่องที่จะพูดในหัวข้อถัดไป เพราะนี่คือจุดที่เราเห็นคนพังบ่อยที่สุด

กับดักใหญ่: Staging Subdomain ที่หลุดขึ้น Google

เคสจริงที่เราเจอ ลูกค้าทำเว็บใหม่กับเอเจนซี่เจ้าหนึ่ง เอเจนซี่ตั้ง staging.brandname.com ไว้ให้ลูกค้าดูงาน ทำเสร็จส่งมอบ ปิดโปรเจกต์ แต่ลืมปิด staging ทิ้งไว้ ผ่านไปสี่เดือน ลูกค้าค้นชื่อแบรนด์ตัวเองใน Google แล้วเจอ staging.brandname.com ขึ้นมาก่อนเว็บจริง พร้อมเนื้อหาเวอร์ชันเก่าที่ยังเขียนว่า “ราคายังไม่อัปเดต”

ความเสียหายมีสามชั้น: หน้าเว็บซ้ำกันทั้งเว็บทำให้ Google สับสนว่าอันไหนของจริง, ลูกค้าที่หลงเข้าไปเห็นข้อมูลผิด, และแบรนด์ดูไม่โปร

กันไว้ด้วยสามชั้นนี้ ทำครบทุกชั้น อย่าเลือกอย่างใดอย่างหนึ่ง

1. ใส่ HTTP Authentication (รหัสผ่าน) — ชั้นนี้สำคัญที่สุด เพราะบอทเข้าไม่ได้ตั้งแต่แรก คนที่ได้ลิงก์มามั่ว ๆ ก็เข้าไม่ได้ ตั้งใน Nginx ด้วย auth_basic หรือใน cPanel ด้วย Directory Privacy ใช้เวลาห้านาที
2. ใส่ X-Robots-Tag: noindex ระดับเซิร์ฟเวอร์ — ครอบทุกไฟล์รวมถึง PDF และรูป ดีกว่าใส่ meta tag ในหน้าเว็บอย่างเดียวเพราะไม่มีทางลืมบางหน้า ดูวิธีเต็มในคู่มือ noindex
3. robots.txt แยกของ staging ที่ Disallow: / — ชั้นเสริม ย้ำอีกทีว่า อย่าใช้ robots.txt เป็นเครื่องมือเดียว เพราะ robots.txt แค่ห้ามคลาน ไม่ได้ห้ามจัดทำดัชนี ถ้ามีคนลิงก์มาที่ staging หน้านั้นก็ยังโผล่ใน SERP ได้ (มาแบบไม่มีคำอธิบาย ซึ่งยิ่งดูแย่)

ข้อควรระวังเวลาขึ้น production: เช็กเสมอว่า noindex ไม่ติดไปกับโค้ดที่ deploy ขึ้นเว็บจริง เคสเว็บใหม่หายจาก Google ทั้งเว็บ สาเหตุอันดับหนึ่งคือ noindex ที่ลืมถอด ตรวจด้วย URL Inspection ใน Search Console ทันทีหลัง deploy

วิธีย้ายจาก Subdomain มาเป็น Subdirectory อย่างปลอดภัย

ถ้าประเมินแล้วว่าควรย้าย ทำตามลำดับนี้ อย่าข้ามขั้น

ขั้นที่ 1 — ทำแผนที่ URL แบบ 1:1

ดึงรายการ URL ทั้งหมดจาก sitemap ของ subdomain รวมกับรายงาน Pages ใน Search Console และ crawl ด้วยเครื่องมืออย่าง Screaming Frog แล้วจับคู่ปลายทางใหม่ทีละอัน blog.example.com/seo-tips/ → example.com/blog/seo-tips/ ห้าม redirect ทุกอย่างไปหน้าแรก เพราะ Google จะตีเป็น soft 404 และคุณจะเสียอันดับทั้งหมด

ขั้นที่ 2 — ย้ายเนื้อหาขึ้นที่ใหม่ก่อน

ให้ URL ใหม่ทำงานได้สมบูรณ์ ทั้งรูป ทั้งลิงก์ภายใน ทั้ง schema ก่อนจะแตะ redirect ใด ๆ

ขั้นที่ 3 — วาง 301 redirect แบบถาวร

ต้องเป็น 301 ไม่ใช่ 302 และต้อง redirect ตรงจากปลายทางเดิมไปปลายทางใหม่ หลีกเลี่ยง redirect chain เช่น http → https → non-www → path ใหม่ ทุกช่วงที่เพิ่มคือความเสี่ยงและความช้า รายละเอียดทั้งหมดอยู่ในคู่มือ 301 redirect

ขั้นที่ 4 — อัปเดตลิงก์ภายในทั้งหมด

ไล่แก้ลิงก์ในเนื้อหาให้ชี้ไป URL ใหม่โดยตรง ไม่ปล่อยให้วิ่งผ่าน redirect รวมถึงเมนู footer breadcrumb และ canonical tag ของทุกหน้า

ขั้นที่ 5 — จัดการฝั่ง Search Console

• อย่าเพิ่งลบ property ของ subdomain เก็บไว้ดูอย่างน้อย 6 เดือนเพื่อตามดูว่ายังมีทราฟฟิกค้างไหม
• ส่ง sitemap ใหม่ที่มี URL ใหม่ทั้งหมด
• ใช้เครื่องมือ Change of Address ได้เฉพาะกรณีย้ายทั้งโดเมน ถ้าย้ายแค่ subdomain → subdirectory ในโดเมนเดียวกัน เครื่องมือนี้ใช้ไม่ได้ ต้องพึ่ง 301 ล้วน ๆ

ขั้นที่ 6 — ติดตามผล 8-12 สัปดาห์

ช่วงแรกอันดับแกว่งเป็นเรื่องปกติ ดูที่จำนวนหน้าที่ถูก index กับคลิกรวมของโดเมน อย่าตัดสินจากสัปดาห์เดียว และอย่าย้ายกลับกลางคัน — การกลับไปกลับมาสร้างความเสียหายมากกว่าการอดทนรอ

ช่วงเวลาที่ควรทำ: เลือกช่วงที่ทราฟฟิกต่ำสุดของปี สำหรับธุรกิจท่องเที่ยวภาคใต้คือช่วงโลว์ซีซัน ไม่ใช่เดือนก่อนไฮซีซันแน่นอน

ตั้งค่า Search Console และการวัดผลให้ถูก

ถ้ายังใช้ subdomain อยู่ มีสองเรื่องที่คนตั้งผิดบ่อย

ใช้ Domain property — ตอนเพิ่ม property ให้เลือกแบบ Domain (ยืนยันด้วย DNS TXT) แทน URL prefix เพราะ Domain property จะรวมข้อมูลของทุก subdomain และทุกโปรโตคอลไว้ให้เห็นภาพรวม แล้วค่อยเพิ่ม URL prefix property ของแต่ละ subdomain แยกไว้ดูรายละเอียดเชิงลึก

ตั้ง Analytics ให้ไม่นับซ้ำ — ใน GA4 การเดินทางข้าม subdomain ถูกจัดการด้วย cross-domain measurement ถ้าไม่ตั้ง คุณจะเห็นคนที่คลิกจาก blog. ไป example.com ถูกนับเป็นสอง session และแหล่งที่มากลายเป็น referral ตัวเอง ทำให้ตีความข้อมูลผิดหมด ดูวิธีตั้งค่าในคู่มือติดตั้ง GA4

Sitemap และ robots.txt แยกกันเสมอ — blog.example.com/robots.txt เป็นคนละไฟล์กับ example.com/robots.txt โดยสิ้นเชิง ต้องมีทั้งคู่และต้องถูกทั้งคู่

ข้อผิดพลาดที่เจอบ่อยที่สุด

• สร้าง subdomain เพราะ “ทำง่ายกว่า” — เหตุผลนี้แพงกว่าที่คิด เพราะคุณกำลังตัดสินใจเรื่องโครงสร้างระยะยาวด้วยความสะดวกระยะสั้น
• บล็อกอยู่ subdomain แล้วไม่ลิงก์กลับเว็บหลัก — เสียโอกาสส่งทั้ง authority และลูกค้า อย่างน้อยที่สุดถ้ายังย้ายไม่ได้ ให้ลิงก์หากันให้แน่นด้วย internal link ที่วางอย่างตั้งใจ
• ลืม SSL ของ subdomain — เบราว์เซอร์ขึ้นเตือน คนกดออกทันที
• ปล่อย staging ให้ Google เจอ — อย่างที่เล่าไปข้างต้น
• ใช้ wildcard DNS แบบไม่คิด — เรคคอร์ด * ทำให้ทุก subdomain ที่พิมพ์มั่วเปิดได้หมด เปิดช่องให้เกิดหน้าซ้ำและ subdomain takeover
• ปล่อย CNAME ค้างหลังเลิกใช้บริการ — ถ้า shop.example.com ยังชี้ไปแพลตฟอร์มที่คุณยกเลิกไปแล้ว คนอื่นอาจไปเคลมชื่อนั้นบนแพลตฟอร์มและควบคุม subdomain ของคุณได้ นี่คือช่องโหว่ที่เรียกว่า subdomain takeover ให้ลบเรคคอร์ดทุกครั้งที่เลิกใช้
• ย้ายด้วย 302 หรือ meta refresh — ไม่ส่งค่าเท่า 301 และทำให้ Google ลังเลว่าจะย้ายดัชนีดีไหม

FAQ สั้น ๆ

Subdomain นับเป็นคนละเว็บไหม? ในทางเทคนิคใช่ — Google มองว่าเป็นโฮสต์แยก และ Search Console ก็แยก property แต่ในบางบริบท Google ก็รวมสัญญาณของ subdomain กับโดเมนแม่ ไม่ได้แยกขาด 100% พูดให้ถูกคือ “แยกพอที่จะทำให้คุณเสียเปรียบถ้าไม่จำเป็น”

สร้าง subdomain ได้กี่อัน? ในทางเทคนิคแทบไม่จำกัด แต่ในทางปฏิบัติควรมีเท่าที่จำเป็น เพราะแต่ละอันคือภาระในการดูแล SSL, ความปลอดภัย และการวัดผล

ต้องจ่ายเพิ่มไหม? ตัว subdomain ฟรี แต่โฮสติ้งบางแพ็กเกจจำกัดจำนวน และ wildcard SSL แบบเสียเงินมีค่าใช้จ่าย (ถ้าใช้ Let’s Encrypt ก็ฟรี)

ถ้าเว็บหลักเป็น WordPress แต่อยากได้บล็อกที่เร็วกว่า? กรณีนี้คนมักหนีไป subdomain โดยอัตโนมัติ แต่จริง ๆ พิจารณาย้ายทั้งเว็บไปโครงสร้างที่เร็วขึ้นทีเดียวจะคุ้มกว่าในระยะยาว ลองอ่านเปรียบเทียบ Astro กับ WordPressก่อนตัดสินใจแยก

www กับ non-www ต่างกันไหมในแง่นี้? ต่างในทางเทคนิค (www คือ subdomain) แต่ไม่ต่างในทางปฏิบัติถ้าคุณตั้ง 301 ให้เหลือเวอร์ชันเดียวและ canonical ตรงกัน เลือกอันไหนก็ได้ แต่ต้องเลือกแล้วอยู่กับมัน

สรุป: เลือกยังไงให้ไม่ต้องมาย้ายทีหลัง

ถามตัวเองสามข้อนี้

1. หน้านี้ต้องการอันดับใน Google ไหม? ถ้าใช่ → subdirectory
2. มันรันบนระบบเดียวกับเว็บหลักได้ไหม? ถ้าได้ → subdirectory
3. มันเป็นส่วนขยายของแบรนด์เดียวกัน พูดกับลูกค้ากลุ่มเดียวกันไหม? ถ้าใช่ → subdirectory

ถ้าตอบ “ไม่” ตั้งแต่ข้อสองเป็นต้นไป — คนละ stack, ไม่ต้องการอันดับ, หรือเป็นระบบภายใน — subdomain คือคำตอบที่ถูกต้อง และไม่ต้องรู้สึกผิดที่ใช้มัน

หลักคิดสั้นที่สุด: เนื้อหาที่ใช้ล่าลูกค้าเก็บไว้ที่โดเมนหลักในรูปโฟลเดอร์ ระบบและเครื่องมือแยกไปอยู่ subdomain ได้ และไม่ว่าจะเลือกแบบไหน ให้โครงสร้างสอดคล้องกับสถาปัตยกรรมเว็บไซต์โดยรวมที่วางไว้ตั้งแต่ต้น เพราะการย้ายทีหลังแพงกว่าการคิดให้ดีตอนแรกเสมอ

ที่ Southern Whale เราช่วยธุรกิจในภาคใต้วางโครงสร้างเว็บและแก้ปัญหา Technical SEO แบบนี้มาแล้วหลายสิบเคส ตั้งแต่ตรวจว่า subdomain ที่มีอยู่กำลังกินแรงเว็บหลักหรือเปล่า ไปจนถึงวางแผนย้ายด้วย 301 แบบไม่เสียอันดับ ถ้าคุณกำลังลังเลว่าจะแยกหรือรวม หรือสงสัยว่าเว็บที่ทำมานานแล้วโครงสร้างถูกไหม คุยกับเราได้ที่บริการ SEO ของ Southern Whale เราดูให้ก่อนได้ว่าปัญหาอยู่ตรงไหนจริง ๆ ก่อนจะลงมือแก้