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

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

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

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

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

ما يمكن حمله من هذا المقال قالب إجراءات يُعاد استخدامه كما هو في إعادة تصميم شركتك. تحديداً أربعة: تكوين أعمدة جدول جرد عناوين URL وجدول التخطيط (الفصل 2)، وطريقة تنفيذ 301 وأمثلة الإعداد (الفصل 3)، وكيفية إعداد قائمة تحقق الحفاظ على المحتوى (الفصل 4)، وأوامر التحقق وبنود التأكيد قبل النشر وبعده (الفصل 8). القراءة المتوقَّعة من زاوية «إذا فعلنا الأمر نفسه في موقعنا، ماذا نُعدّ وماذا نؤكّد».

1. نظرة على المشروع ── Before / After

أولاً الصورة الكلية.

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

أما تصميم الموقع الجديد فبُني على نظام التصميم الذي نشرته الوكالة الرقمية اليابانية أساساً. بإسقاط مرحلة إحداث التصميم من الصفر، وُجّه ذلك الجهد إلى تصميم عناوين URL ونقل المحتوى اللذين يتناولهما هذا المقال. فكر هذا التقدّم مجموع في لماذا يبني كومورا سوفت المواقع الإلكترونية اعتماداً على نظام التصميم Digital Agency.

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

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 22، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. أول ما فعلناه لم يكن التصميم بل جرد عناوين URL

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

تحديداً صُنّفت الوحدات التالية دون إغفال.

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

تكوين أعمدة جدول الجرد يكفي بالشكل التالي. إذا أردت المحاكاة فابدأ بهذه الأعمدة.

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

في جدول التخطيط هذه المرة قسّمنا الحكم إجمالاً إلى نوعين.

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

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

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

• الإنهاء في قفزة واحدة (عدم تكوين سلسلة = سلسلة إعادة توجيه)
• إدخال آلية تتحقق عند البناء من وجود عنوان الوجهة (منع حادث 301 نحو عنوان غير موجود)

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

3. كيف نفّذنا إعادة التوجيه 301

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

الموقع الجديد تكوين توليد موقع ثابت + Cloudflare Pages. في هذا التكوين ينقسم موضع إصدار إعادة التوجيه إلى موضعين.

إن لم تفهم هذا التقسيم أولاً، صرفت وقتاً في «كتبت سطر www في _redirects ولم يعمل». _redirects يعمل على المسارات داخل الموقع، ولا يستطيع التوزيع بحسب اسم المضيف الذي جاء منه الطلب.

3.1 المسارات داخل المضيف نفسه ── ملف _redirects

لدى Cloudflare Pages آلية تعيد التوجيه وفق محتوى ملف نصي اسمه _redirects يُوضع في جذر ناتج البناء. الشكل كتابة «المسار الأصلي» و«الوجهة» و«رمز الحالة» في سطر واحد مفصولة بمسافات.

/blog/5lmln1lx0x/          /blog/oneroom-mansion-hikkoshi/   301
/blog/post20210721.html    /blog/oneroom-mansion-hikkoshi/   301
/php/submit.php            /contact/                         301

هنا صرّح حتماً بـ 301 في الذيل. إذا أُغفل رمز الحالة عولج كـ 302 (نقل مؤقت)، ولم يصر انتقالاً دائماً يُقصد به نقل تقييم البحث. سقف إعادة التوجيه الثابتة 2,000 بند، وإذا تجاوز الحجم ذلك لزم التحويل إلى Bulk Redirects.

هذه المرة لم نكتب _redirects يدوياً، بل جعلنا سكربت البناء يولّده من جدول التخطيط. يحمل سكربت البناء تعريفات إعادة التوجيه كمصفوفة، ويكتبها سطراً سطراً عند الإخراج. الصورة كالتالي.

// 対応表(旧URL → 新URL)を1か所にまとめて持つ
const redirects = [
  ["/blog/5lmln1lx0x/", "/blog/oneroom-mansion-hikkoshi/"],
  ["/blog/post20210721.html", "/blog/oneroom-mansion-hikkoshi/"],
  ["/php/submit.php", "/contact/"],
];

// dist/_redirects に「元のパス 転送先 301」の形式で書き出す
const body = redirects.map(([from, to]) => `${from} ${to} 301`).join("\n");
await fs.writeFile("dist/_redirects", `${body}\n`);

لهذا فائدتان. الأولى أن قاعدتي الفصل 2 «الإنهاء في قفزة واحدة» و«التحقق من وجود عنوان الوجهة» يمكن ضمانهما كاختبار آلي عند البناء. أعددنا اختباراً يتحقق من أن محتوى _redirects المولَّد بالعدد والمحتوى المتوقَّعين، وأكدنا أن الكل 301 بقفزة واحدة. الثانية أنه عند تغيير عنوان مقال يكفي تصحيح جدول التخطيط فيتبع _redirects تلقائياً، فلا يقع حادث إصلاح أحد الجانبين فقط وكسر الآخر.

3.2 ما يتغيّر فيه اسم المضيف ── Redirect Rules في Cloudflare

إعادة التوجيه 301 من www.douzucarry.com إلى apex (douzucarry.com) وأشباهها تُضبط في جانب لوحة Cloudflare. الخطوات كالتالي.

1. في المنطقة المعنية، أكد وجود سجل DNS لـ www وأن الوكيل مفعَّل (Proxied). بلا سجل DNS لا يصل الطلب أصلاً إلى Cloudflare.
2. افتح Rules > Redirect Rules > Create rule.
3. في الشرط (When) عيّن «Hostname equals www.douzucarry.com».
4. في الإجراء (Then) اختر Dynamic redirect، واجعل تعبير الوجهة concat("https://douzucarry.com", http.request.uri.path). الحالة 301، وPreserve query string على ON.

صيغة نقل المسار كما هو مقصودة لإرسال كل صفحة في جانب www واحداً لواحد إلى المسار نفسه في apex. أما إذا كان المحتوى موحَّداً في صفحة واحدة في الموقع الجديد كما في نطاق صفحة الهبوط القديمة في الفصل 7، فلا يجوز بالعكس نقل المسار. إضافة الجزء الملتقَط ببطاقة بدل إلى الوجهة يرسل 301 إلى عنوان غير موجود مثل /refrigerated/foo، فتزيد 404 وينهار تجميع التقييم. في تلك الحالة اجعل الوجهة عنواناً ثابتاً واحداً.

3.3 لماذا نتجنّب الخيارات التي ليست أياً منهما

إذا كان الموقع القديم يعمل بـ PHP أو Apache، فثمة أيضاً كتابة RewriteRule ... [R=301,L] في .htaccess. هذا واقعي إذا افترضت إبقاء البيئة القديمة فترة. أما النقل عبر <meta http-equiv="refresh"> في HTML فـ رمز حالة HTTP يبقى 200، فلا تختره حيث تريد معاملة 301. إعادة الكتابة بـ location.href في JavaScript كذلك. لإبلاغ محرك البحث «انتقلنا»، يلزم أن يعيد جانب الخادم 301.

4. قائمة تحقق للحفاظ حتى لا «يسقط» المحتوى

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

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

لذلك دوّنا المعلومات التي لا غنى عنها من الموقع القديم لكل صفحة رئيسة. بعض المحتوى كالتالي.

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

5. SEO المحلي ── تصميم صفحات المناطق التسع

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

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

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

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

6. تجميع مسار الاستفسار الذي كان متفرقاً

تعامل php/submit.php المذكور في الفصل 2 كان حكماً مهماً أيضاً في ترتيب مسار الاستفسار.

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

• الهاتف (0120-931-677، ساعات الاستقبال 8:00〜20:00)
• البريد
• طلب تقدير عبر LINE

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

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

7. ترتيب النطاقات القديمة ── التعامل مع نطاق صفحة هبوط متروك

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

الثالث وحده بقي غير معالَج. هذا الفرق تأكد كنتيجة التحقق قبل النشر في الفصل 8 التالي، لا «ظننّا أننا ضبطنا»، بل تأكدنا أن 301 يعود فعلاً.

حالة الثالث خصوصاً درس مهم. محتوى صفحة الهبوط القديمة للتوصيل المبرَّد/المجمَّد (سيارات مجهّزة بمجمّد حتى −20°C، تعامل 24 ساعة 365 يوماً، رحلات منتظمة وتوزيع مسارات) نُقل إلى /refrigerated/ في الموقع الجديد، لكن النطاق القديم نفسه لا يُحل الاسم لشبهة انتهاء صلاحية DNS، فلا يمكن إعداد 301 من النطاق القديم. معنى ذلك أن ترك نطاق دون صيانة أو تجديد قد يُفقدك فجأة قوة الروابط الخلفية وحركة البحث بالاسم المتراكمتين على ذلك النطاق.

عندما تدرس شركة تدير صفحات هبوط خدمات على نطاقات منفصلة إعادة التصميم، نوصي لا بتقرير وجهة توحيد المحتوى فحسب، بل بتأكيد حالة عقد النطاق القديم في الوقت نفسه (هل يستمر التجديد، وهل DNS حي). إمكانية إعداد 301 ما دام الاسترجاع ممكناً تغيّر سهولة نقل التقييم بعد ذلك.

8. التحقق قبل النشر وما يُفعل بعده

قبل نشر الموقع الجديد أجرينا تأكيدات كالتالي.

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

قياس 301 الفعلي أجروه بأمر لا بالمتصفح. المتصفح يتبع إعادة التوجيه تلقائياً، حتى إذا تخلّل 302 في الطريق عُرضت الصفحة النهائية ولم تُلاحظ. بـ curl -I (جلب الترويسات فقط، دون اتباع إعادة التوجيه) يمكن تأكيد رمز الحالة العائد وترويسة Location كما هما.

# 旧ブログのID付きURLが、新しいslugのURLへ301になっているか
curl -I https://douzucarry.com/blog/5lmln1lx0x/

# 日付ファイル名の .html URL も同様に確認する
curl -I https://douzucarry.com/blog/post20210721.html

# www で来たリクエストが apex へ301になっているか(パスが引き継がれるかも見る)
curl -I https://www.douzucarry.com/price/

ما يُنظر إليه أمران: أن سطر الحالة في السطر الأول 301، وأن قيمة Location: تطابق «الوجهة» في جدول التخطيط. إذا عاد 302 فذلك نسيان كتابة رمز الحالة في _redirects، وإذا نُقل ما بعد Location إلى عنوان آخر أيضاً فذلك تكوين سلسلة. أسطر redirect في جدول التخطيط كلها تُؤكد بهذه الطريقة واحداً واحداً.

وبعد النشر أيضاً ما ينبغي فعله.

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

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

9. الخلاصة ── قواعد عامة لتفادي الفشل في إعادة التصميم

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

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

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

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

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

• الحالة التي تلخّص هيكل Douzu Carry Service
• لماذا يبني كومورا سوفت المواقع الإلكترونية اعتماداً على نظام التصميم Digital Agency ── يمكن الجمع بين الرخص والجودة
• حين لا يأتي الموقع باستفسارات، أوّل ثلاثة مواضع يجب إصلاحها
• تصميم المواقع
• تواصل معنا

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

غو كومورا

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

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