منصة مصطفى ووردبريس
أهلًا بيك، تشخيص قبل التنفيذ

كود خصم Hostinger انقر للنسخ 20% خصم على استضافة Hostinger الجديدة 10% عند كل تجديد التفاصيل

تخطَّ إلى المحتوى
منصة مصطفى ووردبريس
تصميم وتطوير ووردبريس

معرفة قالب ووردبريس لأي موقع: طرق التحقق وحدود الدقة 2026

دليل عملي لمعرفة قالب WordPress المستخدم في أي موقع عبر مصدر الصفحة وDevTools وملفات CSS، مع شرح القوالب المخصصة وChild Themes وPage Builders ومتى لا يمكن إثبات اسم القالب بدقة.

شارك:
واتساب X فيسبوك لينكدإن تيليجرام
صورة بارزة RTL لمعرفة قالب ووردبريس المستخدم في أي موقع وفحص الكود

معرفة قالب ووردبريس لأي موقع ممكنة في كثير من الحالات، لكنها ليست مضمونة 100%. أحيانًا يظهر اسم القالب مباشرة داخل مسار ملفات CSS أوJavaScript، وأحيانًا ترى فقط اسم Child Theme أواسمًا مخصصًا، وأحيانًا تكون الملفات مبنية أومعاد تسميتها بطريقة تجعل تحديد القالب الأصلي غير ممكن من الواجهة العامة وحدها.

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

إذا كان هدفك أوسع من القالب وتريد معرفة الـCMS والـPage Builder والـJavaScript والخدمات المستخدمة في الموقع، راجع دليل معرفة التقنية المستخدمة في المواقع.

الجواب السريع: كيف تعرف قالب ووردبريس؟

  1. تأكد أولًا أن الموقع يعمل بـWordPress.
  2. افتح View Page Source.
  3. ابحث عن wp-content/themes/.
  4. دوّن اسم المجلد الظاهر بعد /themes/.
  5. افحص أكثر من ملف CSS أوJS للتأكد أن الاسم متكرر.
  6. استخدم DevTools → Network أوSources إذا لم يظهر المسار بوضوح في المصدر.
  7. تحقق هل الاسم Theme رئيسي أمChild Theme أماسمًا مخصصًا.

إذا وجدت مسارًا مثل:

/wp-content/themes/astra/assets/css/...

فهذه قرينة قوية أن الموقع يستخدم Theme directory باسم astra. لكنها لا تثبت وحدها أن القالب لم يُعدل، ولا أن التصميم الذي تراه سببه القالب نفسه.

لماذا لا توجد طريقة تضمن معرفة القالب دائمًا؟

لأن المتصفح لا يحصل على «اسم القالب» كبيان رسمي يجب على WordPress إرساله. ما تراه هو الملفات النهائية التي اختار الموقع نشرها. يمكن أن يحدث واحد أوأكثر من الآتي:

  • استخدام قالب مخصص باسم داخلي لا يطابق أي منتج تجاري.
  • استخدام Child Theme باسم مختلف عن Parent Theme.
  • تجميع CSS وJavaScript في ملفات Build لا تكشف مسار القالب الأصلي بوضوح.
  • تقديم الأصول من CDN أوDomain مختلف.
  • إعادة كتابة أوإخفاء بعض مسارات WordPress.
  • استخدام Headless WordPress بحيث Frontend منفصل تمامًا.
  • بناء معظم الواجهة بواسطة Page Builder بينما القالب مجرد طبقة أساسية.

لهذا السبب، النتيجة المهنية قد تكون أحيانًا: «تم تأكيد WordPress، لكن لا توجد أدلة عامة كافية لتحديد اسم القالب الأصلي.»

الطريقة الأولى: فحص View Source

ابدأ من المصدر الخام للصفحة، وليس Elements panel فقط. ابحث عن:

  • wp-content/themes/
  • wp-content/plugins/
  • ملفات CSS التي تحتوي اسم Theme directory.
  • تعليقات HTML أوMetadata تشير إلى إطار العمل المستخدم.

ما الذي يعتبر دليلًا جيدًا؟

إذا وجدت الاسم نفسه في عدة ملفات مستقلة مثل:

  • Stylesheet.
  • JavaScript bundle.
  • Font أوImage asset.

فالثقة أعلى من ظهور الاسم مرة واحدة داخل ملف Cached قديم.

وما الذي لا يعتبر دليلًا كافيًا؟

  • اسم CSS class يشبه اسم قالب معروف.
  • تعليق من Plugin.
  • اسم صورة أوFolder لا يثبت مصدر التصميم.
  • نتيجة أداة كشف واحدة بدون تحقق يدوي.

الطريقة الثانية: استخدام DevTools وNetwork

افتح أدوات المطور في المتصفح ثم Network وأعد تحميل الصفحة. فلتر حسب CSS وJS، ثم افحص Request URLs.

هذه الطريقة مفيدة عندما:

  • المصدر HTML قصير أوMinified.
  • الأصول تُحمّل بعد JavaScript.
  • تريد رؤية الملفات التي تم طلبها فعليًا.
  • تريد التفريق بين Theme assets وPlugin assets.

يمكن أيضًا استخدام تبويب Sources لرؤية شجرة الملفات التي وصل إليها المتصفح، لكن تذكر: ما تراه هو Frontend assets فقط، وليس ملفات PHP الخاصة بالقالب على الخادم.

الطريقة الثالثة: فحص CSS وstyle.css

في قالب WordPress تقليدي قد يكون ملف style.css مفيدًا لأن Theme header يمكن أن يحتوي على معلومات مثل:

  • Theme Name.
  • Theme URI.
  • Author.
  • Template في حالة Child Theme.

لكن لا تفترض أن style.css متاح دائمًا للعامة أوأنه يُستخدم مباشرة في الصفحة. بعض القوالب الحديثة تعتمد Build process وملفات CSS أخرى، وقد لا تحتاج الصفحة إلى تحميل الملف الرئيسي نفسه.

Child Theme: أكثر سبب يربك نتيجة الكشف

يمكن للموقع استخدام Child Theme باسم خاص، بينما التصميم الأساسي يعتمد على Parent Theme معروف.

مثلًا قد ترى:

/wp-content/themes/company-child/...

هذا يثبت اسم Child directory، لكنه لا يخبرك تلقائيًا باسم Parent Theme.

إذا استطعت الوصول إلى Header صالح داخل style.css للـChild Theme، فقد يحتوي حقل:

Template: parent-theme-directory

وهذه قرينة أقوى لتحديد Parent Theme. إذا لم يكن هذا الملف متاحًا، فلا تخمّن الأب من التصميم فقط.

القالب المخصص: ماذا يعني أن الاسم غير معروف؟

إذا وجدت Theme directory مثل acme-theme ولا يوجد له منتج معروف أوصفحة رسمية، فهناك عدة احتمالات:

  • قالب Custom تم تطويره خصيصًا للموقع.
  • Child Theme أعيدت تسميته.
  • Fork من قالب موجود.
  • قالب داخلي لوكالة أوشركة.

لا يمكنك القفز مباشرة إلى «قالب مخصص 100%». الأفضل أن تقول: «اسم القالب الظاهر مخصص أوغير معروف، ولا توجد أدلة عامة كافية لإثبات مصدره الأصلي.»

Page Builder ليس هو القالب

وجود Elementor أوBricks أوBeaver Builder أوأداة بناء أخرى لا يعني أن اسمها هو Theme المستخدم.

في حالة Elementor مثلًا قد ترى Classes أوAssets مرتبطة بالإضافة، بينما القالب الحقيقي قد يكون Hello Elementor أوAstra أوGeneratePress أوTheme مخصصة تمامًا.

لفهم الفرق بين Builder والقالب راجع ما هو Elementor Page Builder؟.

كيف تعرف أن التصميم من Page Builder أكثر من القالب؟

لا يوجد اختبار واحد حاسم، لكن توجد مؤشرات:

  • عدد كبير من Classes وAssets خاصة بالـBuilder.
  • Template parts وWidgets تُحمّل من Plugin.
  • Theme directory بسيط بينما معظم CSS يأتي من Builder.
  • Header/Footer/Templates مُدارة من Theme Builder داخل الإضافة.

في هذه الحالة اسم القالب قد يكون أقل أهمية من معرفة Builder والإضافات والـCustom CSS المستخدمة.

هل أدوات كشف القوالب مفيدة؟

نعم، كخطوة مساعدة فقط. الأدوات الآلية عادة تبحث عن نفس المؤشرات التي تستطيع رؤيتها يدويًا: مسارات Themes، Metadata، Headers أوFingerprints.

متى تكون النتيجة مفيدة؟

  • قالب معروف ومساراته ظاهرة.
  • WordPress تقليدي بدون إخفاء أوBuild معقد.
  • أكثر من إشارة تؤكد الاسم نفسه.

متى تكون النتيجة ضعيفة؟

  • قالب مخصص.
  • Child Theme.
  • Headless WordPress.
  • CDN أوAsset pipeline تغير المسارات.
  • موقع يعيد كتابة مسارات WordPress.

القاعدة: الأداة تعطي Candidate، والتحقق اليدوي يرفع أوخفض مستوى الثقة.

كيف تتأكد أن الموقع WordPress أصلًا؟

قبل البحث عن Theme، ابحث عن مجموعة إشارات بدل علامة واحدة:

  • مسارات wp-content أوwp-includes.
  • WordPress REST API عندما تكون متاحة.
  • روابط أوAssets معروفة من Plugins.
  • Metadata أوHeaders مرتبطة بووردبريس.

لكن حتى هذه الإشارات يمكن تغييرها أوإخفاؤها. إذا لم تجدها، لا يعني ذلك تلقائيًا أن الموقع ليس WordPress.

لتحليل النظام ككل استخدم معرفة التقنية المستخدمة في أي موقع.

درجة الثقة: طريقة أفضل من “وجدت/لم أجد”

الدليلدرجة الثقةماذا يثبت؟
مسارات Theme متعددة بنفس الاسمعاليةاسم Theme directory المستخدمة
Theme header صالح في style.cssعاليةTheme Name ومعلومات إضافية إن كانت موجودة
Template header في Child ThemeعاليةParent Theme directory
نتيجة أداة آلية فقطمتوسطة/منخفضةCandidate يحتاج تحقق
تشابه بصري مع Demoمنخفضة جدًالا يثبت اسم القالب

لماذا التشابه البصري لا يثبت القالب؟

يمكن بناء نفس الواجهة تقريبًا باستخدام قوالب مختلفة، أوPage Builder، أوCustom CSS، أوBlock Theme مخصص. لذلك صورة Screenshot لا تكفي لتحديد Theme.

إذا أعجبك موقع منافس، السؤال الأكثر فائدة هو:

  • ما Layout المستخدم؟
  • ما نوع Header وNavigation؟
  • ما Grid ونظام Typography؟
  • ما Page Builder أوBlock system؟
  • كيف تُنفذ Search/Filters/Checkout؟
  • كيف هو الأداء على الهاتف؟

ثم اختر حلًا يناسب مشروعك بدل نسخ اسم Theme لمجرد أنها مستخدمة في موقع آخر.

هل اسم القالب مهم للسرعة وSEO؟

اسم القالب وحده لا يحدد الأداء أوالترتيب. ما يهم هو التنفيذ الفعلي:

  • HTML الناتج.
  • CSS/JS وحجمهما.
  • تحميل الخطوط والصور.
  • DOM complexity.
  • Server response.
  • الإضافات.
  • Core Web Vitals.
  • Accessibility وMobile UX.

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

إذا كنت تفكر في اعتماد Theme لمشروع عربي، استخدم Checklist اختبار قالب WordPress عربي وRTL بدل الاعتماد على الشهرة أوالشكل فقط.

شجرة قرار سريعة لمعرفة القالب

  1. ظهر wp-content/themes/name بوضوح؟ سجّل الاسم وابحث عن أدلة إضافية.
  2. ظهر اسم غير معروف؟ افحص هل هو Child/Custom Theme.
  3. ظهر Builder بوضوح؟ افصل بين Builder وTheme.
  4. لا توجد مسارات Theme؟ افحص Network/Sources ثم تحقق من WordPress نفسه.
  5. ما زالت الأدلة غير كافية؟ توقف عن التخمين وسجل النتيجة كغير مؤكدة.

أخطاء شائعة عند محاولة معرفة قالب ووردبريس

  • القول إن النتيجة مؤكدة 100% من أداة واحدة.
  • اعتبار Elementor قالبًا.
  • اعتبار Theme directory المخصصة اسم المنتج الأصلي بالضرورة.
  • الخلط بين Child Theme وParent Theme.
  • الاعتماد على شكل الموقع فقط.
  • الاعتقاد أن عدم ظهور wp-content يعني أن الموقع ليس WordPress.
  • نسخ قالب منافس بدل تحليل احتياجات المشروع.

أسئلة شائعة

هل يمكن معرفة قالب أي موقع WordPress؟

ليس دائمًا. كثير من المواقع تكشف مؤشرات كافية، لكن بعض القوالب المخصصة أوHeadless setups أوAsset pipelines تجعل تحديد الاسم الأصلي غير ممكن من المعلومات العامة.

هل المسار wp-content/themes يثبت القالب؟

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

هل يمكن معرفة Parent Theme؟

أحيانًا، خصوصًا إذا كان Header الخاص بالـChild Theme متاحًا ويحتوي Template. لكن إذا لم توجد هذه البيانات علنًا فلا يوجد ضمان.

هل Elementor هو قالب؟

Elementor Plugin/Page Builder. يمكن استخدامه مع قوالب متعددة، لذلك اكتشاف Elementor لا يكفي لمعرفة Theme.

هل أدوات كشف القوالب دقيقة؟

قد تكون دقيقة في الحالات البسيطة، لكنها ليست مرجعًا نهائيًا. تحقق من Source وNetwork ومسارات Theme بنفسك.

ماذا أفعل إذا لم أستطع معرفة القالب؟

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

الخلاصة

معرفة قالب ووردبريس هي عملية تحقق، وليست اختبارًا يعطي نتيجة مضمونة لكل موقع. ابدأ بمسارات wp-content/themes، ثم افحص Network وCSS وChild Theme وPage Builder. اجمع أكثر من دليل وحدد درجة ثقتك في النتيجة.

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

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

مصطفى زكي، Senior WordPress Platform Engineer ومؤسس منصة مصطفى ووردبريس. متخصص في تطوير WordPress وWooCommerce، القوالب والوظائف المخصصة، الأداء، الأمان، وSEO/AEO، بمنهج يبدأ بالتشخيص والقياس قبل التنفيذ.

WordPress WooCommerce Technical SEO الأداء والأمان
تواصل واتساب