دراسة حالة لإعادة تصميم موقع: شركة النقل في ميازاكي Douzu Carry Service — ما الذي نقلناه من الموقع القديم، وكيف

أكثر ما يُخشى في إعادة تصميم موقع هو أن يتجدد المظهر بينما ينهار ترتيب البحث ومسار التواصل بهدوء. نتناول هذه المرة مشروع إعادة تصميم شركة النقل «Douzu Carry Service» في ميازاكي مثالًا، لنستعرض ما ثبّتناه قبل الشروع في التصميم.

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

يتناول هذا المقال إعادة تصميم «Douzu Carry Service»، شركة النقل في ميازاكي المتخصصة في النقل الفردي والتوصيل لمسافات طويلة والنقل المبرَّد/المجمَّد، مثالًا، ويلخّص الخطوات الفعلية التي اتّبعناها. يتوفر ملخص موجز في الحالة التي تلخّص هيكل Douzu Carry Service، لكن هذا المقال يتعمق أكثر في التفاصيل.

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

1. نظرة عامة على المشروع — قبل / بعد

لنبدأ بالصورة الشاملة.

حافظت الصفحات الثابتة الرئيسية — الصفحة الرئيسية، قائمة الخدمات، النقل، النقل المبرَّد/المجمَّد، التوصيل في اليوم نفسه، الانتقال إلى مرافق كبار السن، الأسعار، معلومات الشركة، الأسئلة الشائعة، والتواصل — إلى جانب صفحات المناطق التسع الخاصة بميازاكي وميّاكونوجو ونوبيوكا ونيتشينان وكوباياشي وهيوغا وسايتو وكوشيما وإيبينو، على عناوين URL دون تغيير طوال عملية إعادة التصميم. ما تغيّر بشكل رئيسي هو كيفية التعامل مع عناوين URL عديمة المعنى في المدونة القديمة، وسكربت متبقٍّ غير مستخدَم.

علاوة على ذلك، بُني تصميم الموقع الجديد استنادًا إلى نظام التصميم الذي نشرته وكالة اليابان الرقمية (Digital Agency). سمح تخطي مرحلة تصميم واجهة من الصفر بتوجيه الجهد الموفَّر نحو أعمال تصميم عناوين URL ونقل المحتوى التي يتناولها هذا المقال. المنطق وراء هذا النهج مفصَّل في مقال «لماذا تبني KomuraSoft المواقع باستخدام نظام تصميم وكالة اليابان الرقمية — يمكن للتكلفة المنخفضة والجودة العالية أن تتعايشا» (المقال متاح باليابانية والإنجليزية وعدد من اللغات الأخرى، ولا تتوفر له حاليًا ترجمة عربية).

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

2. الخطوة الأولى لم تكن التصميم، بل جرد عناوين URL

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

وعلى وجه التحديد، صنّفنا العناصر التالية تصنيفًا شاملاً لا يفوت شيئًا.

• الصفحات الثابتة (الصفحة الرئيسية، قائمة الخدمات، النقل، النقل المبرَّد/المجمَّد، التوصيل في اليوم نفسه، الانتقال إلى مرافق كبار السن، معلومات الشركة، سياسة الخصوصية، الأسئلة الشائعة، الأسعار، المدونة، التواصل)
• صفحات المناطق التسع (ميازاكي، مياكونوجو، نوبيوكا، نيتشينان، كوباياشي، هيوغا، سايتو، كوشيما، إيبينو)
• مقالات المدونة القديمة الفردية (أكثر من 100 مقال، من زوايا محلية مرتبطة بالمناطق إلى مقالات معرفة عملية عن النقل الفردي والتوصيل لمسافات طويلة)
• «الملفات التي ليست صفحات لكنها تظل متاحة للعموم»، مثل robots.txt وsitemap.xml وملف التحقق من الملكية الخاص بـ Search Console، وسكربت إرسال النموذج القديم (php/submit.php)

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

صُنِّفت الصفحات الثابتة وصفحات المناطق وعناوين URL لمقالات المدونة ذات المعنى حاليًا جميعها ضمن keep (دون تغيير). في المقابل، صُمِّمت عناوين URL بسلاسل عشوائية عديمة المعنى رقّمها النظام تلقائيًا (من نوع /blog/5lmln1lx0x/) وأسماء الملفات المؤرَّخة مثل post20210721.html لتُعاد توجيهها عبر 301 نحو عناوين URL جديدة لمقالات تحمل slug ذا معنى.

وكان هناك عنصر آخر دخل ضمن عملية اتخاذ القرار هذه، وهو php/submit.php، سكربت وجهة إرسال متروك على الموقع القديم. تأكدنا من أنه لم يكن مرجعيًا لأي نموذج في HTML المنشور، وأن قنوات التواصل التي كانت تعمل فعليًا اقتصرت على ثلاثة أنظمة فقط: الهاتف والبريد الإلكتروني وطلب عرض السعر عبر LINE — لذا اعتبرناه «سكربت إرسال متروكًا» وأعددناه لإعادة التوجيه عبر 301 نحو /contact/ (نتناول خلفية هذا القرار بمزيد من التفصيل في الفصل التالي والفصل 5).

في تصميم عمليات إعادة التوجيه، التزمنا دون استثناء بقاعدتين.

• تُحل كل عملية إعادة توجيه في قفزة واحدة فقط (عدم إنشاء سلسلة من عمليات إعادة التوجيه أبدًا)
• تضمين فحص أثناء البناء (build) يتحقق من وجود عنوان URL الوجهة فعليًا (لتفادي حادثة توجيه 301 نحو عنوان URL غير موجود)

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

3. قائمة تحقق للحفاظ على المحتوى لتفادي «فقدانه»

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

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

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

باستخدام قائمة التحقق هذه، قارنّا الصفحات القديمة والجديدة صفحة بصفحة قبل إطلاق الموقع الجديد، وتأكدنا من عدم فقدان أي عنصر. النقطة الجوهرية هي أننا ضمِنّا، عبر قائمة لا بالحدس أو الذاكرة، أن «مادة اتخاذ القرار» — الأسعار وساعات العمل ونقاط القوة — انتقلت كاملة رغم تغيّر التصميم.

4. تحسين محركات البحث المحلي — تصميم صفحات المناطق التسع

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

توجد صفحات المناطق هذه كنقطة هبوط لعمليات البحث التي تتضمن اسم مكان، من نوع «[اسم المكان] + نقل» أو «[اسم المكان] + توصيل». وبالنسبة لخدمة مثل النقل أو الانتقال، حيث ترتبط منطقة التغطية بمناطق جغرافية محددة، تؤدي هذه الصفحات دور التقاط طلب البحث المرتبط باسم المكان، وهو ما لا تستطيع الصفحة الرئيسية أو صفحة الأسعار وحدهما تغطيته بالكامل.

بالنظر إلى جدول تخطيط عناوين URL، صُنِّفت الصفحات التسع من /area/miyazaki/ إلى /area/ebino/ جميعها ضمن keep (دون تغيير في عنوان URL)، ولم تمسّ إعادة التصميم هذا الهيكل نفسه. إلى جانب هذه الصفحات، توجد أيضًا مقالات مدونة عديدة مرتبطة بكل منطقة تتناول أسماء أماكن محلية محددة — أحياء داخل مدينة ميازاكي أو مياكونوجو مثلًا — مكوِّنة بذلك هيكلًا تتكامل فيه صفحات المناطق مع مقالات المدونة.

الصفحات من هذا النوع — أي صفحات المناطق — وهي النوع الذي يُنتَج بكميات كبيرة بمجرد تغيير اسم المكان ضمن قالب متطابق فيما عداه، تحمل مخاطرة أن تبدو، إذا كان محتواها ضعيفًا، نسخًا معاد استخدامها من الصفحة نفسها في نظر محركات البحث والقرّاء على حدٍّ سواء. في هذه الحالة، وُرِّث تقسيم الأدوار من الموقع القديم: تغطي صفحات المناطق نفسها مستوى المنطقة، بينما تتناول مقالات المدونة بشكل منفصل تفاصيل مستوى الحي داخل كل منطقة. وكان هذا الهيكل يتجنب بالفعل «الضعف» النمطي للصفحات المُنتَجة بكميات كبيرة. تركت إعادة التصميم هذا الهيكل دون مساس وأبقت عناوين URL دون تغيير.

5. توحيد قنوات التواصل المتناثرة

كان التعامل مع php/submit.php، المذكور في الفصل 3، قرارًا مهمًا أيضًا من منظور تنظيم مسار التواصل.

عند فحص الموقع القديم، تأكدنا من أن الأنظمة الثلاثة التالية فقط هي التي كانت تعمل فعليًا كقنوات تواصل متاحة للعموم.

• الهاتف (0120-931-677، ساعات الاستقبال من 8:00 إلى 20:00)
• البريد الإلكتروني
• طلب عرض سعر عبر LINE

في المقابل، ظل سكربت وجهة الإرسال php/submit.php نفسه موجودًا في الكود، لكن لم يكن مرجعيًا لأي نموذج في HTML المنشور. بعبارة أخرى، كان «سكربتًا متروكًا» لم يعد يُستخدم فعليًا. بناءً على ذلك، يوحِّد الموقع الجديد القنوات الثلاث — الهاتف والبريد الإلكتروني وطلب عرض السعر عبر LINE — في صفحة /contact/، وأي وصول إلى php/submit.php مصمَّم لإعادة التوجيه عبر 301 نحو /contact/.

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

6. ترتيب النطاقات القديمة — التعامل مع نطاق صفحة هبوط مهجور

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

الحالة الثالثة على وجه الخصوص درس مهم. نُقل محتوى صفحة هبوط النقل المبرَّد/المجمَّد القديمة — نقاط قوتها المتعلقة بمركبات مزوَّدة بوحدات تبريد تصل إلى −20 درجة مئوية، وتوفرها على مدار الساعة طوال أيام السنة، ورحلاتها المنتظمة وتوصيلها حسب المسار — إلى /refrigerated/ في الموقع الجديد بالفعل. لكن بما أن النطاق القديم نفسه لم يعد بالإمكان حله، على الأرجح بسبب انتهاء صلاحية تسجيل DNS، فلا سبيل لإعداد إعادة توجيه 301 عليه. الدرس المستفاد هو أن ترك نطاق دون صيانة أو تجديد قد يعرِّضك لفقدان قوة الروابط الخلفية وحركة البحث بالاسم التجاري المتراكمتين عليه فجأة يومًا ما.

إذا كانت شركتك تُشغِّل صفحات هبوط للخدمات على نطاقات منفصلة وتفكر في إعادة تصميم، فإننا نوصي بعدم الاكتفاء بتحديد وجهة توحيد المحتوى، بل التحقق في الوقت نفسه من حالة عقد النطاق القديم — هل ما زال التجديد ساريًا، وهل ما زال DNS الخاص به يعمل. إن إمكانية إعداد إعادة التوجيه 301 ما دام الاسترجاع لا يزال ممكنًا تُحدث فرقًا حقيقيًا في مدى سهولة نقل القوة المتراكمة لاحقًا.

7. التحقق قبل الإطلاق والمهام بعد الإطلاق

قبل إطلاق الموقع الجديد، أجرينا الفحوصات التالية.

• المقارنة مع قائمة تحقق الحفاظ على المحتوى التي أُعِدَّت في الفصلين 2 و3 (هل تتطابق عناصر الصفحات القديمة والجديدة)
• التحقق الفعلي من عمليات إعادة التوجيه 301 (إرسال طلبات فعلية والتأكد من أنها تُعيد رموز الحالة والوجهات المتوقعة)
• التأكد من أن ملف التحقق من الملكية الخاص بـ Search Console يُعيد الحالة 200 بشكل صحيح
• التأكد من أن الملفات اللازمة للإطلاق، مثل robots.txt وsitemap.xml و_headers، منشورة فعليًا

توجد أيضًا مهام يجب معالجتها بعد الإطلاق.

• إعادة إرسال sitemap.xml إلى Search Console
• استخدام أداة فحص عناوين URL للتأكد بشكل فردي من أن عناوين URL بمعرّف في المدونة القديمة وأسماء الملفات .html المؤرَّخة تُعاد توجيهها عبر 301 كما هو متوقَّع
• على مدى عدة أسابيع، التحقق في تقرير التغطية مما إذا كانت عناوين URL القديمة، التي كانت سابقًا تُعيد 404 أو مستبعَدة من الفهرسة، قد أصبحت معترفًا بها كـ«إعادة توجيه»

لا ينتهي مشروع إعادة التصميم بالإطلاق — من الأفضل التخطيط له انطلاقًا من فرضية أنه لا يكتمل فعليًا إلا بعد مراقبة عمليات إعادة التوجيه والتأكد من أن محرك البحث تعرَّف عليها بشكل صحيح بعد الإطلاق.

8. الخلاصة — قواعد عامة لتجنب الفشل في إعادة التصميم

بتلخيص الأفكار المستخلَصة من حالة Douzu Carry Service هذه في مبادئ تنطبق بالقدر نفسه على مشاريع إعادة التصميم الأخرى، نصل إلى ما يلي.

• تصميم عناوين URL أولًا، والتصميم البصري لاحقًا. بالنسبة لموقع قديم يملك بالفعل حركة بحث أو روابط خلفية، أنجِز جرد عناوين URL الكامل وجدول التخطيط نحو عناوين URL الجديدة (تخطيط 301) قبل حتى التفكير في التصميم البصري.
• لا تُطلق الموقع دون جرد للمحتوى. تحقق من «مادة اتخاذ القرار» مثل الأسعار وساعات العمل وبيانات الاتصال ونقاط القوة، عبر قائمة تحقق تقارن الصفحات القديمة والجديدة صفحة بصفحة، قبل الإطلاق.
• أبقِ على القنوات المستخدَمة فعليًا فقط. إذا عثرت على نموذج أو سكربت إرسال غير مستخدَم، تحقق من الواقع الفعلي، ثم وحِّده ضمن القناة التي ما زالت نشطة.
• اربط كل عملية إعادة توجيه بقفزة واحدة وبالتحقق من وجود الوجهة. لا تُنشئ سلاسل أبدًا، واحرص على وجود آلية لا تُرسل أبدًا إلى عنوان URL غير موجود.
• رتِّب النطاقات ما دامت لا تزال نشطة. إن تركت نطاقًا منفصلاً لصفحة هبوط خدمة دون صيانة، فقد يجعله انتهاء صلاحية تسجيل DNS غير قابل للاسترجاع — مما يكلفك بالضبط فرصة نقل القوة المتراكمة.

إعادة تصميم الموقع ليست مجرد عمل يتعلق بتجديد التصميم — بل هي أيضًا، في حد ذاتها، مهمة تصميمية تتمثل في تحديد كيفية نقل القوة البحثية ومسار التواصل المتراكمَين بمرور الوقت. يتوفر ملخص موجز لهذه الحالة في مقال «الحالة التي تلخّص هيكل Douzu Carry Service»، وهو يستحق الاطلاع عليه أيضًا.

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

مقالات ذات صلة

• الحالة التي تلخّص هيكل Douzu Carry Service
• لماذا تبني KomuraSoft المواقع باستخدام نظام تصميم وكالة اليابان الرقمية — يمكن للتكلفة المنخفضة والجودة العالية أن تتعايشا
• الأماكن الثلاثة التي ينبغي إصلاحها أولًا في موقع لا يتلقى استفسارات
• تطوير المواقع
• التواصل

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

بماذا ينبغي أن تبدأ عملية إعادة تصميم الموقع؟

ليس بمسودة تصميم، بل بجدول جرد يسرد جميع عناوين URL في الموقع القديم. يعني ذلك تصنيف الصفحات الثابتة وصفحات المناطق ومقالات المدونة تصنيفًا شاملاً لا يفوت شيئًا، إضافة إلى «الملفات التي ليست صفحات لكنها تظل متاحة للعموم»، مثل robots.txt وملف التحقق من الملكية الخاص بـ Search Console وسكربتات إرسال النماذج. بعد ذلك، يُبنى جدول تخطيط يحدد لكل عنوان URL على حدة ما إذا كان سيبقى دون تغيير أم سيُعاد توجيهه (301). تثبيت هذا الأساس أولًا يقلل من إعادة العمل في مراحل التنفيذ وإنشاء المحتوى اللاحقة.

ما أهم نقاط تصميم عمليات إعادة التوجيه لتجنب انخفاض الترتيب في نتائج البحث أثناء إعادة التصميم؟

أبقِ عناوين URL ذات المعنى — الصفحات الثابتة، صفحات المناطق، وما شابه — دون تغيير (keep)، وأعِد توجيه 301 فقط لعناوين URL عديمة المعنى التي رقّمها النظام تلقائيًا، نحو عناوين URL جديدة تحمل slug ذا معنى. كقواعد تصميم، نلتزم دون استثناء بأمرين: تُحل كل عملية إعادة توجيه في قفزة واحدة فقط دون تكوين سلاسل، وتتضمن عملية البناء (build) فحصًا يتحقق من وجود عنوان URL الوجهة فعليًا، لتفادي حادثة توجيه 301 نحو عنوان URL غير موجود. بعد الإطلاق، نراقب Search Console لعدة أسابيع حتى يتعرف على عمليات إعادة التوجيه.

لماذا تؤدي إعادة التصميم أحيانًا إلى انخفاض عدد الاستفسارات؟

لأنه أثناء عملية تجديد التصميم، قد تختفي دون أن يلاحظ أحد معلومات تؤثر مباشرة في قرار التواصل — كالأسعار وساعات العمل وبيانات الاتصال ونقاط القوة الرئيسية. وكإجراء مضاد، نُعِدّ قائمة تحقق للحفاظ على المحتوى تدوّن، لكل صفحة رئيسية، المعلومات التي لا غنى عنها من الموقع القديم (خطط الأسعار، ساعات الاستقبال، الخدمات المقدَّمة، وما إلى ذلك)، ثم نقارن الصفحات القديمة والجديدة صفحة بصفحة قبل الإطلاق. النقطة الجوهرية هي ضمان ذلك عبر قائمة، لا بالاعتماد على الذاكرة أو الحدس.

هل يجوز ترك صفحة هبوط غير مستخدَمة على نطاق منفصل دون معالجة؟

تركها دون معالجة أمر محفوف بالمخاطر. في هذه الحالة، توقف النطاق القديم لصفحة هبوط التوصيل المبرَّد/المجمَّد عن الحل (resolve)، على الأرجح بسبب انتهاء صلاحية إعدادات DNS الخاصة به — ومع أن المحتوى كان قد نُقل بالفعل إلى الموقع الجديد، لم يعد هناك سبيل لإعداد إعادة توجيه 301 من النطاق القديم. إذا تُرك نطاق دون صيانة أو تجديد، فقد تفقد فجأة يومًا ما قوة الروابط الخلفية وحركة البحث بالاسم التجاري المتراكمتين عليه. عند التخطيط لإعادة التصميم، يُنصح بالتحقق في آنٍ واحد من حالة عقد النطاق القديم ومن استمرار عمل DNS الخاص به، وإعداد إعادة التوجيه 301 ما دام الاسترجاع لا يزال ممكنًا.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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