إن واجهة برمجة تطبيقات فهرسة الوظائف من Google ليست هي الاختصار الذي تعتقد أنه كذلك

أردت أن تكون واجهة برمجة تطبيقات الفهرسة من Google بمثابة رمز الغش للوحات الوظائف. وكانت المعادلة ببساطة:

وظيفة جديدة تذهب مباشرة؟ ادفعه إلى جوجل.

يتم تحديث الوظيفة؟ أخطر جوجل.

تنتهي الوظيفة؟ اطلب من Google إسقاطه.

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

لذا، عندما تقدم Google واجهة برمجة التطبيقات (API) التي تسمح لك بإخطارهم مباشرة عند إنشاء صفحات الوظائف أو تحديثها أو حذفها، فهي بالضبط الأداة التي تصل إلى الحالة “إلزامية” لأصحاب لوحات الوظائف.

وكان هذا افتراضى أيضا.

ثم أمضيت ساعات في مراجعة الوثائق، واختبار استجابات الخادم، والتحقق من حدود الحصص، ومقارنة ما تقول Google أن واجهة برمجة التطبيقات (API) تفعله مع ما يفترض معظم مُحسنات محركات البحث (SEO) أنها تفعله.

الاستنتاج؟

واجهة برمجة التطبيقات ليست عديمة الفائدة. سيكون ذلك أسهل في الواقع للكتابة عنه.

إنه أسوأ من ذلك. إنه يعمل بشكل جيد بما يكفي ليجعلك تعتقد أنك أنجزت شيئًا ما. لكن 90% منكم الذين يستخدمون هذه الأداة (بشكل قانوني أم لا) لا يحصلون على ما يعتقدون.

عرض المحتوى المضمن

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

ما الذي تفعله واجهة برمجة تطبيقات فهرسة الويب من Google بالفعل

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

تقول Google إنه لا يمكن استخدام واجهة برمجة التطبيقات إلا للصفحات التي تحتوي على بيانات JobPosting المنظمة أو صفحات البث المباشر التي تستخدم BroadcastEvent المضمن داخل VideoObject. بمعنى آخر، هذا ليس مخصصًا لمشاركات المدونة أو صفحات الفئات أو صفحات الموقع أو صفحات الخدمة أو صفحات المنتج أو أي عنوان URL آخر ترغب في أن يزحف Google إليه بشكل أسرع.

بالنسبة إلى لوحات الوظائف، توفر واجهة برمجة التطبيقات (API) إجراءين أساسيين.

يمكنك إرسال URL_UPDATED عندما تكون صفحة الوظيفة جديدة أو تم تغييرها بشكل مفيد. يمكنك إرسال URL_DELETED عندما تتم إزالة صفحة الوظيفة ويجب إسقاطها من فهرس Google.

يبدو هذا قويًا، ولكي نكون منصفين، يمكن أن يكون فعالاً إلى حد الجنون.

تكمن المشكلة في أن استجابة واجهة برمجة التطبيقات (API) الناجحة لا تعني ما يريد الكثير من الأشخاص أن تعنيه.

وهذا لا يعني أنه تم فهرسة عنوان URL. وهذا لا يعني أن عنوان URL يظهر في فهرس Google أو في تجربة وظائف Google. وهذا لا يعني أن الصفحة ستولد مرات ظهور أو نقرات أو تحويلات.

هذا يعني أن Google قد تلقت إشعارك.

هذا كل شيء.

الحصص والحدود الافتراضية لواجهة برمجة تطبيقات فهرسة الوظائف

هذا هو الجزء الذي يهم حقا.

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

إن كلمة “ربما” تقوم بالكثير من العمل.

لن. لم يفعل. لم يتم تأكيده.

“يمكن.”

وهذا هو المكان الذي يقع فيه العديد من مُحسنات محركات البحث (SEO) في المشاكل.

تبدو الاستجابة الناجحة لواجهة برمجة التطبيقات (API) وكأنها تقدم لأنه من السهل قياس الإجراءات الفنية. تم إرسال الطلب. كانت استجابة الخادم نظيفة. تم تشغيل البرنامج النصي بدون أخطاء. تُظهر استجابة JSON أن Google تلقت الإشعار.

عظيم.

ولكن المقدمة لم تتم فهرستها. لم يتم الزحف إلى المستلمة. لم يتم تصنيف الزحف إليها. لم يتم النقر على المرتبة. النقر عليه ليس تحويلاً تزايديًا.

لقد فهمت النقطة.

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

تمنحك واجهة برمجة التطبيقات (API) تأكيدًا للإشعار.

لا يعطيك تأكيد الفهرسة.

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

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

في الواقع، لا يهم.

نحن جميعا نعرف الجواب.

النجمة التي تثبت أنك تضيع وقتك.

يمكنك تكوين واجهة برمجة التطبيقات (API) بشكل صحيح. يمكنك إرسال الحمولة الصحيحة. يمكنك الحصول على استجابة ناجحة. يمكنك تخزين البيانات التعريفية للإشعارات. يمكنك أيضًا عرض السجلات التي تثبت عمل نظامك.

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

نقدم لك getMetadata ولماذا لم تخدع Google لفهرسة رسائلك غير المرغوب فيها بعد كل شيء

أحد الأجزاء الأكثر تضليلًا في واجهة برمجة التطبيقات (API) هو القدرة على التحقق من حالة إشعار URL.

للوهلة الأولى، يبدو أن هذا يجيب على السؤال الكبير.

هل قام Google بفهرسة عنوان URL هذا؟ لا.

إن استجابة JSON الأولية هذه هي كل ما تحتاجه لفهم ما يحدث. لسوء الحظ، هذه ليست المعلومات التي يريدها معظم الناس بالفعل.

“واجهة برمجة التطبيقات المقبولة” و”المفهرسة” ليسا متماثلين.

أخبرني المزيد عن getMetadata وGoogle Sandbox

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

هذا لا يعني أن getMetadata عديمة الفائدة.

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

هل تحصل على خطأ 404 في طلب getMetadata الخاص بك، مثلي؟

أنت ترسل الرسالة عبر البريد، لكن المستلم قام بإزالة صندوق البريد من منزله. ما لم تتم الموافقة على واجهة برمجة التطبيقات (API) الخاصة بك للاستخدام الحقيقي، فأنت تعمل بالكامل ضمن وضع الحماية الخاص بـ Google، بغض النظر عما إذا كانت شاشة الحصص تظهر أن لديك مساحة لإرسال المزيد من الطلبات.

وبصراحة، هل يمكنك أن تتخيل عدد طلبات البريد العشوائي التي تلقتها Google من خلال واجهة برمجة التطبيقات هذه؟

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

تهاني. لقد حصلت على إيصال للوقت الضائع.

لكن لا تقلق. تقول Google إنه يمكن إرسال عناوين URL الشرعية لنشر الوظائف بمجرد ملء نموذج الطلب، والذي ستتم مراجعته في المتوسط ​​خلال 2-3 أسابيع.

ها!!!

عملية الموافقة وزيادة الحصص

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

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

على الأقل، هذه هي الطريقة التي كانت تعمل بها.

قبل بضع سنوات، عندما كنت أعمل مع مجلس التوظيف الذي يضم ملايين الوظائف، أصبحت من أفضل الأصدقاء لهذا النموذج. لقد أرسلت طلبات الحصص، وأظهرت أن الحصة الحالية يتم استهلاكها من خلال عناوين URL الشرعية للوظائف، وفي غضون 2-3 أسابيع، ستقوم Google بزيادة الحصة.

كانت تلك تجربتي، وقد نجحت.

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

ثم أدى شيء إلى آخر، وقمت بحركة أحمق أدت إلى حذف واجهة برمجة التطبيقات الخاصة بي. (Booooo! عار علي!)

لذلك قمت بإعداد كل شيء مرة أخرى. هذه المرة، قدمت طلبات لكل من SEOJobs.com وPPCJobs.com.

كان ذلك قبل ستة أشهر. نعم. لا يوجد رد في عام 2026 على الإطلاق.

ليست موافقة. ليس الرفض. ليس طلبا لمزيد من المعلومات.

ببساطة لا شيء.

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

أخبرني أنه لم يتلق أي رد من مجالس العمل التي عمل معها على مدى 10 إلى 12 شهرًا تقريبًا بعد تقديم نفس النموذج.

لا يتم تجاهل هذا الموقع العشوائي.

جوجل، حان دورك الآن

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

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

هل يمكنني التأكد من أن الرقم صفر؟ لا.

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

وهذا هو الجزء المحبط. إذا كانت الإجابة لا، فلا بأس (سأضع القليل في الزاوية).

إذا تم تأمين واجهة برمجة التطبيقات (API) بشكل فعال لزيادة الحصص الجديدة، فلا بأس بذلك أيضًا.

إذا لم تعد Google ترغب في توسيع نطاق الوصول بسبب إساءة استخدام واجهة برمجة التطبيقات (API) إلى درجة الإرهاق، فأنا أتفهم ذلك أيضًا.

ولكن بعد ذلك قل ذلك.

لا تترك النموذج كما لو أنه لا تزال هناك عملية مراجعة فعالة.

لا تطلب من مجالس العمل الشرعية أن تطلب المزيد من الوصول إذا لم يقم أحد بمراجعة الطلبات.

لا تدع الناس يقضون شهورًا في انتظار الرد الذي قد لا يأتي أبدًا.

جوجل لا تدين لنا باختصار الفهرسة.

ولكن إذا كان الباب الأمامي مغلقًا، فيرجى التوقف عن ترك سجادة الترحيب بالخارج.

أداة مجانية لفهرسة الوظائف لتحديد ما إذا كنت تحصل على الخدمة بالفعل

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

يمكنك الآن معرفة في دقائق ما إذا كان يعمل بالطريقة التي توقعتها.

يتوفر الآن فحص صحة فهرسة الوظائف على موقع SEOJobs.com

ويقدم مستويين من الخدمة (كلاهما مجاني).

تأكد من ترميز عنوان URL الخاص بك بشكل صحيح باستخدام مخطط الوظيفة وأنه يبدو أنه صفحة إعلان وظيفة مدعومة.

يقوم “الفحص الكامل” بتحليل مخطط وظيفتك واستجابات واجهة برمجة التطبيقات (API) واستجابات Google Search Console.

كل النتائج مهمة، ولا توجد أي عقبات فنية يجب تجاوزها.

ستبدو النتائج الكاملة بعد تشغيل هذا التقرير هكذا تمامًا (ولكن نأمل أن تحصل على 200 استجابة للبيانات الوصفية!) مثال عبر بيانات اعتماد SEOjobs API وGSC وعنوان URL لقائمة الوظائف.

تتوفر أيضًا استجابة JSON الأولية الكاملة في الأسفل.

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

ظهرت هذه المقالة لأول مرة على موقع المؤلف وأعيد نشرها هنا بإذن.