ربط سلة بسيرش كونسول: التحقق وإرسال خريطة الموقع

لإضافة متجر سلة إلى Google Search Console، يُضاف عنوان المتجر كخاصية، ثم تُثبت ملكيته بالطريقة المناسبة، مثل سجل DNS أو إحدى طرق التحقق المتاحة لعنوان URL. بعد نجاح التحقق، يمكن متابعة بيانات الموقع وإرسال خريطة صفحاته من تقرير Sitemaps (جوجل، جوجل). هذه هي الخطوات الأساسية في ربط سلة بسيرش كونسول، بغض النظر عن طريقة التحقق المختارة.

تختلف التفاصيل بحسب نوع الخاصية وعنوان النطاق وإمكانية الوصول إلى إعداداته. لذلك يبدأ العمل بتحديد عنوان المتجر الذي سيُتابَع، ثم اختيار طريقة تحقق يمكن تنفيذها، قبل الانتقال إلى خريطة الموقع. وإرسال الخريطة يساعد Google على اكتشاف العناوين، لكنه لا يعني فهرسة كل صفحة فيها.

ما الذي يعنيه ربط متجر سلة بـ Search Console؟

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

بعد التحقق، يمكن استخدام الخاصية لمراجعة ما تعرضه الأداة عن الموقع، وإرسال خريطة الموقع لمساعدة Google على العثور على صفحاته. وتظل هناك فروق مهمة بين هذه المراحل: إثبات الملكية يفتح الوصول إلى الخاصية، وإرسال الخريطة يعرّف Google بعناوين الصفحات، أما الفهرسة فهي مسألة منفصلة لا يضمنها مجرد إرسال الخريطة. فهم هذا الفرق يمنع تفسير نجاح التحقق أو قبول الخريطة على أنه ظهور فوري لجميع صفحات المتجر في نتائج البحث.

لا تتطلب البداية معرفة تقنية واسعة، لكنها تتطلب الانتباه إلى العنوان المدخل وطريقة التحقق. فكثير من التعثر يحدث قبل الوصول إلى أي تقارير، حين تُضاف خاصية بعنوان لا يطابق العنوان المراد متابعته، أو تُختار طريقة لا يمكن تطبيقها على إعدادات الموقع.

ما المطلوب قبل إضافة المتجر؟

أول ما يلزم هو تحديد النطاق أو العنوان الذي يعمل عليه المتجر بالفعل. ينبغي التمييز بين اسم النطاق وحده، مثل example.com، وعنوان كامل يبدأ ببروتوكول HTTPS وقد يتضمن www. هذا الفرق يحدد نوع الخاصية المناسب وما الذي ستشمله بياناتها. ومن المفيد فتح المتجر في المتصفح ونسخ عنوانه كما يظهر، بدل الاعتماد على كتابة العنوان من الذاكرة.

بعد ذلك، تُحدَّد الجهة التي يمكن من خلالها إثبات الملكية. إذا كان الاختيار هو خاصية النطاق Domain، فستكون هناك حاجة إلى الوصول إلى إعدادات DNS لدى الجهة التي تدير النطاق، لأن التحقق بهذا النوع يتم عبر DNS. أما إذا كان الاختيار خاصية URL-prefix، فيُنظر إلى طرق التحقق التي يعرضها Search Console لتلك الخاصية وإلى إمكانية تنفيذ إحداها على الموقع.

قبل البدء، تساعد الإجابة عن هذه الأسئلة على اختيار مسار واضح:

• ما العنوان النهائي الذي يصل إليه الزائر عند فتح المتجر: هل يتضمن www أم لا؟ وهل يعمل عبر HTTPS؟
• هل تتوفر صلاحية تعديل سجلات DNS للنطاق لدى الجهة التي تديره؟
• إذا طُرحت طريقة تعتمد على ملف أو وسم HTML، هل يمكن وضعه في الموضع الذي تحدده تعليمات التحقق؟
• هل أُضيفت خاصية للمتجر سابقًا؟ إن وُجدت، فالأفضل مراجعة عنوانها ونوعها قبل إنشاء خاصية أخرى للعنوان نفسه.

هذه الأسئلة ليست إجراءات إضافية داخل سلة؛ الغرض منها تجنب البدء بطريقة يتعذر إكمالها. والأهم أن وجود المتجر تحت إدارة صاحب الحساب لا يغني عن إثبات ملكية عنوانه داخل Search Console.

أيهما أنسب: Domain أم URL-prefix؟

الفرق الأساسي هو نطاق التغطية. خاصية Domain تُضاف باسم النطاق دون بروتوكول، وتشمل نسخه المختلفة، ومنها النطاقات الفرعية ونسختا HTTP وHTTPS. ويتطلب إثبات ملكيتها التحقق عبر DNS. وهي مناسبة حين تكون إدارة النطاق متاحة ويُراد جمع نسخ الموقع تحت خاصية واحدة.

أما خاصية URL-prefix فتُضاف بعنوان كامل يتضمن البروتوكول، مثل نسخة HTTPS من عنوان المتجر. وتغطي العناوين التي تبدأ بالمقدمة المحددة، لا كل نسخ النطاق تلقائيًا؛ لذلك يؤثر اختلاف البروتوكول أو وجود www في العنوان الذي تجري متابعته. وتظهر لها طرق تحقق بحسب ما يتيحه Search Console للخاصية، وقد تتضمن ملف HTML أو وسم HTML أو DNS.

إذا كان عنوان المتجر الظاهر للزوار يتضمن www، فإن إدخال النسخة التي لا تتضمنها في خاصية URL-prefix ليس تفصيلًا شكليًا. ينبغي التأكد من أن الخاصية المفتوحة هي التي تغطي العناوين المطلوب فحصها. ولهذا تنبّه إرشادات Google إلى أهمية الانتباه إلى نسختي الموقع مع www وبدونها عند متابعة الفهرسة.

لا يوجد اختيار واحد يُفرض على جميع المتاجر. يمكن أن تكون Domain أوضح لإدارة النطاق بنسخه المختلفة عندما تتوفر صلاحية DNS، بينما تكون URL-prefix مناسبة لمتابعة عنوان محدد مع استخدام طريقة تحقق متاحة له. القرار العملي هو اختيار خاصية يمكن التحقق منها وتطابق العنوان الذي يُراد مراقبته، لا اختيار النوع بناءً على اسمه فقط.

التحقق من ملكية النطاق عبر DNS

التحقق عبر DNS يثبت التحكم في النطاق بإضافة سجل لدى الجهة التي تدير إعداداته. وهو مسار التحقق المطلوب لخاصية Domain، وتوصي Google عادةً بالاعتماد عليه لأنه يغطي نسخ النطاق المختلفة من خلال التحقق نفسه. لا تُضاف قيمة السجل في صفحة من صفحات المتجر، بل في إعدادات DNS المرتبطة بنطاقه.

يمكن تنفيذ العملية بالترتيب الآتي:

1. افتح Search Console، وأضف خاصية من نوع Domain بكتابة اسم النطاق وفق النموذج الذي تعرضه الأداة، من دون إدخال بروتوكول أو مسار صفحة.
2. افتح تعليمات التحقق المعروضة للخاصية. ستحدد Google نوع السجل المطلوب، مثل TXT أو CNAME، والقيمة التي يجب إضافتها. تُنسخ التفاصيل كما تظهر، لأن قيمة التحقق تخص هذه العملية.
3. انتقل إلى إعدادات DNS لدى الجهة التي تدير النطاق، وأنشئ السجل بالنوع والاسم والقيمة الواردة في تعليمات التحقق. من المهم وضع السجل في إعدادات النطاق الصحيح، لا في حساب يدير نطاقًا آخر.
4. احفظ التغيير، ثم امنح السجل فرصة للظهور في نظام DNS. يمكن الاستعانة بأداة فحص DNS للتأكد من ظهور سجل TXT عند استخدامه قبل العودة إلى زر «تحقق» في Search Console.
5. ارجع إلى صفحة التحقق واضغط «تحقق». إذا لم تنجح المحاولة فورًا، فلا داعي إلى إنشاء سجل جديد عشوائيًا؛ تُراجَع القيمة وموضع إضافتها وظهورها أولًا.

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

قد يلتبس أيضًا مكان تعديل DNS: الجهة التي استُخدمت لتسجيل النطاق ليست بالضرورة الجهة التي تُدار منها سجلاته حاليًا. إن لم يظهر السجل بعد حفظه، فمراجعة مكان إدارة DNS خطوة أنفع من تكرار الضغط على «تحقق». ويجب إبقاء وسيلة التحقق قائمة حتى يظل إثبات الملكية صالحًا.

متى يُستخدم ملف HTML أو وسم HTML؟

قد يعرض Search Console رفع ملف HTML أو إضافة وسم HTML ضمن طرق التحقق لخاصية URL-prefix. هاتان طريقتان مختلفتان عن إثبات ملكية Domain، الذي يتطلب DNS. لذلك ينبغي التأكد من نوع الخاصية قبل البحث عن مكان رفع ملف أو تعديل الصفحة.

في طريقة الملف، يُنزَّل ملف التحقق الفريد الذي توفره Google، ثم يوضع على الموقع في الدليل الجذر أو في المسار المحدد بتعليمات التحقق، بحيث يمكن فتحه من العنوان المطلوب قبل الضغط على «تحقق». لا يكفي الاحتفاظ بالملف على الجهاز أو رفعه في مكان آخر؛ معيار نجاح هذه الطريقة هو أن تتمكن Google من الوصول إليه في العنوان الذي عينته.

أما طريقة الوسم، فتعتمد على إضافة وسم التحقق الذي تعرضه الأداة إلى صفحة الموقع في الموضع المطلوب، ثم التأكد من وجوده قبل إعادة التحقق. وضع النص في وصف منتج أو في محتوى صفحة ظاهر للزائر لا يؤدي الغرض إذا كانت التعليمات تطلب إضافته إلى شيفرة الصفحة.

بالنسبة إلى متجر سلة، لا يُفترض توفر صلاحية رفع ملفات إلى جذر الموقع أو تعديل موضع الوسم لمجرد ظهور الطريقة في Search Console. يُفحص ما تسمح به إعدادات المتجر والنطاق الفعلي أولًا؛ وإذا تعذر تنفيذ تعليمات الطريقة كما هي، فالأفضل اختيار وسيلة تحقق أخرى متاحة بدل محاولة وضع الملف أو الوسم في مكان غير مخصص له. وتبقى خطوات Google الظاهرة للخاصية هي المرجع في تحديد العنوان أو الموضع المطلوب.

إرسال خريطة موقع المتجر بعد التحقق

خريطة الموقع ملف يضم عناوين صفحات يمكن أن تستخدمها Google نقطة بداية لاكتشاف محتوى الموقع والزحف إليه. بعد نجاح التحقق من ملكية الخاصية، يُفتح تقرير Sitemaps داخل Search Console، ثم يُدخل عنوان خريطة الموقع ويُرسل من هناك. يتطلب إرسالها عبر التقرير صلاحيات مالك على الخاصية.

الخطوة الأهم هنا هي الحصول على عنوان الخريطة الصحيح للمتجر. لا ينبغي افتراض أن إضافة اسم ملف خريطة شائع إلى عنوان النطاق ستعطي العنوان المناسب في كل حالة. يُستخدم عنوان الخريطة المتاح فعليًا للموقع، ويُتأكد من أنه يفتح دون خطأ ويخص النطاق الذي أُضيف إلى Search Console. وإذا ظهرت عدة خرائط أو ملف فهرس للخرائط، فيُختار العنوان الملائم للبنية الموجودة بدل تخمين مسار بديل.

عند الإرسال، من المفيد اتباع تسلسل قصير: افتح الخاصية التي تم التحقق منها، وانتقل إلى تقرير Sitemaps، وأدخل عنوان الخريطة وفق الحقل المعروض، ثم راجع حالة الإرسال في التقرير. إذا ظهر خطأ، تُراجَع صحة العنوان وإمكانية الوصول إلى الملف، ثم يُنظر في تفاصيل الخطأ بدل إعادة إدخال العنوان نفسه مرارًا.

إرسال الخريطة لا ينشئ صفحات المتجر ولا يجعلها مفهرسة تلقائيًا. وقد تكتشف Google صفحات الموقع دون خريطة، لكن إرسالها قد يساعد على اكتشافها بصورة أسرع. من هنا تأتي فائدة الخريطة بوصفها وسيلة لتعريف محرك البحث بالعناوين المتاحة، لا بوصفها بديلًا عن متابعة حالة الصفحات في الأداة.

تسلسل عملي من إضافة المتجر إلى متابعة النتيجة

تتوزع التفاصيل السابقة بين اختيار الخاصية وإثبات الملكية وإرسال الخريطة. ولتنفيذها دون خلط بين المراحل، يمكن الرجوع إلى هذا التسلسل أثناء العمل:

1. ثبّت عنوان المتجر المراد متابعته. افتح المتجر، وحدد النطاق والعنوان النهائي الظاهر، ولا سيما البروتوكول ووجود www عند التخطيط لخاصية URL-prefix.
2. أضف الخاصية المناسبة في Search Console. اختر Domain إذا كانت تغطية نسخ النطاق مطلوبة وتتوفر إدارة DNS، أو URL-prefix إذا كانت المتابعة لعنوان محدد مع طريقة تحقق يمكن تطبيقها.
3. أكمل التحقق، ولا تتجاوزه. اتبع بيانات السجل أو الملف أو الوسم التي تظهر للخاصية، ثم تأكد من ظهور نجاح التحقق. لا يمكن الاطلاع على بيانات الموقع بمجرد إضافته دون إثبات الملكية.
4. أرسل خريطة الموقع الصحيحة. بعد الدخول إلى الخاصية المتحقق منها، استخدم تقرير Sitemaps وأدخل عنوان خريطة المتجر الفعلي، ثم راجع نتيجة الإرسال.
5. عد إلى التقارير بعد الإعداد. افتح الخاصية المطابقة لعناوين المتجر وراجع ما يظهر فيها، بدل اعتبار انتهاء خطوة الإرسال نهاية المتابعة.

هذا الترتيب يوضح الاعتماد بين الخطوات: التحقق يسبق الوصول إلى بيانات الخاصية، وإرسال الخريطة يأتي بعده. وإذا تعثرت مرحلة، فمن الأنسب حلها قبل الانتقال إلى التالية. مثلًا، لا يفيد البحث عن حالة خريطة موقع داخل خاصية لم تكتمل ملكيتها بعد.

لماذا يفشل التحقق أو إرسال الخريطة؟

رسالة الفشل لا تعني بالضرورة أن عنوان المتجر غير صالح. غالبًا ما يكون المسار العملي هو مقارنة ما نُفذ بما طلبته نافذة التحقق، ثم فحص العنصر الذي تعتمد عليه الطريقة المختارة.

في التحقق عبر DNS، تبدأ المراجعة بنوع السجل واسمه وقيمته، ثم التأكد من إضافته لدى الجهة التي تدير DNS للنطاق نفسه. إذا كان السجل من نوع TXT، تساعد أداة فحص DNS على معرفة ما إذا كان ظاهرًا قبل إعادة محاولة التحقق. وقد يتطلب ظهور التغيير انتظارًا؛ لذلك لا يُستنتج وجود خطأ في البيانات من محاولة لم تنجح فور حفظها.

في التحقق عبر ملف HTML، يُفتح العنوان الذي حددته Google للملف ويُفحص ما إذا كان الملف الصحيح متاحًا فيه. المطلوب رفع الملف الفريد إلى المسار الذي تعرضه التعليمات، لا إلى أي مساحة ملفات متاحة داخل الموقع. وفي طريقة الوسم، يُراجع وجود الوسم في موضعه المطلوب على الصفحة التي يجري التحقق منها.

في مشكلة إرسال الخريطة، يُراجع عنوان الملف أولًا: هل يفتح؟ هل يعود إلى المتجر المقصود؟ وهل تُجرى المحاولة من الخاصية التي تم التحقق منها؟ كما ينبغي الانتباه إلى الصلاحيات؛ فالإرسال من تقرير Sitemaps يتطلب أن يكون الحساب مالكًا للخاصية. نجاح إضافة خاصية بعنوان آخر لا يعوض التحقق من الخاصية التي يجري العمل داخلها.

يساعد الفصل بين نوعَي الخطأ على اختصار التشخيص. ففشل الملكية يُعالَج في وسيلة إثبات التحكم بالنطاق أو الموقع، أما فشل الخريطة فيُراجع من جهة العنوان المرسل وإمكانية الوصول إليه والصلاحية المستخدمة. تغيير نوع الخاصية أو إعادة إرسال خريطة أخرى قبل تحديد موضع الخلل قد يزيد الالتباس.

لماذا لا تظهر بيانات المتجر فور إضافته؟

أول ما يُفحص هو حالة الملكية: إضافة الخاصية لا تكفي للاطلاع على بيانات الموقع، بل يجب نجاح التحقق. ثم تُراجع الخاصية المفتوحة. في URL-prefix، يهم تطابق العنوان مع النسخة المراد متابعتها، بما في ذلك HTTP أو HTTPS ووجود www؛ أما خاصية Domain فتشمل نسخ النطاق المختلفة بعد التحقق عبر DNS.

إذا اكتمل التحقق وفُتحت الخاصية الصحيحة، فقد لا تظهر بيانات مفيدة مباشرة بعد الإضافة. عدم ظهورها في اللحظة الأولى ليس بحد ذاته دليلًا على فشل الربط. والأفضل ترك وقت للبيانات، ثم العودة إلى التقارير ومراجعة العنوان والخاصية إذا استمر غياب ما يُتوقع ظهوره. ويُفصل في هذه المراجعة بين بيانات الموقع عمومًا وبين حالة صفحة معينة؛ فإضافة المتجر إلى Search Console لا تعني أن كل صفحاته ستظهر في البحث.

أين يدخل المحتوى في متابعة ظهور متجر سلة؟

يركز Search Console على ملكية الموقع وبياناته وخرائطه، بينما يتعلق إعداد المحتوى بما تنشره صفحات المتجر نفسها. بعد ضبط الخاصية، تصبح مراجعة عناوين المنتجات وأوصافها والمقالات جزءًا عمليًا من العمل على المتجر، دون الخلط بين كتابة المحتوى وخطوات التحقق التقنية.

في هذا الجانب، تقدم صدارة منصة عربية لإعداد محتوى متوافق مع محركات البحث، تشمل أوصاف المنتجات والمقالات المعلوماتية ومقالات الترشيح. تمر المادة فيها ببحث يستند إلى مصادر، ثم خطة وكتابة ومراجعة للجودة والسيو. وتُجهّز لكل قطعة محتوى الكلمة المفتاحية وعنوان Meta ووصف Meta، مع مراعاة نبرة المتجر وجمهوره المحددين في مساحة العمل.

يمكن لصاحب المتجر أو فريقه مراجعة المسودة واعتمادها قبل النشر. وتدعم المنصة نشر أوصاف المنتجات مباشرة إلى متاجر سلة بعد الاعتماد، بينما تكون المقالات بتنسيق جاهز لنقلها إلى المدونة. بهذه الصورة يبقى لكل مهمة موضعها: يُستخدم Search Console لمتابعة الموقع بعد إثبات ملكيته، ويُجهّز المحتوى الخاص بصفحات المتجر من خلال مسار تحرير ومراجعة واضح.

أسئلة شائعة

هل يلزم امتلاك حساب يدير DNS لاستخدام Search Console؟

ليس لكل أنواع الخصائص. التحقق عبر DNS مطلوب لخاصية Domain، أما خاصية URL-prefix فقد تعرض طرقًا أخرى مثل ملف HTML أو وسم HTML، وفق الخيارات المتاحة لها. المهم أن تكون طريقة التحقق المختارة قابلة للتنفيذ على الموقع.

هل يمكن رفع ملف التحقق داخل صفحة منتج؟

لا، إذا كانت تعليمات Google تطلب ملفًا متاحًا في جذر الموقع أو في مسار محدد. يجب أن يُفتح ملف التحقق الفريد من العنوان الوارد في التعليمات حتى تصل إليه Google بالطريقة المطلوبة.

هل إرسال خريطة الموقع يعني فهرسة المنتجات كلها؟

لا. الخريطة تُعرّف Google بعناوين يمكن استخدامها في اكتشاف الصفحات، وقد يساعد إرسالها على تسريع هذا الاكتشاف، لكنه لا يضمن فهرسة كل عنوان فيها.

هل يكفي التحقق من نسخة المتجر مع www لمتابعة النسخة الأخرى؟

يتوقف ذلك على نوع الخاصية. خاصية Domain تشمل نسخ النطاق بعد التحقق عبر DNS، بينما تغطي URL-prefix مقدمة العنوان المدخلة فقط. لذا تجدر مراجعة النسخ ذات الصلة عند الاعتماد على URL-prefix.

ينجح ربط سلة بسيرش كونسول عندما تتطابق الخاصية مع عنوان المتجر، وتكتمل طريقة التحقق المطلوبة، ثم تُرسل خريطة الموقع الصحيحة من الخاصية الموثّقة. وبعدها تكون المتابعة عبر التقارير، مع التمييز بين اكتشاف الصفحات وظهورها مفهرسة في البحث.