10 مشكلات فنية شائعة لتحسين محركات البحث - وكيفية اكتشافها

بعد تنفيذك لخدمات تحسين محركات البحث (SEO) عبر مجموعة من الصناعات ، يمكنك أحيانًا التعرف على المشكلات الشائعة خاصة عند العمل على نظام إدارة محتوى مشترك مثل WordPress أو Shopify أو SquareSpace.

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

1 - ملف Robots.txt يحظر الوصول إلى Googlebot

هذا ليس بالأمر الجديد بالنسبة لمعظم مُحسّنات محرّكات البحث التقنية ، لكن لا يزال من السهل جدًا إهمال فحص ملف الروبوتات - وليس فقط عند إجراء تدقيق فني ، ولكن كتحقق متكرر.

يمكنك استخدام أداة مثل Search Console (الإصدار القديم) لمراجعة ما إذا كان لدى Google مشاكل في الوصول ، أو يمكنك فقط محاولة الزحف إلى موقعك مثل Googlebot باستخدام أداة مثل OnCrawl (فقط حدد وكيل المستخدم الخاص به). سوف يلتزم OnCrawl بملف robots.txt ما لم تقل خلاف ذلك.

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

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

إن النظر إلى ملف الروبوتات الخاص بهم (ومحاولة الزحف لاحقًا إلى صفحتهم من OnCrawl مثل Googlebot) أكد شكوكي بأنهم كانوا يحظرون الوصول إلى موقعهم.
يتم عرض ملف robots.txt المذنب أدناه:

لقد تواصلت معهم من خلال "لمعلوماتك" ولكن لم أحصل على رد ، ولكن بعد بضعة أيام رأيت أن كل شيء قد عاد إلى طبيعته. Phew - يمكنني النوم بسهولة مرة أخرى!

في حالتهم ، يبدو أنه كلما قمت بفحص موقعك كجزء من تدقيق السرعة ، كان يُنشئ عنوان URL يتضمن ذلك الحرف المجزأ المميز في ملف الروبوتات أعلاه.

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

تجدر الإشارة إلى أنه في بعض الحالات يمكنك الوصول إلى تغييرات ملف robots.txt التاريخية باستخدام Internet Wayback Machine. من واقع خبرتي ، يعمل هذا بشكل أفضل على المواقع الأكبر كما يمكنك أن تتخيل - يتم الزحف إليها في كثير من الأحيان بواسطة أرشيفي Wayback Machine.

إنها ليست المرة الأولى التي أرى فيها ملف robots.txt مباشرًا في البرية مما تسبب في بعض الفوضى في SERPS. وبالتأكيد لن يكون الأخير - إنه أمر بسيط يجب إهماله (إنه ملف واحد حرفيًا بعد كل شيء) ولكن التحقق منه يجب أن يكون جزءًا من جدول العمل المستمر لكل مُحسنات محركات البحث.

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

Disallow المميز: / في هذه الحالة منع الوصول إلى أي مسارات URL ؛ كان من الأفضل وضع قائمة بأقسام معينة من الموقع لا ينبغي الزحف إليها بدلاً من ذلك.

2 - مشاكل تكوين المجال على مستوى DNS

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

غالبًا مع تطبيقات SSL ، أخفق في رؤية إصدار المجال غير التابع لـ WWW تم تكوينه بشكل صحيح ، مثل إعادة التوجيه 302 إلى عنوان URL التالي وتشكيل سلسلة ، أو عدم تحميل سيناريو أسوأ الحالات على الإطلاق.

وخير مثال على ذلك هو موقع Hotel Football على الويب.

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

لقد لاحظت هذا منذ فترة لأنني عملت كثيرًا في صناعة السفر والضيافة - ومع شغف كبير بكرة القدم كنت مهتمًا برؤية شكل موقع الويب الخاص بهم (بالإضافة إلى كيف كان يعمل بشكل طبيعي بالطبع! ).

كان هذا في الواقع سهل التشخيص - كان للموقع الكثير من الروابط الخلفية الجيدة للغاية ، وكلها تشير إلى نطاق WWW غير SSL على http://www.hotelfootball.com/

إذا حاولت الوصول إلى عنوان URL أعلاه ، فلن يتم تحميله. أُووبس. وكان الأمر هكذا لمدة 18 شهرًا على الأقل حتى الآن. لقد تواصلت مع الوكالة التي تدير الموقع عبر Twitter لإخبارهم بذلك ولكن لم أحصل على رد.

باستخدام هذا ، كل ما يحتاجون إليه هو التأكد من صحة إعدادات منطقة DNS ، مع وجود سجل "A" في مكانه لإصدار "WWW" من المجال ، والذي يشير إلى عنوان IP الصحيح (سيعمل CNAME أيضًا). هذا سيمنع المجال من عدم حل.

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

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

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

لقد سجلوا هدفًا خاصًا مع ما سبق - ولكن إصلاح هذه المشكلة قد يقطع شوطا ما على الأقل في حل ذلك.

زاحف Oncrawl SEO

زاحف تحسين محركات البحث (SEO) لعمليات تدقيق المؤسسات والمراقبة اليومية. قم بزيادة حركة المرور العضوية وإيرادات الموقع ببيانات موثوقة.

يتعلم أكثر

3 - الصفحات المارقة داخل خريطة موقع XML

مرة أخرى ، يعد هذا أمرًا أساسيًا جدًا ولكنه شائع بشكل غريب - عند مراجعة خريطة موقع XML للمواقع (والتي تكون دائمًا تقريبًا إما في domain.com/sitemap.xml أو domain.com/sitemap_index.xml ، قد تكون هناك صفحات مدرجة هنا لا لا حاجة للفهرسة.

من بين الجناة النموذجيين صفحات الشكر المخفية (شكرًا لإرسال نموذج الاتصال) ، أو صفحات PPC المقصودة التي قد تتسبب في حدوث مشكلات محتوى مكررة ، أو أشكال أخرى من الصفحات / المنشورات / التصنيفات التي لم تقم بفهرستها بالفعل في مكان آخر.

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

يمكنك الآن استخدام التقرير المفيد داخل Search Console لمعرفة ما إذا كانت الصفحات قد تم تضمينها أو لم يتم تضمينها في خريطة موقع XML للمواقع عبر خيار فحص عنوان URL.

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

غالبًا ما يمكنك التقاط هذا النوع من المحتوى ذي الجودة المنخفضة والذي لا يقدر بثمن عن طريق إجراء بحث على موقع site: domain.com في Google لإرجاع كل ما تم فهرسته.

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

4 - المشكلات المتعلقة بعرض Googlebot للمحتوى الخاص بك

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

لقد قيل الكثير عن هذا (وعن JavaScript) بالفعل من قبل بعض مُحسنات محركات البحث (SEO) القادرة جدًا ، لذا لن أتعمق في هذا الأمر ، لكن التحقق من كيفية عرض Googlebot لموقعك سيكون دائمًا يستحق وقتك.

يمكن أن يساعد إجراء بعض الفحوصات عبر أدوات عبر الإنترنت في الكشف عن النقاط المحجوبة لـ Googlebot (مناطق على الموقع لا يمكنهم الوصول إليها) ، والمشكلات المتعلقة ببيئة الاستضافة الخاصة بك ، ومشكلات حرق JavaScript للموارد ، وحتى مشاكل تحجيم الشاشة.

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

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

من خلال النقر فوق علامة التبويب "مزيد من المعلومات" (أعلى اليمين) ، فإنها توفر قائمة بالموارد التي لا يمكن الوصول إليها بعد ذلك بواسطة Googlebot والتي تتكون أساسًا من ملفات CSS وملفات الصور.

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

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

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

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

يمكن أن تكون هذه الرسائل المتضاربة من Google خادعة لمطوري الويب ومُحسنات محركات البحث لفك تشفيرها. لفهم المزيد ، تواصلت مع John Mueller الذي اقترح أن أتحقق من مضيف الويب الخاص بي (لا توجد مشكلات) وأن ملف CSS يمكن بالفعل تخزينه مؤقتًا بواسطة Google.

تستخدم Search Console خدمة عرض ويب أقدم (WRS) مقارنة بأداة Mobile-Friendly Tool ، لذلك أميل في الوقت الحاضر إلى إعطاء ترجيح أكبر للأخيرة.

مع إعلان Google عن أحدث برنامج Googlebot مع أحدث إمكانات العرض ، يمكن تعيين كل هذا للتغيير ، لذا من المفيد مواكبة الأدوات الأفضل لاستخدامها في عرض الشيكات.

نصيحة أخرى هنا - إذا كنت ترغب في رؤية عرض كامل قابل للتمرير لصفحة ما ، يمكنك التبديل إلى علامة التبويب HTML من أداة اختبار الهاتف المحمول من Google ، واضغط على CTRL + A لتمييز جميع تعليمات HTML البرمجية المعروضة ، ثم نسخها ولصقها في محرر نصي و حفظ كملف HTML.

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

5 - المواقع التي تم الاستيلاء عليها والروابط الخلفية غير المرغوب فيها

يعد هذا أمرًا ممتعًا للغاية ويمكنه غالبًا التسلل إلى المواقع التي تعمل على إصدارات أقدم من WordPress أو أنظمة CMS الأخرى التي تتطلب تحديثات أمنية منتظمة.

مع هذا العميل (منتجع تجميل) ، لاحظت ظهور بعض مصطلحات البحث الغريبة داخل Search Console.

والمثير للدهشة أنه ليس لديهم مرات ظهور داخل Search Console فحسب ، بل نقرات أيضًا - مما يعني أنه يجب فهرسة شيء ما على النطاق.

بناءً على الاستفسارات ، من الواضح أنه كان بريدًا عشوائيًا للغاية ، وليس شيئًا يريد العميل ربط أعماله به.

أدى إجراء بحث بسيط عن "site: domain.com" في Google إلى اكتشاف مئات الصفحات من التورنت المفترض الذي كان من المفترض أن يستضيفه العميل على موقعه.

أدت زيارة أي من عناوين URL هذه في الواقع إلى 404 - ومع ذلك كانت لا تزال مفهرسة (لقد تحققت أيضًا من العديد من وكلاء المستخدمين وحصلوا جميعًا على نفس الخطأ 404).

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

أظهر النظر إلى سحابة المرساة من Majestic للروابط الخلفية مدى المشكلة حقًا.

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

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

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

6 - إعدادات سيو دولية سيئة

نظرًا لكوني مقيمًا في إسبانيا ولكني أتصفح الإنترنت بلغتي الإنجليزية الأم ، فغالبًا ما أجد نفسي يتم إعادة توجيهي تلقائيًا إلى إصدار أسباني من أحد مواقع الويب.
بينما أفهم المنطق (أنا مقيم في إسبانيا ، لذلك أريد أن أتصفح الموقع باللغة الإسبانية) ، إنه أمر مزعج جدًا من منظور تجربة المستخدم ، وإذا لم يتم القيام به بشكل صحيح ، فقد يتسبب أيضًا في بعض الفوضى في مُحسّنات محرّكات البحث الدولية.
تنتقل مواقع مثل إعلانات Google بهذا إلى مستوى آخر - باستخدام Angular JavaScript لإنشاء محتوى ديناميكيًا بناءً على موقعي ، ولا حتى المرور عبر إعادة توجيه الصفحة من أي نوع وتحميل المحتوى مباشرةً في DOM.

الطريقة المفضلة في الاختيار عند توفر لغات متعددة هي 302 إعادة توجيه المستخدم إلى لغة بناءً على إعدادات متصفح الإنترنت.
لذلك ، إذا كان شخص ما يستخدم اللغة الألمانية كلغته الافتراضية في Google Chrome ، فمن المحتمل أن يكون مرتاحًا لقراءة الموقع باللغة الألمانية بغض النظر عن موقعه الفعلي.
يساعد هذا أيضًا في التغلب على الصعوبات عندما يكون شخص ما مقيمًا في منطقة يتم التحدث بها بلغات مختلفة كما هو الحال في سويسرا حيث تُستخدم الفرنسية والإيطالية والألمانية والرومانشية.
إنه أيضًا مفتاح لأغراض الاستخدام لضمان وجود خيار للتبديل بين اللغات بناءً على تفضيلاتك - فقط في حالة رغبتهم في التبديل.
في إحدى الحالات ، عملت مع فندق مقره في برشلونة ، حيث تمت إضافة برنامج نصي لإعادة توجيه لغة JavaScript إلى موقع دون مراعاة تأثير تحسين محركات البحث.
أعاد هذا النص البرمجي توجيه المستخدمين بناءً على إعداد لغة المتصفح (وهو ليس سيئًا للغاية في حد ذاته) عبر إعادة توجيه JavaScript من جانب العميل.
للأسف في هذه الحالة ، لم يتم إعداد البرنامج النصي بشكل صحيح بسبب التكوين الغريب للروابط الثابتة للمواقع ، وعندما يتم دمجها مع حقيقة أن علامة HTML lang كانت مفقودة من جميع الصفحات على الموقع ، فقد أصبح Googlebot قليلاً ...

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

كان Googlebot يحاول الزحف إلى المحتوى الإسباني (الموجود على hotelname.com/ofertas) وتمت إعادة توجيهه إلى hotelname.com/en/ofertas - عنوان URL غير موجود.
من المثير للدهشة في هذه الحالة أن Googlebot كان يتابع كل عمليات إعادة توجيه JavaScript هذه ، ولأنه لم يتمكن من العثور على عناوين URL هذه ، فقد اضطر لإسقاطها من فهرسها.
في الحالة المذكورة أعلاه ، تمكنت من تأكيد ذلك من خلال الوصول إلى سجلات الخادم الخاصة بالموقع ، والتصفية إلى Googlebot والتحقق من المكان الذي تم تقديم 404 فيه.
أدت إزالة البرنامج النصي لإعادة توجيه JavaScript الخاطئ إلى حل المشكلة ، ولحسن الحظ لم يتم إلغاء فهرسة الصفحات المترجمة لفترة طويلة.
من الجيد دائمًا اختبار الأشياء بالكامل - يمكن أن يساعد الاستثمار في VPN في تشخيص هذه الأنواع من السيناريوهات ، أو حتى تغيير موقعك و / أو لغتك داخل متصفح Chrome.

[دراسة حالة] التعامل مع عمليات تدقيق متعددة للمواقع

في غضون أسابيع قليلة ، ساعد استخدام OnCrawl Evergreen Media في تحقيق مكاسب سريعة لتحسين محركات البحث فيما يتعلق بالمقتطفات المميزة من Google ، وتحسين المقتطفات ، وتحسينات التصنيف لتحويل الصفحات ، وأخطاء 404 ... اكتشف كيف يمكن لـ OnCrawl أن يسهل سير عمل أي وكالة لتحسين محركات البحث عندما يتعلق الأمر بتدقيق تحسين محركات البحث .

اقرأ دراسة الحالة

7 - محتوى مكرر

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

عند استيراد محتوى من WordPress إلى Medium ، أثناء هذه العملية ، سيستخدم Medium عنوان URL لموقع الويب الخاص بك باعتباره علامة أساسية. لذلك من الناحية النظرية ، من المفترض أن تساعد في منح موقع الويب الخاص بك الفضل في المحتوى ، باعتباره المصدر الأصلي.

من بعض تحليلي على الرغم من أنه لا يعمل دائمًا على هذا النحو.
أعتقد أن هذا هو الحال لأنه عندما يتم نشر مقال على Medium دون السماح لـ Google أولاً بالزحف إلى المقالة وفهرستها على نطاقك ، إذا تم نشر المقالة بشكل جيد على Medium (وهو أمر ناجح أو مفقود) يحصل المحتوى الخاص بك مفهرسة ومرتبطة بموقع Medium على الرغم من توجيهها الأساسي إلى موقعك.
بمجرد إضافة المحتوى إلى Medium (وخاصة إذا كان شائعًا) ، يمكنك ضمان أن القطعة سيتم كشطها وإعادة نشرها على الويب في مكان آخر على الفور تقريبًا - لذلك مرة أخرى يتم تكرار المحتوى الخاص بك في مكان آخر.
في حين أن كل هذا يحدث ، فمن المحتمل أنه إذا كان نطاقك صغيرًا جدًا من حيث الصلاحية ، فقد لا تتاح لـ Google فرصة الزحف إلى المحتوى الذي نشرته وفهرسته - وقد يكون الأمر كذلك أن عنصر العرض في الزحف / الفهرس لم يكتمل بعد ، أو أن هناك ثقيلة في جافا سكريبت تسبب فجوة زمنية كبيرة بين الزحف والعرض والفهرسة لهذا المحتوى.
لقد رأيت مواقف تنشر فيها شركة كبيرة مقالًا رائعًا ، ولكن في اليوم التالي تنشره كمقال على مدونة أخبار صناعية ضخمة. علاوة على ذلك ، واجه موقعهم مشكلة حيث تم تكرار المحتوى (وفهرسته) على https://domain.com و https://www.domain.com.
بعد أيام قليلة من النشر ، عند البحث عن عبارة محددة للمقالة في علامات الاقتباس داخل Google ، لم يكن موقع الشركة على الويب يمكن رؤيته في أي مكان. بدلاً من ذلك ، كانت مدونة الصناعة الموثوقة في المقام الأول ، وكان ناشرون آخرون يتولون المناصب التالية.
في هذه الحالة ، تم ربط المحتوى بمدونة الصناعة ، وبالتالي فإن أي روابط تحقق مكاسب القطعة ستستفيد من هذا الموقع - وليس الناشر الأصلي.
إذا كنت ستعمل على إعادة توجيه المحتوى في أي مكان على الويب ، فمن المحتمل أن تتم فهرسته ، فعليك حقًا الانتظار حتى تتأكد تمامًا من فهرسته بواسطة Google على نطاقك الخاص.
ربما تعمل بجد لإنشاء المحتوى الخاص بك وصنعه - لا تتخلص من كل ذلك من خلال حرصك الشديد على إعادة النشر في مكان آخر!

8 - تهيئة سيئة لصفحات AMP (بيان عنوان URL لصفحات AMP مفقود)

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

بدون إخبار محركات البحث بوجود صفحة AMP في عنوان URL معين ، فليس هناك فائدة كبيرة من وجود إعداد AMP على الإطلاق - النقطة المهمة هي أنه يتم فهرستها وإعادتها في SERPS لمستخدمي الأجهزة المحمولة.

تعد إضافة المرجع إلى صفحتك التي ليست بتنسيق AMP طريقة مهمة لإخبار Google عن صفحة AMP ، ومن المهم أن تتذكر أن العلامات الأساسية على صفحات AMP لا يجب أن تكون مرجعية ذاتية: فهي ترتبط مرة أخرى بالصفحة التي ليست بتنسيق AMP.
وعلى الرغم من أنه لا يعتبر حقًا اعتبارًا تقنيًا لتحسين محركات البحث ، إلا أنه من الجدير بالذكر أنك لا تزال بحاجة إلى تضمين شفرة التتبع على صفحات AMP إذا كنت تريد أن تكون قادرًا على الإبلاغ عن أي معلومات عن حركة المرور وسلوك المستخدم.
عادةً كجزء من عمليات تدقيق مُحسّنات محرّكات البحث (SEO) الخاصة بي ، أود إجراء بعض الفحوصات الأساسية لتطبيق التحليلات أيضًا - وإلا فقد لا تكون البيانات التي قدمتها مفيدة في الواقع ، خاصةً إذا كان هناك إعداد تحليلات غير صحيح.

9 - المجالات القديمة التي يقوم 302 بإعادة التوجيه أو تشكيل سلسلة من عمليات إعادة التوجيه

عند العمل مع علامة تجارية فندقية مستقلة كبيرة في الولايات المتحدة ، والتي خضعت للعديد من إعادة العلامات التجارية على مدار السنوات القليلة الماضية (شائعة جدًا في صناعة الضيافة) ، من المهم مراقبة سلوك طلبات اسم النطاق السابقة.
من السهل نسيان هذا الأمر ، لكنه قد يكون مجرد فحص شبه منتظم لمحاولة الزحف إلى موقعهم القديم باستخدام أداة مثل OnCrawl ، أو حتى موقع طرف ثالث يتحقق من رموز الحالة وعمليات إعادة التوجيه.
في كثير من الأحيان ، ستجد النطاق 302 يعيد التوجيه إلى الوجهة النهائية (دائمًا ما يكون 301 هو أفضل رهان هنا) أو 302 إلى إصدار غير WWW من عنوان URL قبل القفز عبر العديد من عمليات إعادة التوجيه قبل النقر على رابط عنوان URL النهائي.
صرح جون مولر من Google من قبل أنهم لا يتبعون سوى 5 عمليات إعادة توجيه قبل الاستسلام ، في حين أنه من المعروف أيضًا أنه بالنسبة لكل عملية إعادة توجيه يتم تمريرها ، يتم فقد بعض قيمة الارتباط. لهذه الأسباب أفضل التمسك بعمليات إعادة التوجيه 301 التي تكون نظيفة قدر الإمكان.
يعد Redirect Path by Ayima امتدادًا رائعًا لمتصفح Chrome يعرض لك حالات إعادة التوجيه أثناء تصفحك للويب.

هناك طريقة أخرى اكتشفت بها أسماء نطاقات قديمة تخص أحد العملاء وهي البحث على Google عن رقم هاتفه ، أو باستخدام اقتباسات مطابقة تامة ، أو أجزاء من عنوانه.
غالبًا ما لا يغير نشاط تجاري مثل فندق العنوان (على الأقل جزء منه على أي حال) وقد تجد أدلة / ملفات تعريف تجارية قديمة مرتبطة بنطاق قديم.
قد يؤدي استخدام أداة backlink مثل Majestic أو Ahrefs أيضًا إلى إظهار بعض الروابط القديمة من المجالات السابقة ، لذلك يعد هذا منفذًا جيدًا للاتصال أيضًا - خاصةً إذا لم تكن على اتصال بالعميل مباشرةً.

10- سوء التعامل مع محتوى البحث الداخلي

هذا في الواقع موضوع كتبته من قبل هنا في OnCrawl - لكني أدرجه مرة أخرى لأنني ما زلت أرى محتوى داخليًا إشكاليًا يحدث "في البرية" كثيرًا.
لقد بدأت هذه المقالة بالحديث عن مشكلة توجيه ملف robots.txt في Pingdom والتي بدت من الخارج أنها حل لمنع المحتوى الذي كانوا ينتجهون من الزحف إليه وفهرسته.
يحتاج أي موقع يقدم نتائج بحث داخلية إلى Google كمحتوى ، أو ينتج عنه الكثير من المحتوى الذي ينشئه المستخدمون ، إلى توخي الحذر الشديد بشأن الطريقة التي يفعلون بها ذلك.
إذا كان أحد المواقع يقدم نتائج بحث داخلية إلى Google بطريقة مباشرة جدًا ، فقد يؤدي ذلك إلى عقوبة يدوية من نوع ما. من المحتمل أن ترى Google ذلك كتجربة سيئة للمستخدم - فهم يبحثون عن X ، ثم يهبطون على موقع حيث يتعين عليهم بعد ذلك تصفية ما يريدون يدويًا.
في بعض الحالات ، أعتقد أنه من الجيد تقديم محتوى داخلي ، فالأمر يعتمد فقط على السياق والظروف. قد يرغب موقع العمل على سبيل المثال في تقديم أحدث نتائج الوظائف التي يتم تحديثها يوميًا تقريبًا - لذلك يتعين عليهم تقريبًا التعامل مع هذا الأمر.
يعد في الواقع مثالًا مشهورًا لموقع عمل قد يأخذ هذا الأمر بعيدًا جدًا ، حيث ينشئ كل أنواع المحتوى بناءً على استفسارات البحث الشائعة (انظر فقط أدناه لمعرفة ما يمكن أن يحدث إذا استخدمت هذا التكتيك).

على الرغم من ذلك ، وفقًا لبيانات SEMRush ، فإن حركة المرور العضوية الخاصة بهم تعمل بشكل رائع - ولكن هذه خطوط رفيعة ، والتصرف بهذه الطريقة يعرضك لخطر كبير من عقوبة Google.

تاجر التجزئة على الإنترنت Wayfair.com هي علامة تجارية أخرى تحب الإبحار بالقرب من الريح. من خلال الملايين من عناوين URL المفهرسة (والكثير من عناوين URL للكلمات الرئيسية التي تم إنشاؤها تلقائيًا) ، فإنهم يقومون بعمل رائع من حيث حركة المرور العضوية - لكنهم معرضون بشكل كبير لخطر التعرض للعقاب على تقديم المحتوى بهذه الطريقة إلى محركات البحث.

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

تغليف

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