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

الخلاصة — HTTPS هو الإصدار الآمن والمشفّر من HTTP، ويظهر برمز القفل في المتصفح. تمنح Google صفحات HTTPS دفعة ضئيلة جدًا في الترتيب تاريخيًا، لكن السببين الحقيقيين للانتقال هما أن Chrome يصف مواقع HTTP العادية بأنها “غير آمنة”، وأن HTTPS أصبح ما يتوقعه الويب. يكون الانتقال آمنًا إذا نُفذ جيدًا: وجّه كل عنوان http:// قديم إلى نسخته https:// من دون كسر أي شيء في الطريق.

ما HTTPS؟

عندما تفتح موقعًا، يتواصل المتصفح مع خادم. مع HTTP العادي يجري هذا الاتصال مكشوفًا، ويمكن لأي جهة في الشبكة بينهما، مثل مزود خدمة الإنترنت أو شبكة Wi-Fi عامة أو مهاجم، قراءته أو العبث به. HTTPS هو الاتصال نفسه بعد تشفيره. ويشير الحرف S إلى Secure، أي «آمن». تحصل عليه بتثبيت شهادة TLS، التي ما زال كثيرون يسمونها «شهادة SSL»، على الخادم.

يمكنك معرفة ما إذا كانت الصفحة تستخدمه من شريط العنوان: يبدأ عنوانها بـhttps:// ويظهر عادة رمز قفل. أما صفحة http:// العادية فيعرض Chrome عليها تسمية “Not Secure” (الترجمة العربية) «غير آمنة».

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

هل يساعد HTTPS في تحسين محركات البحث؟

قليلًا من الناحية التاريخية. أكدت Google عام 2014 أنها تستخدم HTTPS إشارة ترتيب، لكنها إشارة صغيرة جدًا، ووصفها فريق Google حينئذ بأنها عامل حسم عند التعادل: إذا تساوت صفحتان في سائر الجوانب فقد تتقدم الآمنة قليلًا. لن ترفع صفحة ضعيفة فوق صفحة قوية، كما أن إرشادات Google الحالية لا تعيد تأكيد دفعة مباشرة في الترتيب من HTTPS اليوم. ومن يعد بمكاسب كبيرة “بمجرد إضافة SSL” يبالغ.

الأسباب المهمة فعلًا:

• يقول Chrome “Not Secure”، أي «غير آمنة». منذ 2018 يظهر هذا التحذير على كل صفحة HTTP، وقد ينفر الزوار بصرف النظر عن رأي Google.
• أصبح هو خط الأساس. تشير التقديرات إلى أن 9 مواقع من كل 10 تستخدم HTTPS بالفعل (W3Techs، 2026)، فيبدو الموقع المتخلف عنه معطلًا.
• تحتاجه الميزات الحديثة. لا تعمل كثير من إمكانات المتصفح، ولا الاتصالات الأسرع عبر HTTP/2 عمليًا، من دون HTTPS.

هل سيضر الانتقال بترتيبي؟

لا، إذا نفذته بعناية. يُعد الانتقال من HTTP إلى HTTPS نوعًا من ترحيل الموقع، وتنطبق عليه القاعدة الذهبية لأي ترحيل: أعد توجيه كل URL قديم إلى نسخته الآمنة الجديدة بإعادة توجيه 301. بالتنفيذ الصحيح تحافظ على ترتيبك، أما إهمال عمليات إعادة التوجيه أو كسر روابط الصور والبرامج النصية فقد يفقدك الزيارات. الانتقال نفسه آمن؛ والأخطاء المحيطة به هي التي تضر. Evidence for this claim Google recommends permanent server-side redirects during site moves and says HTTP-to-HTTPS moves do not use the Change of Address tool. Scope: Google's site-move guide supports redirect and Search Console handling; it does not guarantee that a migration with implementation errors retains traffic. Confidence: high · Verified: 2026-07-14 Google Search Central: Site moves with URL changes

هل تريد الصورة الكاملة، من وزن الإشارة الحقيقي وخطوات الترحيل إلى المحتوى المختلط وHSTS؟ انتقل إلى تبويب المتقدم.

الخلاصة — تقول إرشادات Google الحالية لتجربة الصفحة إن الجوانب الأخرى غير Core Web Vitals “don’t directly help your website rank higher” (الترجمة العربية) «لا تساعد موقعك مباشرة على تحقيق ترتيب أعلى»، لذلك لا تعد بدفعة حالية من HTTPS. المؤكد تاريخي: أعلنت Google في أغسطس 2014 أن HTTPS إشارة ترتيب “very lightweight” (الترجمة العربية) «خفيفة جدًا» تؤثر في أقل من 1% من الطلبات، ووصفها Gary Illyes عام 2015 بأنها عامل حسم عند التعادل؛ وهذا تعليق مؤرخ لا آلية حالية موثقة. ومنفصلًا عن ذلك، تفضل إرشادات canonical الحالية لدى Google صفحات HTTPS على نظيراتها HTTP، لكن بشروط: قد تعكس شهادة غير صالحة أو تبعيات غير آمنة أو إعادة توجيه HTTPS→HTTP أو وسم canonical شارد يشير إلى HTTP هذا التفضيل، ولا يستطيع HSTS تجاوزه. الدافع الحقيقي هو تسمية Chrome “Not Secure”، وHTTP/2 في المتصفحات الكبرى، وواجهات المتصفح الحديثة، وكون HTTPS معيارًا أساسيًا لا رافعة نمو. الترحيل هو ترحيل موقع: استخدم 301 لكل URL من دون فقدان PageRank، وأصلح المحتوى المختلط النشط والسلبي، وحدّث canonical وخرائط الموقع والروابط الداخلية، وأعد التحقق في Search Console؛ ولا تستخدم أداة تغيير العنوان لتبديل البروتوكول. ويوفر HSTS وإعادة التوجيه الداخلية 307 حماية في طبقة المتصفح فوق إعادة التوجيه 301 من الخادم، لا بديلًا منها.

هل تعد Google حاليًا بدفعة ترتيب من HTTPS؟

ابدأ بما تقوله Google اليوم، لا عام 2014. تنص وثائق تجربة الصفحة الحالية على أن جوانب تجربة الصفحة الأخرى غير Core Web Vitals، ومنها HTTPS، “don’t directly help your website rank higher in search results.” (الترجمة العربية) «لا تساعد موقعك مباشرة على تحقيق ترتيب أعلى في نتائج البحث». وهذه أحدث إرشادات مباشرة متاحة، ولا تسند وعدًا حاليًا بدفعة ترتيب لمجرد استخدام HTTPS.

إشارة 2014 ووصف «عامل الحسم» — تاريخ لا آلية حالية

المؤكد هو التاريخ: أعلنت Google استخدام HTTPS إشارة ترتيب في 6 أغسطس 2014، وكانت صريحة على نحو غير معتاد بشأن ضعف وزنها عند الإطلاق. وصفتها بأنها “very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content.” (الترجمة العربية) «إشارة خفيفة جدًا تؤثر في أقل من 1% من طلبات البحث عالميًا، ووزنها أقل من إشارات أخرى مثل المحتوى عالي الجودة». وأضافت أنها “may decide to strengthen it” (الترجمة العربية) «قد تقرر تقويتها» مع الوقت لتشجيع التبني؛ قالت «تقويتها»، لا «دفعة» كما أعادت صحافة SEO صياغتها. Evidence for this claim Google announced HTTPS as a very lightweight ranking signal affecting fewer than one percent of global queries at launch. Scope: Google's 2014 announcement establishes the signal and its weight at launch; it does not quantify the signal's current weight. Confidence: high · Verified: 2026-07-14 Google Search Central: HTTPS as a ranking signal

بعد عام، في سبتمبر 2015، وصف Gary Illyes الإشارة بأنها عامل حسم: “it acts more like a tiebreaker. For example, if all quality signals are equal for two results, then the one that is on HTTPS would get … or may get … the extra boost.” (الترجمة العربية) «تعمل أقرب إلى عامل حسم؛ فإذا تساوت كل إشارات الجودة لنتيجتين، فقد تحصل النتيجة الموجودة على HTTPS على الدفعة الإضافية». وفي العام نفسه حسم الأولويات بقوله: “you should switch to HTTPS for users, not as a ranking signal.” (الترجمة العربية) «ينبغي الانتقال إلى HTTPS من أجل المستخدمين، لا بوصفه إشارة ترتيب». ويؤدي تأطير John Mueller في الفترة نفسها، وهو ألا تتوقع تغيرًا ظاهرًا في الترتيب من الانتقال وحده، إلى النتيجة ذاتها.

تعامل مع «عامل الحسم» بوصفه وصفًا تمثيليًا مؤرخًا من Illyes في 2015–2016، لا آلية ترتيب نشطة توثقها Google حاليًا؛ فصياغة تجربة الصفحة أعلاه هي المصدر الحالي الأكثر تحفظًا. لذا فالإجابة الصادقة والمؤرخة عن أثر HTTPS في SEO هي أن Google أكدت إشارة طفيفة عام 2014، ووصفها أحد موظفيها بعامل حسم عام 2015، ولا تعيد الإرشادات الحالية تأكيد تلك الآلية مباشرة. HTTPS بند نظافة أساسي لا رافعة نمو، مهما كان الوزن الحالي الدقيق للإشارة التاريخية.

تفضيل Google لصفحات HTTPS بوصفها canonical — مشروط لا قائم على البروتوكول وحده

بمعزل عن إشارة ترتيب 2014، توثق Google اليوم تفضيلًا في اختيار canonical: “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals such as” (الترجمة العربية) «تفضل Google صفحات HTTPS على صفحات HTTP المكافئة بوصفها canonical، إلا عند وجود مشكلات أو إشارات متعارضة مثل» شهادة SSL غير صالحة، أو تبعيات غير آمنة عدا الصور، أو صفحة HTTPS تعيد توجيه المستخدمين إلى صفحة HTTP أو عبرها، أو صفحة HTTPS تحمل rel="canonical" يشير إلى نسخة HTTP.

هذه دقة تغفلها معظم الأدلة، وتخالف التبسيط الشائع، ومنه قول Illyes عام 2016 إن الإشارة “basically looking at the first five characters in front of the URL” (الترجمة العربية) «تنظر أساسًا إلى الأحرف الخمسة الأولى أمام URL»؛ فهذا الاختصار يصف إشارة ترتيب 2014 لا قرار canonical. وتوضح Google أن الشهادة السيئة أو إعادة التوجيه إلى بروتوكول أقل أمانًا تتغلب على تفضيل HTTPS: “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly.” (الترجمة العربية) «تجنب شهادات TLS/SSL السيئة وإعادة التوجيه من HTTPS إلى HTTP لأنها تجعل Google تفضل HTTP بشدة». ولا يصلح HSTS ذلك: “Implementing HSTS cannot override this strong preference.” (الترجمة العربية) «لا يستطيع تطبيق HSTS تجاوز هذا التفضيل القوي».

النتيجة العملية أن الشهادة المنتهية أو السيئة الإعداد ليست مشكلة تجربة مستخدم فقط؛ فقد تدفع Google أيضًا إلى فهرسة صفحة HTTP بدل نسخة HTTPS التي تريد ترتيبها. راجع أنواع إخفاق الشهادات وتشخيصها في شهادات SSL/TLS، واقرأ تقرير Search Console المخصص لهذا القرار في تقرير HTTPS.

لماذا يهم HTTPS فعلًا؟

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

ضمن هذا النطاق، هذه هي الحجة العملية:

• تحذير Chrome “Not Secure”، أي «غير آمنة». منذ Chrome 68 في يوليو 2018، يصف Chrome كل صفحات HTTP بأنها غير آمنة. تظهر التسمية في شريط العنوان أمام الزوار، وهي مشكلة تحويل أكبر كثيرًا من أي دفعة ترتيب.
• هو المتطلب العملي لـHTTP/2 وHTTP/3. لا يقدم أي متصفح رئيسي HTTP/2 عبر HTTP عادي؛ بل تتفاوض المتصفحات الكبرى عليه عبر TLS، رغم أن مواصفة HTTP/2 لا تفرض التشفير. وتقول وثائق Google: “in some cases, TLS can improve performance, mostly as a result of making HTTP/2 possible.” (الترجمة العربية) «قد يحسن TLS الأداء في بعض الحالات، ويرجع ذلك أساسًا إلى إتاحة HTTP/2». هذا احتمال مشروط لا ضمان؛ فما زال حمل TLS وإعداد الخادم وإعادة استخدام الاتصال مهمًا، لكن تعدد الإرسال وضغط الترويسات قد يجعلان HTTPS مع HTTP/2 أسرع من HTTP/1.1 العادي.
• تحتاجه ميزات المتصفح الحديثة. تتطلب service workers وواجهات الموقع الجغرافي والكاميرا والميكروفون وتطبيقات الويب التقدمية سياقًا آمنًا عادة، مع التحقق من استثناءات كل ميزة ومتصفح مثل localhost. تقول Google: “HTTPS is required for many new browser features, especially those required for progressive web apps.” (الترجمة العربية) «HTTPS مطلوب لكثير من ميزات المتصفح الجديدة، ولا سيما اللازمة لتطبيقات الويب التقدمية».
• بيانات الإحالة و”dark traffic”، أي «الزيارات المظلمة» — افتراضيًا لا دائمًا. تحذف المتصفحات التي تستخدم Referrer-Policy الافتراضية الحديثة (strict-origin-when-cross-origin) ترويسة Referer كليًا عند الانتقال من HTTPS إلى HTTP، بينما يرسل الانتقال ضمن البروتوكول نفسه أو إلى بروتوكول أعلى أمانًا الأصل على الأقل. وقد تُنسب الزيارات خطأ إلى «مباشرة»، لكن ترويسة الموقع نفسه تستطيع تجاوز الافتراض في الاتجاهين، فلا تعامل ذلك كقاعدة مطلقة.
• أصبح معيارًا أساسيًا. تستخدمه نحو 89% من المواقع وفق تقدير W3Techs لعام 2026؛ تعامل معه كتقدير اتجاهي لا عدد آني دقيق. قصة SEO ليست مكسب الانتقال، بل خطر البقاء استثناء ظاهرًا.

الانتقال من HTTP إلى HTTPS

الانتقال من HTTP إلى HTTPS هو ترحيل موقع ويستحق الانضباط نفسه. والخبر الجيد، مباشرة من إرشادات Google لنقل المواقع، هو: “301 and other permanent redirects don’t cause a loss in PageRank.” (الترجمة العربية) «لا تسبب عمليات 301 وغيرها من عمليات إعادة التوجيه الدائمة فقدان PageRank». فالخوف القديم من خسارة قيمة الروابط خرافة؛ يكمن الخطر في التنفيذ، مثل غياب 301 والمحتوى المختلط ووسوم canonical القديمة وعدم التحقق من خاصية HTTPS في Search Console، لا في تغيير البروتوكول.

الانضباط الأساسي في فقرة: سجّل خط أساس لموقع HTTP الحي، بما يشمل الزحف والترتيب وتصدير Search Console والروابط الخلفية؛ واحصل على شهادة TLS، إذ تمنح شهادة DV مجانية من Let’s Encrypt الإشارة نفسها التي تمنحها شهادة OV/EV مدفوعة؛ ثم أعد توجيه كل URL من HTTP إلى نظيره HTTPS واحدًا لواحد برمز 301، واجعل HTTPS هو canonical في الروابط الداخلية وخريطة الموقع وhreflang، وأصلح المحتوى المختلط قبل التحويل، وأعد التحقق من خصائص Search Console الأربع من دون أداة تغيير العنوان، وأبق عمليات إعادة التوجيه سنة على الأقل. توقع تقلبًا مؤقتًا؛ فالهبوط الذي يتعافى تسوية طبيعية، أما المستمر فيعني أن شيئًا تعطل.

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

المحتوى المختلط

المحتوى المختلط هو أن تحمّل صفحة HTTPS موردًا فرعيًا عبر HTTP. وله نوعان يحدد الفرق بينهما ترتيب الأولويات:

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

اعثر عليه بالزحف إلى موقع HTTPS عبر Ahrefs Site Audit أو Screaming Frog، أو بمراقبة وحدة تحكم Chrome DevTools، أو بجمع تقارير CSP. أنظف إصلاح استباقي هو ترويسة Content-Security-Policy: upgrade-insecure-requests التي تجعل المتصفح يعيد كتابة طلبات الموارد الفرعية من http:// إلى https:// بصمت قبل إرسالها؛ وهي شبكة أمان مفيدة أثناء الترحيل وبعده. ولا تُعد روابط الارتساء العادية إلى صفحات HTTP محتوى مختلطًا؛ فهي تنقل المستخدم فحسب.

HSTS ولماذا لا يغني عن عمليات 301

HSTS، أي HTTP Strict Transport Security، ترويسة استجابة (Strict-Transport-Security) تأمر المتصفحات باستخدام HTTPS دائمًا لنطاقك، حتى إذا كتب المستخدم رابط http:// أو نقره. وهي تغلق «مشكلة الطلب الأول»: مع 301 وحدها يخرج أول طلب لزائر جديد عبر HTTP قبل تنفيذ إعادة التوجيه، وهي النافذة التي يستهدفها مهاجم stripping SSL. ووفق وثائق Google يتيح HSTS “avoid the cost of the 301 redirect” (الترجمة العربية) «تجنب كلفة إعادة التوجيه 301» للزوار العائدين، كما “defeats attacks like SSL Stripping.” (الترجمة العربية) «يهزم هجمات مثل stripping SSL».

ينبغي لمختصي SEO التمييز بين أمرين:

• لا يغني HSTS عن عمليات 301 من الخادم. عندما يطبق المتصفح HSTS ينفذ إعادة توجيه 307 داخلية إلى HTTPS، لكن ذلك يحدث داخل المتصفح ولا تراه برامج الزحف. ما زالت محركات البحث تحتاج إلى 301 حقيقية من الخادم لفهم الانتقال ونقل قيمة الروابط. تحتاج إلى كليهما.
• تحميل HSTS المسبق شبه دائم. يمكنك إرسال نطاقك إلى قائمة التحميل المسبق المضمنة في المتصفح، بشرط max-age لا يقل عن سنة وincludeSubDomains وpreload، فتغلق الفجوة حتى للزوار الجدد. لكن الخروج من القائمة بطيء ومؤلم. تحذر Google: “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (الترجمة العربية) «لا تفعل HSTS قبل أن تتأكد من متانة تشغيل الموقع بما يكفي لتجنب نشر HTTPS مع أخطاء تحقق الشهادة». تعامل مع التحميل المسبق كباب أحادي الاتجاه.

خرافات شائعة

• “HTTPS دفعة كبيرة حالية في الترتيب.” لا؛ فوصف 2014 “very lightweight” وتأثيره في أقل من 1% من الطلبات، ووصف 2015 بأنه عامل حسم، تعليقات مؤرخة. تقول الإرشادات الحالية إن جوانب تجربة الصفحة خارج Core Web Vitals “don’t directly help you rank higher” (الترجمة العربية) «لا تساعدك مباشرة على تحقيق ترتيب أعلى».
• “سيحطم الانتقال ترتيبي.” ليس إذا نُفذت إعادة التوجيه جيدًا؛ لا تفقد 301 قيمة PageRank. يضر الترحيل الفاشل، لا تغيير البروتوكول.
• “تحتاج إلى أداة تغيير العنوان.” ليس عند الانتقال من HTTP إلى HTTPS؛ فهي لنقل النطاق فقط.
• “الشهادة المنتهية تضر تجربة المستخدم فقط.” لا؛ فالشهادة السيئة من الشروط المسماة التي قد تحول تفضيل Google للـcanonical إلى صفحة HTTP، فضلًا عن كسر الصفحة للمستخدمين.
• “HTTPS مهم لصفحات الدفع فقط.” لا؛ يوسم Chrome كل صفحة HTTP، وتتطلب واجهات حديثة كثيرة سياقًا آمنًا.
• “TLS يبطئ المواقع.” يحدث العكس غالبًا عمليًا لأن HTTPS يتيح HTTP/2، مع بقاء التحسين احتمالًا لا ضمانًا.

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

ملخص الذكاء الاصطناعي

خلاصة مكثفة للنسخة المتقدمة:

• لا تعد إرشادات Google الحالية بدفعة ترتيب. تقول وثيقة تجربة الصفحة إن الجوانب خارج Core Web Vitals “don’t directly help your website rank higher” (الترجمة العربية) «لا تساعد موقعك مباشرة على تحقيق ترتيب أعلى»، وHTTPS منها.
• إشارة 2014 ووصف «عامل الحسم» عام 2015 تاريخيان. كانت الإشارة خفيفة جدًا وتؤثر في أقل من 1% من الطلبات؛ لا تعامل HTTPS رافعة نمو.
• تفضيل Google للـHTTPS بوصفه canonical منفصل ومشروط. قد تتغلب عليه شهادة غير صالحة أو تبعيات غير آمنة أو إعادة توجيه HTTPS→HTTP أو canonical يشير إلى HTTP، ولا يستطيع HSTS تجاوزه.
• يحمي HTTPS النقل فقط، لا منطق التطبيق أو نقاط النهاية أو نية المستخدم؛ فقد تعمل صفحة تصيد بشهادة صالحة.
• الأسباب الحقيقية: تسمية Chrome “Not Secure” لكل صفحات HTTP منذ يوليو 2018، وHTTP/2 في المتصفحات الكبرى، وميزات السياق الآمن، وسلوك الإحالة الافتراضي القابل للتجاوز، وكون HTTPS معيارًا تستخدمه نحو 89% من المواقع.
• الترحيل ترحيل موقع. أعد توجيه كل URL واحدًا لواحد برمز 301 من دون فقد PageRank، واجعل HTTPS هو canonical، وحدّث الروابط وخرائط الموقع وhreflang، وأصلح المحتوى المختلط، وأعد التحقق في GSC، وأبق إعادة التوجيه سنة على الأقل، ولا تستخدم أداة تغيير العنوان.
• المحتوى المختلط: يُحظر النشط مثل البرامج النصية والإطارات، فأصلحه أولًا؛ أما السلبي مثل الصور فيطلق تحذيرًا. وتمثل upgrade-insecure-requests شبكة أمان استباقية.
• يغلق HSTS فجوة الطلب الأول عبر 307 داخلية لا تراها برامج الزحف؛ فهو فوق 301 من الخادم لا بدلًا منها. والتحميل المسبق شبه دائم، فلا تتعجل.

الوثائق الرسمية

وثائق المصادر الأولية من محركات البحث وفرق المتصفحات.

Google

• HTTPS بوصفه إشارة ترتيب (إعلان 2014) — المنشور الأصلي الذي وصف الإشارة بأنها خفيفة جدًا.
• تفعيل HTTPS على خوادمك في web.dev — الشهادات و301s وcanonical وHSTS وملفات تعريف الارتباط.
• لماذا يهم HTTPS — الأمن وميزات المتصفح.
• إصلاح المحتوى المختلط — النوعان النشط والسلبي وupgrade-insecure-requests.
• نقل المواقع مع تغيير عناوين URL — دليل الترحيل، وإعادة التوجيه، وعدم استخدام أداة تغيير العنوان لـHTTPS.
• فهم تجربة الصفحة — موضع HTTPS في هذا الإطار والمصدر الحالي لعدم توقع دفعة مباشرة.
• تحديد عنوان canonical — التفضيل الحالي المشروط بين HTTPS وHTTP والاستثناءات التي تتغلب عليه.

Chrome / Chromium

• الانتقال نحو ويب أكثر أمانًا (2016) — بداية طرح تسمية “Not Secure”.
• الويب الآمن باقٍ (2018) — وسم Chrome 68 لكل صفحات HTTP بأنها غير آمنة.

Bing / Microsoft

• إرشادات Bing لمشرفي المواقع — إرشادات عامة؛ تحقق داخل المتصفح من صياغة HTTPS الحالية.

اقتباسات من المصدر

تصريحات مسجلة من Google. كل رابط عميق يقفز إلى المقطع المقتبس في صفحة المصدر.

Google — إعلان إشارة الترتيب عام 2014

• “We’re starting to use HTTPS as a ranking signal. For now it’s only a very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content.” (الترجمة العربية) «بدأنا استخدام HTTPS إشارة ترتيب. وهي الآن إشارة خفيفة جدًا تؤثر في أقل من 1% من طلبات البحث عالميًا، ووزنها أقل من إشارات مثل المحتوى عالي الجودة». — Zineb Ait Bahajji وGary Illyes من Google. انتقل إلى الاقتباس
• “But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS.” (الترجمة العربية) «لكننا قد نقرر تقويتها مع الوقت لأننا نريد تشجيع مالكي المواقع جميعًا على الانتقال من HTTP إلى HTTPS». — المنشور نفسه. انتقل إلى الاقتباس

Gary Illyes — وصف عامل الحسم

• “With the HTTPS ranking boost, it acts more like a tiebreaker. For example, if all quality signals are equal for two results, then the one that is on HTTPS would get … or may get … the extra boost that is needed to trump the other result.” (الترجمة العربية) «تعمل دفعة HTTPS أقرب إلى عامل حسم؛ فإذا تساوت إشارات الجودة لنتيجتين فقد تحصل نتيجة HTTPS على الدفعة اللازمة للتقدم». — Gary Illyes من Google عبر Search Engine Land. اقرأ التغطية
• “You should switch to HTTPS for users, not as a ranking signal.” (الترجمة العربية) «ينبغي الانتقال إلى HTTPS من أجل المستخدمين، لا بوصفه إشارة ترتيب». — Gary Illyes في SMX East 2015. اقرأ التغطية
• “Basically looking at the first five characters in front of the URL, and if it’s HTTPS … it will get a minimal boost.” (الترجمة العربية) «تنظر أساسًا إلى الأحرف الخمسة الأولى أمام URL، وإذا كانت HTTPS تحصل على دفعة ضئيلة». — Gary Illyes عام 2016. اقرأ التغطية

Google — تفضيل HTTPS بوصفه canonical في الإرشادات الحالية

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals such as the following.” (الترجمة العربية) «تفضل Google صفحات HTTPS على نظيراتها HTTP بوصفها canonical، إلا عند وجود مشكلات أو إشارات متعارضة مثل الآتي». — Google Search Central. انتقل إلى الاقتباس
• “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly.” (الترجمة العربية) «تجنب شهادات TLS/SSL السيئة وإعادة التوجيه من HTTPS إلى HTTP لأنها تجعل Google تفضل HTTP بشدة». — Google Search Central. انتقل إلى الاقتباس
• “Implementing HSTS cannot override this strong preference.” (الترجمة العربية) «لا يستطيع تطبيق HSTS تجاوز هذا التفضيل القوي». — Google Search Central. انتقل إلى الاقتباس

Google — إرشادات الترحيل وHSTS

• “301 and other permanent redirects don’t cause a loss in PageRank.” (الترجمة العربية) «لا تسبب عمليات 301 وغيرها من عمليات إعادة التوجيه الدائمة فقدان PageRank». — Google Search Central. انتقل إلى الاقتباس
• “If you’re moving your site from HTTP to HTTPS, you don’t need to use the Change of Address tool.” (الترجمة العربية) «إذا كنت تنقل موقعك من HTTP إلى HTTPS، فلا تحتاج إلى أداة تغيير العنوان». — Google Search Central. انتقل إلى الاقتباس
• “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (الترجمة العربية) «لا تفعل HSTS قبل أن تتأكد من متانة تشغيل الموقع بما يكفي لتجنب نشر HTTPS مع أخطاء تحقق الشهادة». — web.dev من Google. انتقل إلى الاقتباس
• “In some cases, TLS can improve performance, mostly as a result of making HTTP/2 possible.” (الترجمة العربية) «قد يحسن TLS الأداء في بعض الحالات، ويرجع ذلك أساسًا إلى إتاحة HTTP/2». — web.dev من Google. انتقل إلى الاقتباس

Chrome — طرح تسمية “Not Secure”، أي «غير آمنة»

• “Beginning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as ‘not secure’.” (الترجمة العربية) «ابتداء من يوليو 2018 مع إصدار Chrome 68، سيسم Chrome كل مواقع HTTP بأنها غير آمنة». — Emily Schechter من Chrome Security. انتقل إلى الاقتباس

قائمة التحقق للانتقال من HTTP إلى HTTPS

هذه نسخة موجزة قبل الإطلاق؛ وللاطلاع على قائمة التنفيذ الكاملة وتجربة بيئة الاختبار وخطة التراجع، راجع الانتقال من HTTP إلى HTTPS.

قبل الانتقال

• حفظ زحف كامل لموقع HTTP الحي، بما يشمل كل استجابة 200 وكل إعادة توجيه قائمة.
• أرشفة لقطة للترتيب وتصدير Search Console وملف الروابط الخلفية.
• الحصول على شهادة TLS واختبارها؛ تكفي شهادة DV مجانية للإشارة.

التبديل

• يعيد كل URL بنظام HTTP التوجيه من الخادم، واحدًا لواحد، إلى نظيره HTTPS برمز 301.
• لا سلاسل إعادة توجيه؛ ينتقل العنوان القديم مباشرة إلى HTTPS النهائي.
• لا إعادة توجيه جماعية للعناوين غير المطابقة إلى الصفحة الرئيسية.
• تشير كل صفحة إلى نفسها عبر rel="canonical" باستخدام عنوان HTTPS.
• تحديث الروابط الداخلية وخرائط XML وhreflang إلى HTTPS، لا تركها لعمليات إعادة التوجيه.
• إصلاح المحتوى المختلط النشط، مثل البرامج النصية والأنماط والإطارات، لأنه يُحظر.
• إصلاح المحتوى المختلط السلبي، مثل الصور والوسائط، وضبط upgrade-insecure-requests في CSP.

Search Console وما بعد الانتقال

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

النماذج الذهنية

1. HTTPS نظافة أساسية لا رافعة نمو. وُصف بأنه خفيف جدًا ويؤثر في أقل من 1% من الطلبات وعامل حسم. أنفق جهد الترتيب على المحتوى والروابط؛ وطبّق HTTPS لأن الويب يتطلبه ثم تابع عملك.

2. افصل إشارة ترتيب 2014 عن تفضيل canonical الحالي. كانت إشارة 2014 قائمة تاريخيًا على البروتوكول، ويصفها قول Illyes عن «الأحرف الخمسة الأولى»، لكنه تعليق مؤرخ لا آلية حالية موثقة. أما تفضيل Google الحالي للـHTTPS بوصفه canonical فمختلف ومشروط؛ فقد تدفع شهادة سيئة أو تبعيات غير آمنة أو إعادة توجيه إلى HTTP Google إلى فهرسة صفحة HTTP. لذلك ليست الشهادة المعطلة طارئ تجربة مستخدم فقط، بل قد تكلفك canonical الخاص بـHTTPS.

3. تحمل عمليات 301 الترحيل؛ وما عداها إشارات مساندة. تؤدي إعادة التوجيه التي لا تفقد PageRank العمل الحقيقي لنقل الترتيب. وتساعد canonical وخرائط الموقع وتحديث الروابط الداخلية وإعادة التحقق في GSC Google على معالجة النقل بسرعة ونظافة أكبر.

4. لفرض HTTPS طبقتان وتحتاج إليهما معًا. إعادة التوجيه 301 من الخادم لبرامج الزحف وقيمة الروابط. أما HSTS وإعادة التوجيه 307 الخاصة بالمتصفح فللزوار العائدين والحماية من تجريد SSL. تحلان مشكلتين مختلفتين؛ ولا يغني HSTS عن 301.

5. رتب المحتوى المختلط حسب تصرف المتصفح. يُحظر النوع النشط، مثل البرامج النصية والأنماط والإطارات، لذلك إصلاحه وظيفي وأولويته أعلى. أما السلبي، مثل الصور والوسائط، فيطلق تحذيرًا؛ أصلحه بعده. وتمثل upgrade-insecure-requests شبكة الأمان لما يفوتك.

ورقة مرجعية لـHTTPS في SEO

حقيقة الترتيب

حقائق إعادة التوجيه والترحيل

المحتوى المختلط وHSTS

فرض HTTPS وضبط HSTS

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

Apache (.htaccess)

# 301 every HTTP request to HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# HSTS — only add once you're confident HTTPS is solid
<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

Nginx

# Redirect HTTP → HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

# On the HTTPS server block, add HSTS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

لا تضف ; preload إلى ترويسة HSTS إلا إذا كنت تنوي الإرسال إلى hstspreload.org؛ فالقرار شبه غير قابل للعكس.

العثور على المحتوى المختلط من سطر الأوامر

ازحف إلى صفحات HTTPS وابحث باستخدام grep عن أي موارد فرعية تبدأ بـhttp:// ما زالت في HTML.

macOS / Linux

# Pull a page and flag insecure script/img/link/iframe sources
curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

Windows (PowerShell)

# Same idea in PowerShell
(Invoke-WebRequest -Uri "https://example.com/").Content `
  | Select-String -Pattern '(src|href)="http://[^"]+"' -AllMatches `
  | ForEach-Object { $_.Matches.Value } | Sort-Object -Unique

لفحص الموقع كله، يكون الزاحف مثل Ahrefs Site Audit أو Screaming Frog، أو وحدة تحكم Chrome DevTools، أسرع من كتابة برنامج لكل صفحة.

موارد تستحق وقتك

محاضراتي

• السلامة أولًا مع HTTPS — ‏SMX East 2016 على SlideShare — شرحي المتعمق لـTLS وإخفاقات تنفيذ HTTPS الشائعة ومزالق الترحيل. يسري التنبيه الدائم: هذا فهمي للأنظمة، وإحصاءات التبني فيه تعود إلى 2016.

كتاباتي ذات الصلة

• دليل المبتدئين إلى Technical SEO — موضع HTTPS في الصورة الأكبر.

مصادر رسمية من جهات أخرى

• تفعيل HTTPS على خوادمك وإصلاح المحتوى المختلط من Google — مجموعة مركزة ومفيدة من وثائق التنفيذ.
• hstspreload.org — تحقق من الأهلية قبل الالتزام بالتحميل المسبق.
• SSL Labs Server Test — قيّم إعداد TLS.

من مصادر القطاع

• HTTPS بوصفه عامل ترتيب من Search Engine Journal — وزن الإشارة الحقيقي ولماذا تظل عامل حسم لا رافعة.
• تغطية وصف Gary Illyes للـHTTPS بعامل حسم من Search Engine Land.
• تغطية إعلان 2014 ورد فعل القطاع المبكر.
• دليل HSTS من Kinsta — التحميل المسبق ومخاطر الالتزام.
• Let’s Encrypt — جهة شهادات DV مجانية ومؤتمتة للحصول على النطاق الآمن https://.
• HTTPS سهل من Troy Hunt — سلسلة فيديو قصيرة لتبسيط إعداد TLS.

إحصاءات تستحق الاستشهاد

• HTTPS هو “a very lightweight signal—affecting fewer than 1% of global queries.” (الترجمة العربية) «إشارة خفيفة جدًا تؤثر في أقل من 1% من طلبات البحث عالميًا». هذا وصف Google لوزن الإشارة عند إطلاقها عام 2014؛ رقم تاريخي مفيد لضبط التوقعات، لا إعادة بيان للآلية الحالية. المصدر
• توسم كل صفحات HTTP بأنها “Not Secure” منذ Chrome 68 في يوليو 2018. وهو أوضح سبب عملي للانتقال. المصدر
• نحو 89% من المواقع تستخدم HTTPS الآن. أصبح معيارًا أساسيًا؛ والخطر في البقاء استثناء لا المكسب من الانتقال (W3Techs، 2026؛ تحقق من الرقم الحالي).
• لا تفقد عمليات 301 قيمة PageRank. تصريح Google المباشر الذي يدحض خرافة فقدان قيمة الروابط. المصدر

اختبر معلوماتك: HTTPS لتحسين محركات البحث

خمسة أسئلة سريعة عن HTTPS في SEO. اختر إجابة لكل سؤال ثم تحقق منها.

سجل التغييرات