دليل الترحيل من Movable Type إلى Next.js للشركات اليابانية

إذا عملت مع مواقع الشركات اليابانية لفترة من الوقت، فقد التقيت بالتأكيد بـ Movable Type. احتفظت نظام إدارة المحتوى من Six Apart بسيطرة قوية بشكل ملحوظ على السوق الياباني منذ منتصف العقد الأول من القرن الحادي والعشرين، مما يدعم كل شيء من مواقع الشركات الكبرى لدى الشركات المصنعة الكبرى إلى بوابات الحكومة ومواقع الجامعات. لكن هنا تكمن المشكلة -- نحن في عام 2026، والويب تجاوز هذه المرحلة. من المرجح أن تثبيت Movable Type الخاص بك لم يتقدم.

لقد ساعدت في ترحيل عدة مواقع شركات يابانية بعيداً عن Movable Type خلال السنتين الماضيتين، وسأكون صريحاً: هذا ليس مشروعاً تافهاً. هناك تفاصيل دقيقة حول ترميز الأحرف، وهياكل المحتوى الفريدة لمواقع الشركات اليابانية، والمخاوف التنظيمية التي تجعل هذه الترحيلات مختلفة عن الانتقال النموذجي من WordPress إلى Next.js. يغطي هذا الدليل كل شيء تعلمته بالطريقة الصعبة.

جدول المحتويات

• لماذا تغادر الشركات اليابانية Movable Type
• فهم معمارية Movable Type
• اختيار خلفية نظام إدارة المحتوى بدون رأس
• تدقيق المحتوى واستخراج البيانات
• التعامل مع المحتوى الياباني المحدد
• بناء واجهة Next.js الأمامية
• استراتيجية ترحيل تحسين محركات البحث للبحث الياباني
• النشر والبنية التحتية
• التخطيط الزمني والميزانية
• الأسئلة الشائعة

لماذا تغادر الشركات اليابانية Movable Type

دعنا ننهي الواضح: Movable Type ليس ميتاً. لا تزال Six Apart Japan تحافظ عليه، وأضاف Movable Type 8 (الصادر في أواخر 2024) بعض الميزات الحديثة. لكن الكتابة على الجدار واضحة لعدة أسباب.

مخاوف الأداء

يستخدم Movable Type نموذج نشر ثابت -- فهو يعيد بناء ملفات HTML عند تغيير المحتوى. يبدو هذا رائعاً حتى يكون لديك موقع به 15000 صفحة ومحرر محتوى ينتظر 20 دقيقة لانتهاء إعادة البناء. لقد رأيت مواقع شركات يابانية حيث كان المحررون يجدولون إعادة البناء بين عشية وضحاها لأن العملية كانت بطيئة جداً.

يحل Next.js مع ISR (Incremental Static Regeneration) أو إعادة التحقق عند الطلب هذا تماماً. تتجدد الصفحات بشكل فردي في أجزاء من الألف من الثانية.

تكلفة الملكية

تبلغ تكاليف ترخيص Movable Type في اليابان حوالي ¥600,000-¥1,200,000 سنوياً للتراخيص الخاصة بالمؤسسات اعتباراً من 2026. هذا $4,000-$8,000 USD سنوياً فقط لترخيص نظام إدارة المحتوى، قبل الاستضافة أو المكونات الإضافية أو التطوير المخصص. قارن ذلك مع نظام إدارة محتوى بدون رأس مثل microCMS (شهير في اليابان، يبدأ من ¥4,900/شهر لخطط الأعمال) مقترناً بـ Next.js على Vercel، وتبدأ الرياضيات تبدو مختلفة جداً.

نقص المطورين

هذا هو الكبير الذي لا أحد يتحدث عنه علناً. البحث عن مطورين يعرفون Perl (لغة Movable Type) وهم على استعداد للعمل على قوالب MT يصبح صعباً حقاً في اليابان. العمر الوسيط للمطورين ذوي الخبرة MT التي قابلتها يزيد عن 45. وفي الوقت نفسه، مطورو Next.js في كل مكان -- إنه الإطار الذي تقوم الشركات التكنولوجية اليابانية بتوظيفه في عام 2026.

الأمان والامتثال

كان لدى Movable Type عدة نقاط ضعف خطيرة على مدار السنين، بما في ذلك ثغرة XMLRPC سيئة السمعة (CVE-2021-20837) التي تم استغلالها بنشاط ضد المواقع اليابانية. مع تشديد متطلبات APPI المعدلة في اليابان (قانون حماية المعلومات الشخصية) في 2025-2026، تقيم الشركات أوضاعها الأمنية.

فهم معمارية Movable Type

قبل أن تتمكن من الهجرة، يجب أن تفهم ما تهاجر منه. نموذج بيانات Movable Type مختلف عن WordPress أو معظم أنظمة إدارة المحتوى الحديثة.

هياكل البيانات الأساسية

مفهوم MT	الوصف	معادل Next.js/بدون رأس
Blog	حاوية محتوى على المستوى الأعلى	الموقع أو مساحة العمل
Entry	مقالة مدونة أو مقال	عنصر محتوى (نوع مدونة)
Page	صفحة ثابتة	عنصر محتوى (نوع صفحة)
Category	تصنيف هرمي	نظام الفئة/العلامة
Template	قوالب HTML مع علامات MT	مكونات React + تخطيطات
Custom Field	حقول الإدخال الممتدة	حقول نموذج المحتوى
Asset	ملفات الوسائط المرفوعة	مكتبة الوسائط/الأصول
Website	حاوية الوالدين للمدونات	تكوين الموقع المتعدد

تستخدم لغة قوالب Movable Type علامات مثل <mt:EntryTitle> و <mt:Entries>. هذه لا تعيّن 1:1 إلى أي شيء في المكدس الحديث -- ستعيد بناء طبقة العرض من البداية.

طبقة قاعدة البيانات

يدعم MT MySQL و PostgreSQL و SQLite. تستخدم معظم التثبيتات الخاصة بالمؤسسات اليابانية MySQL. مخطط قاعدة البيانات موثق جيداً ولكن... غريب الأطوار. يتم تخزين الحقول المخصصة في جدول mt_entry_meta منفصل باستخدام نمط القيمة الرئيسية، مما يجعل الاستخراج غير تافه.

إليك شكل جدول الإدخال:

SELECT 
  entry_id,
  entry_title,
  entry_text,
  entry_text_more,
  entry_excerpt,
  entry_created_on,
  entry_modified_on,
  entry_basename,
  entry_status
FROM mt_entry
WHERE entry_blog_id = 1
  AND entry_status = 2  -- 2 = published
ORDER BY entry_created_on DESC;

لاحظ انقسام entry_text و entry_text_more. يقسم MT محتوى الجسم إلى حقلين -- نمط من عصر المدونات المبكرة الذي ستحتاج إلى دمجه أثناء الترحيل.

اختيار خلفية نظام إدارة المحتوى بدون رأس

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

microCMS

هذا هو الخيار الافتراضي للشركات اليابانية، ولسبب وجيه. تم بناؤه بواسطة شركة يابانية، له واجهة استخدام يابانية أصلية، دعم عملاء ياباني، وإقامة البيانات في اليابان. يبدأ التسعير من ¥4,900/شهر (Hobby مجاني للمشاريع الصغيرة). واجهة برمجة التطبيقات نظيفة، ودعم webhook يعمل بشكل جيد مع ISR الخاص بـ Next.js، ولن يحتاج محررو المحتوى الخاص بك إلى مهارات اللغة الإنجليزية.

Newt

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

Contentful

خيار المؤسسات العالمية. دعم توطين قوي، واجهة برمجة تطبيقات ممتازة، وبيئة نظام ناضجة. الجانب السلبي للشركات اليابانية: الدعم باللغة الإنجليزية، والواجهة باللغة الإنجليزية، والتسعير بالدولار الأمريكي. بسعر $300/شهر لخطة الفريق (تسعير 2026)، أغلى بكثير من البدائل اليابانية.

Sanity

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

نظام إدارة المحتوى	واجهة المستخدم اليابانية	إقامة بيانات اليابان	السعر الابتدائي	الأنسب لـ
microCMS	✅	✅	¥4,900/شهر	معظم مواقع الشركات اليابانية
Newt	✅	✅	¥3,300/شهر	نماذج المحتوى المعقدة
Contentful	❌	❌ (EU/US)	~$300/شهر	الشركات العالمية
Sanity	جزئي	❌	$99/شهر (الفريق)	فريق الموجهة للمطورين

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

تدقيق المحتوى واستخراج البيانات

هنا يبدأ العمل الحقيقي. لا تتخطَ مرحلة التدقيق -- رأيت عمليات ترحيل تفشل لأن الفريق قفز مباشرة إلى الاستخراج دون فهم ما لديهم بالفعل.

الخطوة 1: جرد كل شيء

اتصل بقاعدة بيانات MT الخاصة بك وقم بتشغيل العدد:

-- جرد الإدخالات حسب المدونة
SELECT 
  b.blog_name,
  COUNT(e.entry_id) as entry_count
FROM mt_entry e
JOIN mt_blog b ON e.entry_blog_id = b.blog_id
WHERE e.entry_status = 2
GROUP BY b.blog_name;

-- جرد الحقول المخصصة لكل مدونة
SELECT 
  b.blog_name,
  em.entry_meta_type,
  COUNT(*) as field_count
FROM mt_entry_meta em
JOIN mt_entry e ON em.entry_meta_entry_id = e.entry_id
JOIN mt_blog b ON e.entry_blog_id = b.blog_id
GROUP BY b.blog_name, em.entry_meta_type;

الخطوة 2: تصدير المحتوى

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

import mysql.connector
import json
import html

def extract_mt_entries(config):
    conn = mysql.connector.connect(**config)
    cursor = conn.cursor(dictionary=True)
    
    cursor.execute("""
        SELECT 
            e.entry_id,
            e.entry_title,
            e.entry_text,
            e.entry_text_more,
            e.entry_excerpt,
            e.entry_basename,
            e.entry_created_on,
            e.entry_modified_on,
            GROUP_CONCAT(c.category_label) as categories
        FROM mt_entry e
        LEFT JOIN mt_placement p ON e.entry_id = p.placement_entry_id
        LEFT JOIN mt_category c ON p.placement_category_id = c.category_id
        WHERE e.entry_status = 2
        GROUP BY e.entry_id
    """)
    
    entries = cursor.fetchall()
    
    for entry in entries:
        # دمج النص والنص_المزيد
        body = (entry['entry_text'] or '') + (entry['entry_text_more'] or '')
        entry['full_body'] = body
        # التعامل مع الترميز
        entry['entry_title'] = entry['entry_title']
    
    with open('mt_export.json', 'w', encoding='utf-8') as f:
        json.dump(entries, f, ensure_ascii=False, default=str, indent=2)
    
    return entries

الخطوة 3: هجرة أصول الوسائط

يخزن MT الأصول على نظام الملفات، عادة تحت /path/to/mt/support/uploads/. ستحتاج إلى:

1. جرد جميع الملفات ومطابقتها بسجلات قاعدة البيانات في mt_asset
2. إعادة التحميل إلى نظام إدارة محتوى جديد أو CDN (Cloudinary أو imgix أو التخزين المدمج في نظام إدارة المحتوى الخاص بك)
3. تحديث جميع المراجع في محتوى الجسم HTML

هذا مملل. خطط الوقت له.

التعامل مع المحتوى الياباني المحدد

هذا القسم هو السبب في كتابتي لهذه المقالة. لا تغطي الأدلة الشاملة هذه المشاكل.

ترميز الأحرف

تخزن تثبيتات Movable Type الأقدم (قبل MT5) أحياناً المحتوى بترميز EUC-JP أو Shift_JIS، حتى لو كانت قاعدة البيانات يابانية اسمياً UTF-8. تحقق من البيانات الفعلية:

# كشف مشاكل الترميز
import chardet

def check_encoding(text_bytes):
    result = chardet.detect(text_bytes)
    if result['encoding'] != 'utf-8':
        print(f"تحذير: تم اكتشاف {result['encoding']} "
              f"بثقة {result['confidence']:.0%}")
    return result

إذا وجدت عدم تطابق في الترميز، قم بتحويل كل شيء إلى UTF-8 قبل الاستيراد إلى نظام إدارة المحتوى الجديد. الأحرف المشوهة (文字化け) على موقع شركة حقيقي يحدّ من الوظيفة الوظيفية.

نص Ruby (Furigana)

تستخدم مواقع الشركات اليابانية بشكل متكرر شروح ruby -- مساعدات قراءة صغيرة فوق أحرف kanji. غالباً ما تتعامل قوالب MT مع هذه باستخدام علامات مخصصة. في Next.js، ستستخدم عناصر HTML <ruby> القياسية:

// components/RubyText.tsx
export function RubyText({ base, reading }: { base: string; reading: string }) {
  return (
    <ruby>
      {base}
      <rp>(</rp>
      <rt>{reading}</rt>
      <rp>)</rp>
    </ruby>
  );
}

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

صيغة التاريخ الياباني

غالباً ما تعرض مواقع الشركات اليابانية التواريخ بصيغة 和暦 (صيغة الحقبة اليابانية): 令和8年1月15日 بدلاً من 2026-01-15. تعامل مع هذا في مكونات Next.js الخاصة بك:

function formatJapaneseDate(dateString: string): string {
  const date = new Date(dateString);
  return date.toLocaleDateString('ja-JP-u-ca-japanese', {
    era: 'long',
    year: 'numeric',
    month: 'long',
    day: 'numeric',
  });
}

تخطيطات النصوص العمودية

بعض المواقع اليابانية، خاصة في النشر أو الصناعات التقليدية، تستخدم نصوص عمودية (縦書き). معالج CSS يتعامل مع هذا:

.vertical-text {
  writing-mode: vertical-rl;
  text-orientation: mixed;
}

Next.js يتعامل مع هذا بشكل جيد، لكن اختبر جيداً عبر المتصفحات.

بناء واجهة Next.js الأمامية

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

App Router مع الإنشاء الثابت

استخدم Next.js 15 App Router مع الإنشاء الثابت لمعظم الصفحات. مواقع الشركات اليابانية عادة ما تكون غنية بالمحتوى مع تحديثات نادرة -- مثالية للإنشاء الثابت مع إعادة التحقق عند الطلب.

// app/news/[slug]/page.tsx
import { getArticle, getAllArticleSlugs } from '@/lib/cms';

export async function generateStaticParams() {
  const slugs = await getAllArticleSlugs();
  return slugs.map((slug) => ({ slug }));
}

export default async function NewsArticle({ 
  params 
}: { 
  params: Promise<{ slug: string }> 
}) {
  const { slug } = await params;
  const article = await getArticle(slug);
  
  return (
    <article>
      <h1>{article.title}</h1>
      <time dateTime={article.publishedAt}>
        {formatJapaneseDate(article.publishedAt)}
      </time>
      <div dangerouslySetInnerHTML={{ __html: article.body }} />
    </article>
  );
}

تكوين i18n

تحتاج العديد من مواقع الشركات اليابانية إلى نسخ يابانية وإنجليزية. يتعامل Next.js App Router مع هذا باستخدام مجموعات الطرق أو كشف اللغات المستندة إلى البرامج الوسيطة:

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';

export function middleware(request: NextRequest) {
  const pathname = request.nextUrl.pathname;
  const locale = pathname.startsWith('/en') ? 'en' : 'ja';
  
  request.headers.set('x-locale', locale);
  return NextResponse.next();
}

لقد بنينا العشرات من مواقع الشركات اليابانية ثنائية اللغة باستخدام Next.js -- فريق تطوير Next.js الخاص بنا يمكنه أن يرشدك خلال الفروقات الدقيقة.

استراتيجية ترحيل تحسين محركات البحث للبحث الياباني

هذا غير قابل للتفاوض. تعيش الشركات اليابانية وتموت من خلال تصنيفات Google للبحث (Yahoo! Japan تستخدم محرك Google، لذا فهي حقاً فقط Google). قد يسبب الترحيل السيء انهيار حركة البحث العضوي لعدة أشهر.

تعيين عناوين URL

ينشئ Movable Type عناوين URL مع أنماط قابلة للتكوين. الأنماط الشائعة التي أراها في المواقع اليابانية:

• /blog/2024/01/entry-basename.html
• /news/category/entry_basename.html
• /archives/000123.html (أقدم نمط)

أنشئ تعيين عناوين URL كامل قبل أن تبني أي شيء:

// scripts/generate-redirects.ts
interface RedirectMap {
  source: string;
  destination: string;
  permanent: boolean;
}

function generateRedirects(mtEntries: MTEntry[]): RedirectMap[] {
  return mtEntries.map(entry => ({
    source: buildMTUrl(entry),  // نمط عنوان URL القديم MT
    destination: `/news/${entry.entry_basename}`,  // عنوان URL الجديد Next.js
    permanent: true,  // إعادة توجيه 301
  }));
}

ضعها في next.config.ts:

const nextConfig = {
  async redirects() {
    const redirects = await import('./redirects.json');
    return redirects.default;
  },
};

بالنسبة للمواقع التي تحتوي على آلاف عمليات إعادة التوجيه، استخدم البرامج الوسيطة بدلاً من ذلك -- عمليات إعادة التوجيه next.config.ts لها حد عملي.

البيانات المنظمة

تعرض نتائج Google اليابانية بكثافة مجزآت غنية. أضف JSON-LD للمقالات والأسئلة الشائعة والمعلومات التنظيمية:

function ArticleJsonLd({ article }: { article: Article }) {
  const jsonLd = {
    '@context': 'https://schema.org',
    '@type': 'Article',
    headline: article.title,
    datePublished: article.publishedAt,
    dateModified: article.updatedAt,
    author: {
      '@type': 'Organization',
      name: article.companyName,
    },
    inLanguage: 'ja',
  };

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
    />
  );
}

النشر والبنية التحتية

بالنسبة للجماهير اليابانية، يهم زمن الاستجابة. إليك ما يعمل:

المنصة	عقد حافة اليابان	الأفضل لـ	التكلفة الشهرية (نموذجية)
Vercel	طوكيو	معظم مواقع Next.js	$20-150/شهر
AWS (CloudFront + Lambda@Edge)	طوكيو وأوساكا	الامتثال الخاص بالمؤسسات	$100-500/شهر
Google Cloud Run + Cloud CDN	طوكيو	فريق GCP-native	$50-200/شهر
Cloudflare Pages	طوكيو + كثير	المواقع الثابتة البسيطة	مجاني-$25/شهر

Vercel هو الاختيار الافتراضي الخاص بي. تم بناؤها خصيصاً لـ Next.js، وتحتوي على عقدة حافة في طوكيو، ويتم تحديث التجربة عن طريق عدم التطابق. بالنسبة للشركات ذات متطلبات إقامة البيانات الصارمة (الحكومة والمالية)، AWS في ap-northeast-1 (طوكيو) هو الخيار الآمن.

إذا كنت تفكر في Astro بدلاً من Next.js لموقع غني بالمحتوى مع تفاعل ضئيل، فهذا اختيار صحيح أيضاً -- تحقق من قدرات تطوير Astro.

التخطيط الزمني والميزانية

بناءً على الترحيلات الفعلية التي أكملتها، إليك ما يجب توقعه:

المرحلة	المدة	الأنشطة الرئيسية
الاكتشاف والتدقيق	2-3 أسابيع	جرد المحتوى واستطلاعات أصحاب المصلحة وتعيين عناوين URL
إعداد نظام إدارة المحتوى ونمذجة المحتوى	2-4 أسابيع	تصميم المخطط ونصوص هجرة المحتوى
هجرة المحتوى	3-6 أسابيع	نقل البيانات وهجرة الوسائط وضمان الجودة
تطوير الواجهة الأمامية	6-10 أسابيع	بناء Next.js ومكتبة المكونات و i18n
تحسين محركات البحث وضمان الجودة	2-3 أسابيع	اختبار إعادة التوجيه وضبط الأداء واختبار التوافق عبر المتصفحات
التشغيل المرحلي	1-2 أسبوع	قطع DNS والمراقبة والإصلاحات السريعة

الإجمالي: 16-28 أسبوعاً لموقع شركة يابانية نموذجي يحتوي على 1,000-10,000 صفحة.

من حيث الميزانية، تنظر إلى ¥5,000,000-¥15,000,000 ($33,000-$100,000 USD) اعتماداً على التعقيد. قد يبدو هذا مرتفعاً جداً، لكن ضع في الاعتبار: من المرجح أنك تدفع أكثر من ¥1,000,000 سنوياً لترخيص MT والتطوير المتخصص بالفعل. تدفع الهجرة نفسها خلال 2-3 سنوات من خلال تقليل التكاليف التشغيلية وتحسين سرعة المطورين.

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

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

هل يمكننا الاستمرار في استخدام Movable Type كنظام إدارة محتوى بدون رأس مع Next.js؟ من الناحية التقنية نعم -- Movable Type 7+ لديه واجهة برمجة تطبيقات بيانات يمكنها نشر محتوى إلى الواجهة الأمامية. لكنها بطيئة وموثقة بشكل سيء وتفتقر إلى webhooks لإعادة التحقق. جربت هذا النهج في مشروع واحد ولن أوصي به. ستقضي المزيد من الوقت في التعامل مع قيود واجهة برمجة التطبيقات MT مقارنة بالهجرة إلى نظام إدارة محتوى بدون رأس مناسب.

كيف نتعامل مع نموذج إعادة بناء MT مقابل ISR الخاص بـ Next.js؟ إنها مختلفة بشكل أساسي. يعيد MT بناء أقسام الموقع بالكامل مرة واحدة (إنشاء ثابت دفعي). يعيد Next.js ISR إنشاء صفحات فردية عند الطلب. هذا يعني أن المحررين يحصلون على أوقات نشر فورية بدلاً من انتظار إعادة البناء. التحول العقلي سهل فعلاً للمحررين -- يضغطون فقط على النشر والصفحة مباشرة في غضون ثوانٍ.

ماذا يحدث لمكونات إضافية MT الخاصة بنا أثناء الترحيل؟ يحتاج كل مكون إضافي MT إلى استبدال أو إعادة تنفيذ. المكونات الشائعة مثل نماذج الاتصال (مكونات إضافية قائمة على MT) يتم استبدالها بمعالجة نموذج Next.js أو خدمات مثل Formspree. يتم استبدال مكونات البحث بـ Algolia أو البحث المدمج في نظام إدارة المحتوى. جعل جرد المكون الإضافي الكامل أثناء مرحلة التدقيق.

هل ستنخفض تصنيفات Google الخاصة بنا أثناء الترحيل؟ يمكنهم، لكن لا يجب عليهم. العوامل الحاسمة هي: عمليات إعادة التوجيه 301 لكل عنوان URL، والحفاظ على عناوين الصفحات ووصفات البيانات الوصفية متطابقة أو محسنة، والحفاظ على هيكل الارتباط الداخلي وإرسال خريطة الموقع المحدثة. رأيت عمليات ترحيل حيث تحسنت التصنيفات بالفعل لأن الموقع الجديد كان أسرع وكان لديه درجات Core Web Vitals أفضل.

كيف نتعامل مع عناصر تحسين محركات البحث الخاصة بـ اليابان مثل Yahoo! Japan؟ استخدم Yahoo! Japan محرك Google للبحث منذ 2010، لذا فإن استراتيجية تحسين محركات البحث Google تغطي Yahoo! أيضاً. الاستثناء الوحيد هو خصائص Yahoo! Japan الخاصة بها (Yahoo! News وغيرها) التي تحتوي على عمليات تقديم منفصلة. بالنسبة للبحث العضوي العام، ركز على Google وأنت مغطى.

هل يجب أن نهاجر كل المحتوى أم نستخدم هذا كفرصة لتنظيفه؟ التنظيف دائماً. في كل هجرة موقع شركة يابانية قمت بها، كان 30-50٪ من المحتوى قديماً أو متكرراً أو لا توجد حركة مرور له. يهدر ترحيل المحتوى الميت الوقت ويخفف السلطة الموضوعية للموقع الخاص بك. استخدم بيانات التحليلات لتحديد الصفحات التي تستحق الترحيل واترك الباقي يرحل (مع ردود 410 Gone المناسبة وليس 404).

هل يمكننا تشغيل Movable Type و Next.js بالتوازي أثناء الترحيل؟ نعم، وأوصي بها. استخدم نطاق فرعي أو التوجيه المستند إلى المسار لتقديم موقع Next.js الجديد للأقسام المهاجرة بينما يتعامل MT مع الباقي. هذا يتيح لك الهجرة على مراحل بدلاً من عملية قطع محفوفة بالمخاطر. تجعل تكوينات الخادم الوكيل العكسي مع nginx أو Cloudflare Workers هذا سهلاً.

ماذا عن التحكم في الوصول المدمج في Movable Type والميزات الأعضاء؟ إذا كان موقع MT الخاص بك يستخدم تسجيل دخول عضو أو محتوى مبوب أو وصول قائم على الأدوار، فستحتاج إلى تنفيذ المصادقة في Next.js. يعمل NextAuth.js (الآن Auth.js) بشكل جيد لهذا، أو يمكنك استخدام خدمة مثل Clerk أو Auth0. هذا يضيف التعقيد والتكلفة -- احسبها في التخطيط من اليوم الأول.