طبّقت مخطط LocalBusiness في تايوان، ومع ذلك لم تذكر محركات الذكاء الاصطناعي منشأتك. غالبًا لا تكمن المشكلة في الشفرة، بل في عدم تطابق البيانات. فعندما يسأل مستخدم Perplexity أو ChatGPT: «هل توجد عيادات أسنان موصى بها في حي شينيي بمدينة تايبيه؟»، يقارن الذكاء الاصطناعي أولًا الاسم والعنوان ورقم الهاتف في موقعك مع Google Business Profile والخرائط والأدلة المتخصصة. وإذا وجد ثلاث صيغ مختلفة لهذه البيانات، فسيفضّل تجاهل منشأتك على تخمين الصيغة الصحيحة. لذلك، العامل الحقيقي الذي يحدد إمكانية الاستشهاد بك هو اتساق NAP، أي الاسم والعنوان ورقم الهاتف. أما صياغة المخطط فلا تفعل سوى تقديم هذه الحقائق بتنسيق قابل للقراءة آليًا. يشرح هذا المقال تسلسل التطبيق: اختيار النوع، وإدخال العنوان، وتحديد ساعات العمل، ثم توحيد بيانات NAP على جميع المنصات.
لماذا تتعامل محركات الذكاء الاصطناعي بحساسية خاصة مع LocalBusiness؟
عند الإجابة عن استفسار محلي، يحتاج محرك الذكاء الاصطناعي إلى حقائق يسهل استخراجها: أين يقع المتجر؟ وهل هو مفتوح الآن؟ وما رقم هاتفه؟ العناوين الصينية ليست سهلة المعالجة آليًا؛ فقد يرى الإنسان أن «رقم 7، القسم 5، طريق شينيي، مدينة تايبيه» و«رقم 7، القسم 5، طريق شينيي، حي شينيي، مدينة تايبيه» يشيران إلى المكان نفسه، بينما قد يتعامل نموذج الاستخراج معهما ككيانين منفصلين. يفصل مخطط LocalBusiness هذه المعلومات داخل حقول ثابتة ويعرّفها بوضوح، وكأنك تسلّم المحرك الإجابة مباشرة وتوفّر عليه كلفة التخمين والمقارنة. وكلما قلّ ما يحتاج المحرك إلى تخمينه، زادت ثقته في إدراج منشأتك ضمن الإجابة.
الخطوة 1: اختر @type المناسب ولا تستخدم LocalBusiness لكل شيء
يضم schema.org عشرات الأنواع الفرعية تحت LocalBusiness. وكلما كان النوع أكثر تحديدًا، فهم المحرك طبيعة نشاطك بدقة أكبر. يمكن تصنيف مكتب محاسبة تحت LocalBusiness العام أو تحت AccountingService المتخصص، لكن الفرق كبير عندما يقيّم الذكاء الاصطناعي ما إذا كانت المنشأة هي الخدمة المهنية التي يبحث عنها المستخدم. ابدأ بأقرب نوع فرعي إلى نشاطك، وإن لم تجد نوعًا مطابقًا فعلًا، ارجع مستوى واحدًا واستخدم النوع العام.
- المطاعم والمقاهي: Restaurant وCafeOrCoffeeShop
- أطباء الأسنان والعيادات: Dentist وMedicalClinic
- المحامون ووكلاء الأراضي: Attorney وLegalService
- مكاتب المحاسبة ومسك الدفاتر: AccountingService
- متاجر التجزئة: Store، مع إمكان استخدام نوع أدق مثل ClothingStore أو HardwareStore وغيرها.
- صالونات التجميل وتصفيف الشعر: BeautySalon وHairSalon
- لا تلجأ إلى LocalBusiness العام إلا عندما لا يتوفر نوع مطابق فعلًا.
حقل العنوان: ربط التقسيمات الإدارية في تايوان بـPostalAddress
العنوان هو أكثر الأجزاء عرضة للأخطاء. يتكوّن PostalAddress من حقول ثابتة، ويجب توزيع التسلسل الإداري في تايوان عليها بدقة. لا تضع العنوان كاملًا، بما فيه رقم المبنى، داخل streetAddress؛ وإلا تعذّر على المحرك استخراج المقاطعة أو المدينة والمنطقة الإدارية كلٌّ على حدة.
- addressCountry: أدخل رمز الدولة "TW"، وليس "Taiwan" أو "Taiwan"
- addressRegion: البلدية أو المقاطعة، مثل "مدينة تايبيه" و"مدينة تايبيه الجديدة"
- addressLocality: الحي أو البلدة، مثل "حي شينيي"
- streetAddress: الطريق والقسم والحارة والرقم، مثل "رقم 7، القسم 5، طريق شينيي"
- postalCode: الرمز البريدي بصيغة 3+3، مثل "110011"
- geo: خط العرض وخط الطول، ويجب أن تتطابق الإحداثيات مع موضع الدبوس على Google Maps
ساعات العمل: كيف تستخدم openingHoursSpecification بلا أخطاء؟
يُستخدم OpeningHoursSpecification لتحديد ساعات العمل، وdayOfWeek لتعريف أيام كل فترة، بينما تُكتب قيمتا opens وcloses بصيغة HH:MM وفق نظام 24-hour. إذا كان المتجر يغلق وقت الظهيرة، فلا تسجل ساعات العمل من 09:00 إلى 21:00 كفترة متصلة؛ قسّمها إلى فترتين، مثل 11:00–14:00 و17:00–21:00، وإلا فقد يخبر الذكاء الاصطناعي المستخدم بأنك مفتوح عند الساعة 3 مساءً. لا تُدرج يوم العطلة إذا كانت المنشأة مغلقة. وإذا كانت تعمل 24 ساعة يوميًا، فأدخل 00:00 في كل من opens وcloses. أما التعديلات المؤقتة، مثل عطلة رأس السنة القمرية أو العطلات الوطنية، فاستخدم لها specialOpeningHoursSpecification مع نطاق التواريخ؛ فهذا أكثر أمانًا من تعديل الجدول الأساسي مباشرة. وبعد أي تغيير، لا تنسَ مزامنته مع ساعات العطلات في Google Business Profile حتى تتطابق المعلومة في الجانبين.
اتساق NAP: المخطط ليس سوى عقدة واحدة ضمن شبكة المصادر
لن تنفعك دقة المخطط مهما كانت عالية إذا خالفت بياناته ما يظهر في بقية المصادر. يجب أن يتطابق الاسم والعنوان ورقم الهاتف حرفيًا على كل منصة، بما في ذلك علامات الترقيم والتنسيق. ويظهر الالتباس بوضوح في أرقام الهاتف: يعرض الموقع الرسمي "02-1234-5678"، وتعرض صفحة Google Business Profile الرقم "(02)12345678"، بينما يسجله المخطط بصيغة "+886-2-1234-5678". يستطيع الإنسان فهم أنها كلها للرقم نفسه، لكن الآلة قد تراها ثلاث معلومات منفصلة. يُنصح باستخدام تنسيق E.164 دائمًا في البيانات المنظّمة، مثل "+886212345678". ويمكن تنسيق النسخة الظاهرة للزوار بطريقة مختلفة، لكن يجب اعتماد صيغة واحدة فقط داخل المخطط.
- Google Business Profile
- المخطط وتذييل الموقع وصفحة التواصل في الموقع الرسمي
- صفحات النشاط التجاري على Facebook وInstagram
- Apple Maps ومنصات الملاحة المختلفة
- الأدلة المتخصصة ودليل الصفحات الصفراء المحلي
عند تدقيق المواقع الرسمية المحلية لعملائنا، لا يكون الخلل الأكثر شيوعًا غياب المخطط، بل كتابة رقم الهاتف نفسه بأربع صيغ على أربع منصات. في نظر محرك الذكاء الاصطناعي، لا تبدو هذه منشأة واحدة، بل أربع منشآت متشابهة جدًا.— Tenten GEO audit notes
قائمة التحقق قبل الإطلاق
- استخدم Google Rich Results Test للتأكد من أن المخطط قابل للتحليل ولا يحتوي على أخطاء
- استخدم Schema Markup Validator للتحقق من صحة بنية كل حقل
- ضع بيانات NAP الواردة في المخطط حرفيًا بجانب بيانات Google Business Profile وقارن بينهما لاكتشاف أي اختلاف.
- اطرح سؤالًا محليًا على محرك ذكاء اصطناعي، ثم تحقق مما إذا كان العنوان وساعات العمل في إجابته صحيحين.
- أعد الفحص دوريًا بعد الإطلاق. وعند تغيير العنوان أو رقم الهاتف، حدّث جميع المنصات بالتزامن.
لم تكن صعوبة مخطط LocalBusiness يومًا في كتابة JSON-LD، بل في إبقاء الحقائق الموزعة على عشرات المنصات متطابقة بمرور الوقت. إذا لم تكن متأكدًا من عدد المنشآت التي توحي بها بيانات NAP والبيانات المنظّمة لمحركات الذكاء الاصطناعي، يكشف تدقيق GEO من Tenten GEO لمدة 30 يومًا هذه الفجوات دفعة واحدة. وإذا أردت الحصول سريعًا على اتجاه أولي، يمكنك حجز جلسة تشخيص GEO مدتها 30 دقيقة؛ وسنجري استعلامًا محليًا باستخدام عنوان موقعك الفعلي.
