SEO في Sanity

يخزن Sanity المحتوى في صورة JSON ولا ينتج أي HTML؛ لذلك تحدد الواجهة الأمامية مخرجات SEO. يغطي الدليل أوضاع التصيير وPortable Text وكائن SEO وخرائط الموقع وحماية المسودات بـnoindex وJSON-LD والإضافات.

نُشر أول مرة: 27 يونيو 2026 · آخر تحديث: 13 أغسطس 2026 · Advanced
اللغات

Sanity نظام إدارة محتوى منفصل يخزن المحتوى في صورة JSON منظمة داخل Content Lake ولا ينتج HTML، لذا تتحكم الواجهة الأمامية المبنية مثلًا بـNext.js أو Astro أو Remix في كل مخرجات SEO. العامل الأهم هو التصيير: يرسل SSG وSSR ‏HTML مكتملًا، بينما ينطوي CSR على مخاطرة لأن عقود تصيير زواحف نماذج اللغة تختلف باختلاف المزود. ‏Portable Text شجرة بنية مجردة بصيغة JSON لا HTML، وعلى الواجهة تسلسلها. أنشئ كائن SEO قابلًا لإعادة الاستخدام، وولّد خرائط الموقع وJSON-LD برمجيًا، وأبعد المسودات عن الفهرس بترويسة X-Robots-Tag: noindex، واستخدم sanity-plugin-seo بدل لوحة Yoast المهملة. نجاح SEO في Sanity ثمرة بنية مقصودة لا إضافات.

الخلاصة — ‏Sanity محايد تجاه المخرجات: يخزن JSON منظمًا في Content Lake ولا يصدر أي HTML، ولذلك تحدد طريقة التصيير في الواجهة الأمامية كل شيء. يقدم SSG وSSR ‏HTML مكتملًا وهما آمنان، بينما ينطوي CSR على مخاطرة لأن عقود تصيير زواحف نماذج اللغة تختلف بين المزودين. ‏Portable Text شجرة بنية مجردة بصيغة JSON يجب على الواجهة تسلسلها. ابنِ كائن seo قابلًا لإعادة الاستخدام في نموذج المحتوى، مع قيم تجاوز لا حقول إلزامية باستخدام coalesce()، وأنشئ خرائط المواقع وJSON-LD برمجيًا من الحقول الموجودة، وأبق المسودات خارج الفهرس بترويسة X-Robots-Tag: noindex في كل استجابة معاينة. استخدم sanity-plugin-seo ولا تستخدم لوحة Yoast المهملة، لكن تذكر أن «نجاح SEO في Sanity يأتي من البنية المقصودة لا المكونات الإضافية».

‏Sanity مخزن محتوى لا ناشر

مبدأ أول مفيد: يتعامل Sanity مع محتواك، لا مع تصييره. تخزن Content Lake كل شيء في صورة JSON منظم، ويُستعلم عنه باستخدام GROQ، لغة استعلام Sanity، أو REST. أما Sanity Studio، وهي واجهة التحرير، فتطبيق React أحادي الصفحة يوجد عادةً على نطاق فرعي مستقل ينتهي بـ.sanity.studio وليس مما تريد فهرسته. لا ينتج أي جزء من هذه المنظومة HTML.

Evidence for this claim Sanity Content Lake is queried using APIs and GROQ; it is distinct from a site's frontend rendering layer. Scope: Sanity-hosted content data and query APIs. Confidence: high · Verified: Sanity: Content Lake

لذلك يعيش سطح SEO كله في إطار الواجهة الأمامية. وتوضح Webstacks أن Sanity يتولى تخزين المحتوى وتحريره، بينما تتولى الواجهة الأمامية مخرجات SEO. وهذا ليس قيدًا، بل جوهر النموذج المنفصل. ويصف فريق Sanity استخدامه بأنه SEO لنظام منفصل يتطلب تنفيذًا تقنيًا مدروسًا، لكنه يتيح للمحتوى الوصول إلى مستخدمين أكثر عبر القنوات المختلفة. العمل حقيقي، لكنه العمل نفسه في أي بناء منفصل؛ راجع SEO لنظام إدارة محتوى منفصل.

طريقة التصيير هي الأساس

لأن الواجهة الأمامية تبني HTML، فإن قرار التصيير هو أهم اختيار منفرد لـSEO في موقع Sanity. توجد أربع طرق:

SSG، أي التوليد الثابت للموقع. يُجلب المحتوى من Sanity وقت البناء ويُدمج في HTML ثابت تقدمه CDN. وهذه أفضل حالة لـSEO: ‏HTML مصيّر بالكامل من أول طلب وTTFB سريع. وهي مثالية للمقالات وصفحات التسويق والمنتجات والهبوط. المقايضة هي الحداثة، إذ يحتاج المحتوى المتغير إلى إعادة بناء، وتحل ISR ذلك.

SSR، أي التصيير من جانب الخادم. يُجلب المحتوى عند كل طلب ويُصيّر HTML كاملًا على الخادم. وهو ممتاز لـSEO ودائم الحداثة، ويناسب المحتوى كثير التحديث. والمقايضة هي تكلفة البنية الأساسية وTTFB أعلى قليلًا من الملفات الثابتة.

ISR، أي إعادة التوليد الثابت التزايدي في Vercel وNext.js. تتجدد الصفحات الثابتة في الخلفية، ومن الأفضل أن يشغل التجديد webhook من Sanity عند النشر حتى يعاد بناء الصفحة لحظة ضغط المحرر على زر النشر. ويجمع ذلك سرعة SSG وحداثة SSR للمحتوى الذي يتغير كل ساعات أو أيام.

CSR، أي التصيير من جانب العميل. يصل غلاف HTML ثم تجلب JavaScript المحتوى من Sanity وتبني DOM في المتصفح. وهذا أسوأ خيار لـSEO؛ إذ يجب على Googlebot وضع الصفحة في طابور موجة تصيير لاحقة، ويظل التوقيت غير متوقع، بينما لا ترى زواحف الذكاء الاصطناعي وكثير من الروبوتات سوى الغلاف. لا يناسب CSR إلا المحتوى الموجود خلف المصادقة الذي لا تريد فهرسته أصلًا.

ولا تستخدم الاختصار القديم: أهملت Google التصيير الديناميكي، أي تقديم HTML مصيّر مسبقًا للروبوتات وCSR للمستخدمين. تقول رسميًا: “dynamic rendering was a workaround and not a long-term solution,” (الترجمة العربية): «كان التصيير الديناميكي حلًا التفافيًا لا حلًا طويل الأجل»، وتوصي الآن بـ*“server-side rendering, static rendering, or hydration.”* (الترجمة العربية): «التصيير من جانب الخادم أو التصيير الثابت أوhydration». وهذا يعني لموقع Sanity استخدام SSG أو SSR لا حيلة لكشف الروبوتات. وترد المعالجة الكاملة في JavaScript SEO.

Evidence for this claim Google describes dynamic rendering as a workaround rather than a recommended long-term solution and recommends server-side rendering, static rendering, or hydration. Scope: Google Search guidance for JavaScript sites. Confidence: high · Verified: Google: Dynamic rendering

‏Portable Text — نص الصفحة شجرة بنية مجردة بصيغة JSON

هذا أكثر ما يخص Sanity تحديدًا في الصفحة. يخزن Sanity النص المنسق بصيغة Portable Text، وهي شجرة بنية مجردة في JSON وليست HTML. يظهر نص Content Lake كمصفوفة كتل ذات أنواع، لا وسوم <p>. ويجب على واجهتك تسلسله إلى HTML قبل أن يستطيع أي زاحف قراءته:

  • @portabletext/react لإطاري React وNext.js.
  • @portabletext/to-html مستقل عن الإطار، ويناسب Astro وRemix وغيرهما.
  • الحزمة القديمة @sanity/block-content-to-react مهملة؛ فلا تستخدمها.

إذا صيّرت على الخادم أو وقت البناء، يحدث التسلسل قبل إرسال الصفحة وتتلقى الزواحف HTML كاملًا. أما إذا صيّرت لدى العميل، فيجري التسلسل في المتصفح. ولأن عقود تصيير زواحف نماذج اللغة تختلف بين المزودين، فإن Portable Text مع CSR يُعرّض التغطية للخطر على نحو يتجنبه HTML الخام. وثمة دالة GROQ مفيدة: تستخرج pt::text(body) النص العادي كله من حقل Portable Text كسلسلة، وهي مثالية لتغذية أوصاف JSON-LD من دون حقل تحرير منفصل.

نمذجة المحتوى لـSEO — كائن SEO القابل لإعادة الاستخدام

أنظف نمط، وهو الذي تدرسه دورة Sanity نفسها، كائن seo واحد قابل لإعادة الاستخدام يضاف إلى كل نوع مستند، لا حقول SEO منسوخة في كل نوع. ومبدأ التصميم الأساسي في Sanity Learn هو ألا تُفرض الحقول المتعلقة بـSEO دائمًا على كتّاب المحتوى، بل تُستخدم عند توفيرها لتجاوز القيم المشتقة من المحتوى القائم.

عمليًا، يعني ذلك أن حقول SEO قيم تجاوز ذات بدائل احتياطية تنفذ باستخدام coalesce() في GROQ:

"title": coalesce(seo.title, title, ""),
"description": coalesce(seo.description, excerpt, "")

الحد الأدنى القابل للاستخدام من كائن seo هو: metaTitle بما لا يزيد على 65 حرفًا، وmetaDescription بما لا يزيد على 155 حرفًا، وcanonicalUrl، وopenGraphImage بأبعاد 1200×630، وقيمة منطقية noIndex. أضف قواعد تحقق في Sanity لفرض حدود الأحرف قبل النشر حتى يكتشف المحررون مشكلات كانت المنصة ستسمح بها. استخدم نوع slug مع دالة توليد مخصصة، واستخدم المراجع للروابط الداخلية كي تنتشر تغييرات URL تلقائيًا. وأضف قيمة منطقية hideFromSearch واستبعدها من استعلام GROQ لخريطة الموقع ومن بيانات robots الوصفية للصفحة معًا.

البيانات الوصفية وخرائط المواقع وcanonical — كلها تُبنى في الواجهة الأمامية

البيانات الوصفية. في Next.js App Router استخدم الدالة المصدّرة generateMetadata()، لا وسوم <head> المضمنة، حتى لا تتكرر البيانات عبر التخطيطات المتداخلة. ابنِ دالة مساعدة واحدة على الخادم تستقبل نتيجة GROQ وتعيد كائن البيانات الوصفية الخاص بالإطار؛ نفذها مرة واستخدمها في كل موضع. ويمكن إنشاء صور Open Graph ديناميكيًا باستخدام Edge OG في Next.js مع جلب المحتوى مباشرة من Sanity.

خرائط المواقع. لا توجد خريطة تلقائية؛ بل تبنيها من استعلام GROQ ثم مصفوفة URL ثم XML، باستخدام sitemap.ts في Next.js أو @astrojs/sitemap في Astro. استبعد المسودات والصفحات المخفية دائمًا:

*[_type in ["page", "post"] && defined(slug.current) && hideFromSearch != true]

استخدم _updatedAt لا _createdAt أو تاريخًا يدويًا لقيمة lastModified، وأبق كل ملف خريطة تحت 50 000 عنوان URL مع فهرس للمواقع الأكبر، وشغّل إعادة التوليد عبر webhook من Sanity عند النشر أو إلغاء النشر كي لا تصبح الخريطة قديمة.

عناوين canonical. اضبطها من نموذج المحتوى، واجعل القيمة الافتراضية canonical ذاتي الإشارة، وابنِ العناوين المطلقة من قيمة SITE_URL واحدة حتى لا تنحرف. وترد الآليات في تحديد canonical.

البيانات المنظمة — ولّدها ولا تجعلها محتوى يحرره المستخدم

النمط الصحيح هو توليد JSON-LD برمجيًا من حقول المحتوى القائمة وقت التصيير، لا بناء واجهة منفصلة لتحرير JSON-LD في Studio، لأن ذلك لا يفعل سوى إنشاء انحراف بين المحتوى والترميز. قاعدة Roboto Studio صريحة: “Derive JSON-LD from existing fields, at render time, in code.” (الترجمة العربية): «اشتق JSON-LD من الحقول القائمة وقت التصيير داخل الشيفرة». ويوافق Sanity: “JSON-LD is a powerful way to provide structured data to search engines — fortunately structured data is what Sanity does best.” (الترجمة العربية): «JSON-LD وسيلة قوية لتقديم البيانات المنظمة إلى محركات البحث، ولحسن الحظ فالبيانات المنظمة هي ما يتقنه Sanity».

استخدم pt::text(body) لاستخراج النص العادي لأوصاف schema، وحزمة TypeScript المسماة schema-dts لضمان الأنواع، وصيّره باستخدام <script type="application/ld+json">. ولاحظ أن “the JSON-LD markup can be rendered anywhere in the page — it doesn’t need to be stored inside the <head>.” (الترجمة العربية): «يمكن تصيير ترميز JSON-LD في أي موضع من الصفحة، ولا يلزم تخزينه داخل <head>». والأنواع ذات الأولوية لمواقع المحتوى هي Article وBlogPosting وBreadcrumbList وFAQPage وOrganization وWebSite.

إبقاء المسودات خارج Google — مأزق وقع فعلًا

يتحكم نظام perspective في Sanity في ظهور المسودات؛ فالقيمة published تعيد محتوى الإنتاج وحده، بينما تعيد drafts مستندات المسودة للمعاينة. استخدم منظور published دائمًا في استدعاءات API للإنتاج. لكن هذا وحده لا يكفي لأن عناوين المسودات قد تتسرب. وكما روى أحد المطورين، تكمن الخطورة في “a client panicking because an unpublished landing page showed up in Google Search Console. If a content editor shares that URL in Slack, and someone clicks it from a browser that’s then crawled (it happens), the draft content can end up indexed.” (الترجمة العربية): «ذعر عميل لأن صفحة هبوط غير منشورة ظهرت في Google Search Console. فإذا شارك محرر المحتوى عنوانها في Slack ونقره شخص من متصفح يُزحف إليه لاحقًا، وقد حدث ذلك، فقد ينتهي الأمر بفهرسة محتوى المسودة».

الدفاع الموثوق متعدد الطبقات:

  1. استخدم منظور published في الإنتاج، ولا تكشف أبدًا نقطة معاينة غير محمية.
  2. أضف ترويسة HTTP ‏**X-Robots-Tag: noindex إلى كل استجابة في وضع المسودة أو المعاينة**؛ فحتى إذا تسرب URL للمسودة وزُحف إليه، يحترم Googlebot الترويسة ولا يفهرسه. لا تعتمد على robots.txt هنا؛ فالترويسة أوثق من disallow لصفحات المعاينة.
  3. تحقق من سر المعاينة على الخادم، ولا تعكسه في URL لإعادة التوجيه، واقصر نقطة تفعيل المعاينة على أصل Studio الخاص بك.

‏Robots وإعادة التوجيه وSEO للصور وhreflang

robots.txt ملف ثابت في الواجهة الأمامية، مثل app/robots.ts في Next.js. احظر مسارات Studio فقط إذا كانت على النطاق نفسه، باستخدام Disallow: /studio/، ولا تحاول حظر صفحات المعاينة به.

عمليات إعادة التوجيه مكسب حقيقي لسير العمل: خزّنها كمستندات Sanity تحتوي from وto وstatusCode كي يديرها فريق المحتوى من دون نشر ينفذه مطور، ثم طبقها في middleware.ts لدى Next.js أوفي طبقة CDN أو Worker، لا داخل Sanity نفسه. أضف قواعد تحقق تمنع الحلقات والمسارات غير الصالحة.

SEO للصور: استخدم CDN للصور في Sanity مع ?auto=format للحصول تلقائيًا على WebP أو AVIF، وأدر النص البديل على مستوى الأصل مع إمكان تجاوزه في المستند، واستخدم أسماء ملفات مقروءة بدل العناوين المجزأة، واضبط hotspot وcrop حتى تبقي الاقتصاصات التلقائية العنصر الأساسي، وهو مهم خصوصًا لصور OG.

Hreflang: مثّل تنويعات الإعدادات المحلية كمستندات Sanity مستقلة تشير إلى النسخة المعتمدة، وأنشئ hreflang من استعلام GROQ يعيد slugs للإعدادات المحلية كلها، وامنح كل صفحة محلية canonical ذاتي الإشارة؛ ولا تجعل صفحة غير إنجليزية تشير عبر canonical إلى الإنجليزية.

المكونات الإضافية — مفيدة لكنها ليست بديلًا

  • sanity-plugin-seo — التوصية الأساسية، وله أكثر من 22k تنزيل. يقدم درجة SEO مباشرة ومعاينة meta وOG وبطاقات اجتماعية وتحكمًا في robots وhreflang وقابلية القراءة. وتضيف الفئة المدعومة بالذكاء الاصطناعي اقتراحات الكلمات وتوليد meta.
  • sanity-plugin-seofields — بديل يوفر 39 نوعًا من schema.org ولوحة SEO Health ودوال مساعدة لـNext.js مثل buildSeoMeta().
  • sanity-plugin-seo-paneمهمل. هذا هو تكامل Yoast القديم الذي أزيل بسبب تبعية قديمة، لكنه ما زال يظهر في شروح قديمة؛ فلا تستخدمه.

ويلخص Yanatiev الفكرة بأن نجاح SEO في Sanity يأتي من البنية المقصودة لا المكونات الإضافية. تكشف الإضافات الحقول وتقدم ملاحظات تحريرية، لكنها لا تستبدل نمذجة المحتوى السليمة.

البحث بالذكاء الاصطناعي وAEO

التطور في 2026 هو أن زواحف تدريب نماذج اللغة والاسترجاع، مثل Anthropic وOpenAI وCommon Crawl، لا تنفذ JavaScript عادةً اليوم؛ لذا يظل Portable Text المعروض عبر CSR غير مرئي لها إلى حد بعيد، بصرف النظر عن قدرة Googlebot على تصييره. لكن ذلك خاص بكل مزود وليس عقدًا مضمونًا. وتمثل منظومة Gemini الاستثناء الملحوظ لأنها تعيد استخدام بنية تصيير Googlebot، كما يمكن أن يتغير سلوك المزودين. تعامل مع عدم التصيير على أنه الافتراض الآمن للبناء، لا قانونًا دائمًا. وإلى جانب التصيير توجد طريقتان مناسبتان لـSanity: تقديم Markdown عبر التفاوض على المحتوى عند وجود Accept: text/markdown، إذ تحول حزمة @portabletext/markdown ‏Portable Text من دون تأليف إضافي، ومراقبة Bing تحديدًا لأن فهرسه يغذي إجابات التصفح في ChatGPT. ويشكك Knut Melvær من Sanity في جدوى llms.txt للمواقع الكبيرة لأن النطاق الشامل وحدود حجم الملف يجعلانها غير عملية، بينما يوفر التفاوض على مستوى الصفحة دقة أكبر. كما يلخص Roboto Studio العقلية الصحيحة بأن AEO وSEO يعتمدان على البنية التحتية نفسها، ومن ثم ينبغي التعامل معهما كمهمة واحدة. المزيد في البحث بالذكاء الاصطناعي.

خرافات تستحق الإنهاء

  • «ينفذ Sanity ‏SEO تلقائيًا مثل WordPress مع Yoast». لا؛ فهو لا ينتج أي HTML ولا ينفذ شيئًا تلقائيًا.
  • «أي طريقة تصيير مناسبة ما دام المحتوى في Sanity». لا؛ يضر CSR بالفهرسة والظهور للذكاء الاصطناعي، والتصيير الديناميكي مهمل.
  • «لا يمكن فهرسة المسودات». يمكن فهرستها إذا تسرب URL للمعاينة؛ استخدم ترويسة noindex.
  • «Portable Text هو HTML». بل شجرة JSON يجب على الواجهة تسلسلها.
  • «تحتاج إلى محرر JSON-LD في Studio». لا؛ ولّده من الحقول القائمة.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.