تم نشر عملية النشر الخاصة بك في الساعة 2:47 مساءً. اجتازت البناء. انتشرت DNS عبر خوادم الأسماء. يتحل المجال الخاص بك. يحمّل المتصفح الخاص بك الصفحة الرئيسية — الخطوط تعرض، والصور تظهر، والبرامج النصية تنفذ. أنت تتنفس الصعداء.

ثم يأتي السؤال الثاني: ماذا يحدث لتحسين محركات البحث الخاصة بك في الساعات الـ 48 القادمة؟

هذه النافذة تحدد ما إذا كانت Google ستكتشف صفحاتك في غضون أيام أو تنجرف لأسابيع. ما إذا كانت عناوينك القديمة تعيد التوجيه بشكل نظيف أو تنتشر 404s عبر الفهرس. ما إذا كانت Search Console ستتصل قبل وصول أول ميزانية زحف لديك — أو بعد أن فقدتها بالفعل.

فيما يلي قائمة التحقق الدقيقة من 48 ساعة التي أقوم بها بعد كل نشر في الإنتاج. تغطي التحقق من Search Console وpings IndexNow وتدقيق إعادة التوجيه والفحوصات الكنسية والسبع مهام تقنية التي تفصل الفهرسة السريعة عن الغموض البطيء. إذا كنت بعد الساعة 47، ابدأ بالمهمة الأولى على أي حال — الحالات الأخيرة أفضل من عدم القيام بأي شيء.

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

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

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

Website SEO Launch Day Checklist: What to Do in the First 48 Hours

الساعة 0-1: التحقق من المتطلبات الأساسية

قبل أن تفكر حتى في محركات البحث، تحتاج إلى التأكد من عدم كسر الأساسيات. لقد رأيت عمليات إطلاق حيث لا تزال علامة المرحلة noindex موجودة في <head>. هذا واحد ممتع لاكتشافه بعد ثلاثة أسابيع.

تحقق من توجيهات المرحلة المتبقية

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

<meta name="robots" content="noindex">

إذا كان لا يزال هناك، توقف عن كل شيء وأصلحه. تحقق من رؤوس HTTP الخاصة بك أيضاً — بعض الأطر (خاصة Next.js) يمكن أن تعيّن رؤوس X-Robots-Tag على مستوى الخادم:

curl -I https://yourdomain.com | grep -i robots

لا يجب أن تري شيئاً. إذا رأيت X-Robots-Tag: noindex، فموقعك بالكامل غير مرئي لمحركات البحث ولا شيء آخر في قائمة التحقق هذه مهم.

تحقق من SSL والعناوين الكنسية

اضغط على هذه العناوين الأربعة يدويًا:

  • http://yourdomain.com
  • http://www.yourdomain.com
  • https://yourdomain.com
  • https://www.yourdomain.com

يجب أن تعيد جميعها توجيه 301 إلى نسخة كنسية واحدة. تستخدم معظم المواقع https://yourdomain.com (بدون www، HTTPS). إذا قدم أي من هذه استجابة 200 بدلاً من إعادة التوجيه، فلديك محتوى مكرر من الدقيقة الأولى.

التحقق من عناوين الصفحات والأوصاف الميتا

قم بفحص نقطي لأفضل 10 صفحات. تأكد من أن كل منها لديها علامة <title> فريدة وـ <meta name="description">. أستخدم Screaming Frog لهذا، لكن يمكنك أيضاً just curl بعض الصفحات:

curl -s https://yourdomain.com | grep -o '<title>[^<]*</title>'

إذا كنت تقوم بتشغيل إعداد CMS بدون رأس — Sanity أو Contentful أو Storyblok — تأكد من أن طبقة headless CMS development الخاصة بك تملأ فعلاً هذه الحقول من محتوى CMS، وليس نص البرنامج.

الساعة 1-2: robots.txt وتكوين Sitemap

robots.txt

ملف robots.txt الخاص بك يعيش في https://yourdomain.com/robots.txt. يجب أن يكون موجوداً، وأن يكون صحيحاً.

بالنسبة لمعظم المواقع الجديدة، إليك ما يجب أن يبدو عليه:

User-agent: *
Allow: /

Sitemap: https://yourdomain.com/sitemap.xml

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

  1. أنت لا تحظر عن غير قصد كل شيء (Disallow: / هو الخيار النووي)
  2. أنت تشير إلى sitemap الخاص بك
  3. الملف متاح (يعود 200، وليس 404)

إذا كنت تستخدم Next.js، فإن App Router يدعم إنشاء robots.txt المدمج:

// app/robots.ts
import { MetadataRoute } from 'next'

export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: '*',
      allow: '/',
    },
    sitemap: 'https://yourdomain.com/sitemap.xml',
  }
}

بالنسبة لـ Astro builds، ستستخدم عادةً تكامل @astrojs/sitemap وإنشاء ملف ثابت robots.txt في مجلد public/ الخاص بك.

Sitemap XML

يخبر sitemap الخاص بك محركات البحث بالضبط الصفحات التي تكون موجودة ومتى تم تعديلها آخر مرة. يجب أن يكون في https://yourdomain.com/sitemap.xml.

ـ sitemap جيد في يوم الإطلاق:

  • يتضمن فقط الصفحات التي تريد فهرستها بالفعل (بدون 404s، بدون إعادة توجيه، بدون صفحات noindex)
  • يستخدم عناوين URL الكنسية الصحيحة (HTTPS، www الصحيحة/non-www)
  • له تواريخ <lastmod> دقيقة
  • يبقى أقل من 50,000 عنوان URL لكل ملف sitemap (استخدم فهرس sitemap إذا لزم الأمر)

اختبره الآن:

curl -s https://yourdomain.com/sitemap.xml | head -50

تأكد من أنه XML صحيح، وليس صفحة HTML. لقد رأيت تطبيقات React تعترض /sitemap.xml وتقدم app shell بدلاً من ذلك. هذا لا فائدة له لـ Googlebot.

الساعة 2-4: إعداد Google Search Console

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

إضافة ممتلكاتك

  1. اذهب إلى Google Search Console
  2. أضف ممتلكاتك باستخدام خيار Domain (وليس URL prefix) — يغطي هذا جميع النطاقات الفرعية ومتغيرات البروتوكول
  3. التحقق عبر سجل DNS TXT (يجعل مزود الاستضافة أو Cloudflare هذا سهلاً)

التحقق على مستوى المجال يستغرق بضع دقائق للانتشار. بينما تنتظر:

أرسل Sitemap الخاص بك

بمجرد التحقق، اذهب إلى Sitemaps في الشريط الجانبي الأيسر وأرسل عنوان URL sitemap الخاص بك. ستقوم Google بجلبه والإبلاغ عن أي أخطاء.

عادةً ما أرى معالجة sitemap الأولية مكتملة في غضون 1-4 ساعات. ستخبرك Google بعدد عناوين URL المكتشفة وعدد الصفحات الصحيحة.

طلب الفهرسة للصفحات الرئيسية

استخدم أداة URL Inspection في أعلى Search Console. الصق عناوين URL الأكثر أهمية لديك — الصفحة الرئيسية وصفحات الهبوط الرئيسية ومنشورات المدونة الأعلى — وانقر على Request Indexing.

تحد Google لك تقريباً من 10-12 طلب فهرسة يومياً لكل ممتلكات. أولويات:

  1. الصفحة الرئيسية
  2. صفحات الخدمة/المنتج الأساسية
  3. صفحة حول
  4. صفحات المحتوى الأعلى

لا تهدر الطلبات على صفحات التصفح أو صفحات العلامات أو أي شيء تعتبره ثانوياً.

تحقق من تقرير التغطية

خلال 24 ساعة (غالباً ما يكون أسرع)، سيبدأ تقرير Pages في الملء. اراقب:

  • Not indexed: Crawled - currently not indexed — وجدت Google الصفحة لكنها اختارت عدم فهرستها
  • Not indexed: Discovered - currently not indexed — تعرف Google أن الصفحة موجودة لكنها لم تزحفها بعد
  • Excluded by robots.txt — robots.txt الخاص بك يحظر شيئاً لم تقصده

Website SEO Launch Day Checklist: What to Do in the First 48 Hours - architecture

الساعة 2-4: أدوات Bing Webmaster و IndexNow

نعم، Bing مهم. إنها توفر تقريباً 9٪ من حركة بحث الولايات المتحدة اعتباراً من أوائل عام 2026، بالإضافة إلى DuckDuckGo و Yahoo وبشكل متزايد نتائج البحث بدعم AI في Copilot و ChatGPT (من خلال فهرس Bing).

إعداد أدوات Bing Webmaster

  1. اذهب إلى Bing Webmaster Tools
  2. يمكنك استيراد إعداد Google Search Console الخاص بك مباشرةً — تقدم Bing هذا الخيار ويوفر الوقت
  3. أرسل sitemap الخاص بك هنا أيضاً

عادةً ما تكون فهرسة Bing أسرع من فهرسة Google للمواقع الجديدة، جزئياً بسبب IndexNow.

بروتوكول IndexNow

IndexNow هو بروتوكول قائم على الدفع يخطر محركات البحث فوراً عند تغيير المحتوى الخاص بك. Bing و Yandex وعدد من محركات البحث الأخرى تدعمه. Google لا (حتى الآن — لقد كانوا "يقيمون" منذ عام 2022).

إليك كيفية إعداده:

  1. إنشاء مفتاح API (أي سلسلة نصية، مثل UUID)
  2. إنشاء ملف مفتاح في https://yourdomain.com/{your-key}.txt يحتوي على المفتاح فقط
  3. اضغط IndexNow API:
curl "https://api.indexnow.org/indexnow?url=https://yourdomain.com/&key=your-api-key"

للإرسالات الضخمة:

curl -X POST "https://api.indexnow.org/indexnow" \
  -H "Content-Type: application/json" \
  -d '{
    "host": "yourdomain.com",
    "key": "your-api-key",
    "urlList": [
      "https://yourdomain.com/",
      "https://yourdomain.com/about",
      "https://yourdomain.com/services"
    ]
  }'

عدد من منصات الاستضافة وأدوات CMS تدعم IndexNow بشكل أصلي الآن. لدى Cloudflare تكامل IndexNow. WordPress لديه البرامج الإضافية. إذا كنت تقوم بتشغيل موقع Next.js، يمكنك إضافة pings IndexNow إلى خط أنابيب البناء/النشر أو معالجات webhook CMS.

الساعة 4-8: إعادة التوجيه — القاتل الصامت

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

خريطة كل عنوان URL قديم إلى ما يعادله الجديد

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

خذ sitemap القديم الخاص بك (أنت حفظته، أليس كذلك؟) واختبر كل عنوان URL:

# Quick bash one-liner to check redirects
while read url; do
  status=$(curl -o /dev/null -s -w "%{http_code}" -L "$url")
  echo "$status $url"
done < old-urls.txt

أنت تبحث عن:

  • 301 redirects إلى الصفحة الجديدة الصحيحة (وليس 302s — استخدم 301 للحركات الدائمة)
  • بدون سلاسل إعادة توجيه (عنوان URL القديم → عنوان URL الوسيط → عنوان URL النهائي). يجب أن تذهب كل إعادة توجيه مباشرة إلى الوجهة
  • بدون حلقات إعادة التوجيه (عنوان URL A → عنوان URL B → عنوان URL A)

المزالق الشائعة في إعادة التوجيه

المشكلة ما يحدث كيفية اكتشافها
إعادة توجيه الشرطة المائلة المتأخرة المفقودة /about و /about/ عناوين URL مختلفة تحقق من كلا المتغيرات
حساسية حالة الأحرف /About vs /about اختبر مع الحالة الخاطئة
معالجة معاملات الاستعلام عناوين URL القديمة مع ?id=123 تحقق من عناوين URL المعاملات القديمة
معالجة الأجزاء تُحذف المراسي #section راجع الأجزاء المرتبطة القديمة
إعادة توجيه محتوى مختلط HTTP → HTTPS بالإضافة إلى تغيير المسار تأكد من 301 واحد، وليس سلسلة

في Next.js، تتعامل مع إعادة التوجيهات في next.config.js:

module.exports = {
  async redirects() {
    return [
      {
        source: '/old-blog/:slug',
        destination: '/articles/:slug',
        permanent: true,
      },
    ]
  },
}

بالنسبة لإعادة توجيهات واسعة النطاق (المئات أو الآلاف)، فكر في التعامل معها في الحافة — Vercel Edge Config أو Cloudflare Workers أو قواعد إعادة التوجيه CDN الخاصة بك. وضع 2,000 إعادة توجيه في تكوين التطبيق الخاص بك يمكن أن يبطئ الإنشاءات.

الساعة 4-8: التحقق من التحليلات والتتبع

Google Analytics 4 (GA4)

تأكد من أن GA4 الخاص بك يطلق على كل صفحة بشكل صحيح. أسهل فحص:

  1. افتح موقعك في Chrome
  2. افتح DevTools → Network tab
  3. صفّي بواسطة collect أو google-analytics
  4. تنقل بين الصفحات — يجب أن تري طلبات الشبكة لكل عرض صفحة

بالنسبة إلى التطبيقات التي تعمل على صفحة واحدة (التي تعتبر معظم مواقع Next.js و Astro، على الأقل جزئياً)، تحقق من أن التنقلات من جانب العميل تطلق عروض الصفحات. هذا miss شائع جداً — تطلق حمل الصفحة الأولي analytics، لكن التنقلات اللاحقة لا تطلق.

إذا كنت تستخدم Next.js App Router مع حزمة @next/third-parties:

import { GoogleAnalytics } from '@next/third-parties/google'

export default function RootLayout({ children }) {
  return (
    <html>
      <body>{children}</body>
      <GoogleAnalytics gaId="G-XXXXXXXXXX" />
    </html>
  )
}

Google Tag Manager

إذا كنت تستخدم GTM، تحقق من تحميل الحاوية والعلامات الخاصة بك تطلق. استخدم وضع GTM Preview (Tag Assistant) للتصحيح.

إعداد مراقبة Core Web Vitals

هذا مهم لتصنيف تحسين محركات البحث. ستصبح مقاييس يوم الإطلاق الخاصة بك خطأ الأساس الخاص بك. قم بإعداد مراقبة المستخدم الحقيقي:

  • Google Search Console → تقرير Core Web Vitals (يستغرق بضعة أيام للملء)
  • web-vitals مكتبة JavaScript لبيانات الوقت الفعلي
  • Vercel Analytics إذا كنت على Vercel (مدمج في المنصة، $10/month للـ Pro)

اعتباراً من عام 2026، يستخدم تصنيف Google عتبات CWV هذه:

المقياس جيد يحتاج إلى تحسين ضعيف
LCP (Largest Contentful Paint) ≤ 2.5s 2.5s - 4.0s > 4.0s
INP (Interaction to Next Paint) ≤ 200ms 200ms - 500ms > 500ms
CLS (Cumulative Layout Shift) ≤ 0.1 0.1 - 0.25 > 0.25

ملاحظة: استبدل INP FID (First Input Delay) في مارس 2024 كمقياس الاستجابة. إذا كان أي دليل لا يزال يذكر FID، فهو قديم.

الساعة 8-24: ما يتم فهرسته فعلاً أولاً

هذا هو السؤال الذي يسأله الجميع، والجواب قد يفاجئك.

أولوية الزحف في Google

من تجربتي عبر عشرات الإطلاقات، إليك ترتيب الفهرسة النموذجي:

  1. الصفحة الرئيسية — تقريباً دائماً الأولى، عادةً في غضون 4-24 ساعة بعد إرسال sitemap وطلب الفهرسة
  2. الصفحات المرتبطة من الصفحة الرئيسية — صفحات الملاحة الرئيسية الخاصة بك تحصل على الزحف التالي
  3. الصفحات مع الروابط الخارجية — إذا كان موقعك الجديد لديه بالفعل روابط من مواقع أخرى تشير إليها، فإن صفحات الوجهة تحصل على الأولوية
  4. صفحات Sitemap فقط — الصفحات التي يمكن اكتشافها فقط عبر sitemap (وليس المرتبطة من الملاحة) يتم الزحف إليها أخيراً

ما يبطئ الفهرسة

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

الخط الزمني الواقعي للفهرسة لنطاق جديد (2026)

الإطار الزمني ما يتوقعه
0-4 ساعات Sitemap جلب، الصفحة الرئيسية الزحف
4-24 ساعات الصفحة الرئيسية مفهرسة، صفحات المستوى الأعلى الزحف
1-3 أيام صفحات الملاحة الرئيسية مفهرسة
1-2 أسابيع معظم عناوين URL sitemap الزحف
2-4 أسابيع تغطية الفهرس الكاملة لصفحات الجودة
1-3 أشهر تصنيفات البحث تبدأ في الاستقرار

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

الساعة 24-48: المراقبة وإصلاح المشاكل

تحقق من تغطية Google Search Console

بحلول الآن، يجب أن تري البيانات تتدفق. انظر إلى تقرير Pages وعالج أي مشاكل:

  • Soft 404s — صفحات تعيد 200 لكن Google تعتقد أنها صفحات خطأ (عادةً لأن لديها محتوى قليل جداً)
  • أخطاء الخادم (5xx) — موقعك يعيد أخطاء إلى Googlebot حتى لو بدا جيداً في متصفحك (يمكن أن يحدث هذا مع تحديد معدل عدواني أو كشف بوت)
  • أخطاء إعادة التوجيه — سلاسل إعادة توجيه مكسورة أو حلقات

مراقبة 404s الخاصة بك

تحقق من سجلات الخادم أو analytics للأخطاء 404. مستخدمون حقيقيون ومحركات بحث تضغط على عناوين URL التي لا توجد. بالنسبة لإعادة الإطلاق، كل 404 هو إعادة توجيه مفقودة تكلفك equity الارتباط.

جلب وعرض الصفحات الرئيسية

استخدم ميزة Live Test في أداة URL Inspection لترى بالضبط كيف تعرض Google صفحاتك. هذا أمر بالغ الأهمية لمواقع JavaScript الثقيلة. إذا كنت تستخدم العرض من جانب العميل للمحتوى المهم، فقد لا ترى Google ذلك.

هذا سبب واحد لنوصي غالباً بعرض من جانب الخادم أو إنشاء ثابت للمواقع الثقيلة المحتوى. عملنا Next.js development و Astro development تقريباً دائماً يستخدم SSR أو SSG لهذا السبب بالضبط.

جدول قائمة التحقق الكاملة من 48 ساعة

الوقت المهمة الأولوية الأداة
الساعة 0 إزالة علامات noindex في المرحلة حرجة عرض المصدر، curl
الساعة 0 التحقق من SSL وإعادة توجيهات الكنسية حرجة متصفح، curl
الساعة 0 فحص نقطي لعناوين الصفحات والأوصاف الميتا عالية Screaming Frog، curl
الساعة 1 التحقق من أن robots.txt متاح وصحيح حرجة متصفح
الساعة 1 التحقق من صحة Sitemap XML وكمله حرجة متصفح، مدقق XML
الساعة 2 إعداد Google Search Console حرجة GSC
الساعة 2 إرسال Sitemap إلى Google حرجة GSC
الساعة 2 طلب الفهرسة لـ top 10 صفحات عالية GSC URL Inspection
الساعة 3 إعداد أدوات Bing Webmaster عالية Bing
الساعة 3 تنفيذ IndexNow متوسطة API، تكوين الاستضافة
الساعة 4 التحقق من جميع إعادة التوجيهات (إعادة إطلاق فقط) حرجة curl، Screaming Frog
الساعة 4 التحقق من أن GA4 تتبع جميع الصفحات عالية GA4 Real-time، DevTools
الساعة 4 إعداد مراقبة Core Web Vitals متوسطة GSC، web-vitals
الساعة 8 التحقق من إحصائيات الزحف الأولية في GSC عالية GSC
الساعة 24 مراجعة تقرير التغطية GSC عالية GSC
الساعة 24 التحقق من أخطاء 404 في السجلات/analytics عالية سجلات الخادم، GA4
الساعة 48 اختبار الجلب والعرض للصفحات الرئيسية متوسطة GSC URL Inspection
الساعة 48 التحقق من أن عدد الصفحة المفهرسة يطابق التوقعات عالية site:yourdomain.com

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

كم من الوقت يستغرق Google لفهرس موقع ويب جديد في عام 2026؟ بالنسبة لنطاق جديد تماماً، توقع أن تكون الصفحة الرئيسية مفهرسة في غضون 24 ساعة إذا قمت بإرسال sitemap الخاص بك من خلال Google Search Console وطلبت الفهرسة. عادةً ما تستغرق فهرسة الموقع الكامل 2-4 أسابيع. تري النطاقات المثبتة التي يتم إعادة تشغيلها عادةً إعادة فهرسة كاملة خلال 3-7 أيام. تفترض هذه الخطوط الزمنية أنك قمت بكل شيء في هذه القائمة — بدون إرسال Search Console، قد ينتظر نطاق جديد أسابيع قبل أن تكتشف Google حتى.

هل يجب أن أرسل موقعي إلى Google أو أنتظر حتى يتم اكتشافه بشكل طبيعي؟ أرسل دائماً بشكل استباقي. فكرة أنك يجب أن تدع "Google تجدك" نصيحة قديمة من عقد مضى. أرسل sitemap الخاص بك من خلال Google Search Console واستخدم أداة URL Inspection لطلب الفهرسة لصفحاتك الأكثر أهمية. لا توجد جوانب سلبية وتسرع الاكتشاف بأيام أو أسابيع.

هل يعمل IndexNow مع Google؟ لا، ليس حتى منتصف 2026. لقد كانت Google تقيّم IndexNow منذ أواخر عام 2021 لكنها لم تتبنها رسمياً. يعمل IndexNow حالياً مع Bing و Yandex و Naver وآخرين. لا يزال يستحق التنفيذ لأن فهرس Bing يوفر DuckDuckGo و Yahoo Search ويستخدمه مساعدون AI مثل Microsoft Copilot و (جزئياً) ChatGPT.

ما الفرق بين إعادة توجيه 301 و 302 لتحسين محركات البحث؟ 301 هي إعادة توجيه دائمة تمرر معظم equity الارتباط (قوة التصنيف) إلى عنوان URL الوجهة. 302 مؤقتة وتخبر محركات البحث أن عنوان URL الأصلي قد يعود، لذا فهم أقل عرضة لنقل إشارات التصنيف. بالنسبة لعمليات إعادة الإطلاق وتغييرات URL التي لا تخطط لعكسها، استخدم دائماً 301. أرى فريق يستخدم 302s بالخطأ طوال الوقت لأن هذا هو الافتراضي في بعض الأطر.

لماذا تظهر صفحاتي كـ "Discovered - currently not indexed" في Google Search Console؟ هذا يعني أن Google تعرف أن صفحاتك موجودة (من sitemap أو روابط داخلية) لكنها لم تزحفها بعد. بالنسبة للمواقع الجديدة، هذا أمر طبيعي في الأيام القليلة الأولى — يضع Google عناوين URL في الطابور ويزحفها بناءً على الأولوية. إذا ظلت الصفحات في هذه الحالة لأكثر من 2-3 أسابيع، فهذا عادةً يعني أن Google لا تعتبرها ذات أولوية عالية بما يكفي. يساعد تحسين الربط الداخلي وإضافة محتوى فريد وقيم إلى تلك الصفحات.

هل أحتاج إلى Google Search Console و Bing Webmaster Tools؟ نعم. يخدمان محركات بحث مختلفة ويعطيانك بيانات مختلفة. يغطي Google Search Console تقريباً 90٪ من حركة البحث في معظم الأسواق، لكن أدوات Bing Webmaster Tools تغطي الباقي وتوفر إمكانية الوصول إلى تكامل IndexNow، مما قد يسرع الفهرسة على محركات Bing. استغرق الإعداد حوالي 5 دقائق لـ Bing لأنه يمكنك استيراد تكوين GSC مباشرةً.

كيف أتحقق مما إذا كان محتوى JavaScript الخاص بي يتم فهرسته بواسطة Google؟ استخدم أداة URL Inspection في Google Search Console وانقر على "Test Live URL". ثم عرض HTML المعروض — هذا يوضح لك بالضبط ما يراه Googlebot بعد تنفيذ JavaScript الخاص بك. إذا كان محتوى حرج مفقوداً من الإخراج المعروض، تحتاج إلى التبديل إلى عرض من جانب الخادم لهذا المحتوى. هذا شائع خاصة مع SPAs React التي تجلب المحتوى من جانب العميل. تتعامل أطر مثل Next.js و Astro بشكل جيد مع SSR و SSG من الصندوق.

هل يجب أن أحظر زواحف AI في robots.txt الخاص بي في يوم الإطلاق؟ هذا حكم يعتمد على عملك. يمكن حظر bots مثل GPTBot (OpenAI) و ClaudeBot (Anthropic) و Google-Extended (تدريب Gemini) عبر robots.txt إذا كنت لا تريد استخدام المحتوى الخاص بك لتدريب AI. ومع ذلك، قد يؤثر حظر GPTBot على كيفية ظهور المحتوى الخاص بك في نتائج بحث ChatGPT. توصيتي: ابدأ بكل شيء مسموح به، راقب حمل الخادم من زواحف AI، وأضف حظر انتقائياً إذا لزم الأمر. لا تدع هذا القرار يؤخر الإطلاق — يمكنك تحديث robots.txt لاحقاً.

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