كيف تنقل موقعًا قديمًا إلى موقع جديد دون فقدان الفهرسة؟ قائمة تجنب الأخطاء في تطوير المواقع

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

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

فيما يلي شرح حسب ترتيب المشروع الفعلي، بلغة مبسطة قدر الإمكان.

أولًا: حدد قواعد URL قبل تعديل الكود

أكثر ما يسبب مشاكل في النقل هو URL. إذا كان الموقع القديم يستخدم `/product/123.html` وأصبح الموقع الجديد `/product?id=123`، أو تم تغيير أسماء الأقسام بالكامل، فستتعامل محركات البحث معها كمجموعة صفحات جديدة وتعيد التعرف عليها.

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

نقطة تجنب الخطأ: لا تعد كتابة جميع عناوين URL من جديد فقط من أجل «مظهر مرتب». الترتيب للناس، والفهرسة للزاحفات، وعند التعارض تكون الأولوية للفهرسة.

ثانيًا: نفذ إعادة التوجيه 301 بالكامل، لا للصفحة الرئيسية فقط

إعادة التوجيه 301 هي نقطة الحسم في النقل. من الأخطاء الشائعة توجيه الصفحة الرئيسية فقط، بينما تصبح جميع الصفحات الداخلية 404.

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

هناك تفصيل آخر: يجب ألا تتجاوز سلسلة إعادة التوجيه مستوى واحدًا. A إلى B ثم B إلى C يسهل انقطاع الزاحف. اجعل التقنيين أثناء تطوير الموقع يضبطونها مباشرة من A إلى C.

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

ثالثًا: لا تعيد كتابة المحتوى للموقع كاملًا، ابدأ بالربط

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

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

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

رابعًا: إيقاع الإطلاق: تحقق أولًا بحركة مرور صغيرة ثم انتقل بالكامل

لا يُنصح بالنقل دفعة واحدة.

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

هناك ثلاث نقاط لتجنب الأخطاء:

- لا تحجب robots.txt بالخطأ: بيئة الاختبار غالبًا تحتوي `Disallow: /`، وينسى الفريق حذفها عند الإطلاق فلا يستطيع الزاحف الوصول للموقع كله.

- لا تجعل canonical يشير إلى النطاق القديم: يحدث ذلك بسهولة عند نسخ القوالب.

- لا تضع الصفحة الرئيسية فقط في خريطة الموقع: يجب أن تشمل الأقسام الرئيسية وصفحات المحتوى.

خامسًا: التطبيقات المصغرة وApp ليست بديلًا، لا تخلط بينها في النقل

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

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

متى يكون من المناسب التعاون مع MIC Studio

إذا كنت تواجه إحدى هذه الحالات، يمكنك التفكير في فريق خارجي:

- هيكل الموقع القديم غير منظم، ولا أحد يستطيع تحديد الصفحات التي تجلب زيارات، وتحتاج إلى ترتيب قبل النقل؛

- لا يوجد داخل الشركة مطورون متخصصون للواجهة والخلفية، ومدة تطوير الموقع ضيقة؛

- ظهر انخفاض في الفهرسة بعد النقل، وتحتاج إلى فحص مشاكل إعادة التوجيه والفهرسة؛

- تحتاج في الوقت نفسه إلى موقع مؤسسي أو تطوير تطبيقات مصغرة أو تطوير App، وتريد توحيد المحتوى والنهج التقني.

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

ثلاث توصيات قابلة للتنفيذ

1. صدّر قائمة عناوين URL القديمة قبل الإطلاق، وأكد لكل عنوان ما إذا كان يبقى أو يعاد توجيهه، وشكّل جدولًا وسلمه للتطوير.

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

3. حافظ على محتوى الصفحات الأساسية أولًا ثم عدّل النصوص، وبعد استقرار الإطلاق بأسبوعين ابدأ تحسين الكلمات المفتاحية.

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