محتويات المقال22
- 1.ما الذي يجب أن يغطيه Technical SEO Audit قبل أن تعتبر الموقع سليمًا؟
- 2.أسئلة يطرحها أصحاب القرار في البحث والذكاء الاصطناعي
- 3.Technical SEO بالأولوية: أصلح ما يمنع الزحف والفهرسة والإيراد أولًا
- 4.1. Crawl Access: هل يستطيع Googlebot الوصول إلى الصفحات المهمة؟
- 5.2. Indexability: لماذا يزحف Google إلى الصفحة ولا يفهرسها؟
- 6.3. Canonicalization: كيف تمنع Google من اختيار النسخة الخطأ؟
- 7.4. Redirects وStatus Codes: أين تضيع إشارات الصفحات والزيارات؟
- 8.5. JavaScript SEO: هل المحتوى المهم موجود في HTML الذي يراه Google؟
- 9.6. Site Architecture: هل يصل Google والعميل إلى صفحات المال بسهولة؟
- 10.7. XML Sitemap: هل ترسل لمحركات البحث قائمة نظيفة بالصفحات Canonical؟
- 11.8. Core Web Vitals: قس تجربة المستخدم الحقيقية لا نتيجة Lighthouse فقط
- 12.9. Mobile SEO: هل النسخة التي يراها Google على الهاتف مكتملة؟
- 13.10. Structured Data: متى تساعد Schema ومتى تصبح مجرد ضوضاء؟
- 14.11. International SEO: هل Hreflang يربط اللغة والسوق الصحيحين؟
- 15.12. Faceted Navigation: كيف تمنع الفلاتر والParameters من تضخيم الزحف؟
- 16.13. Log Analysis: أين يصرف Googlebot ميزانية الزحف فعلًا؟
- 17.14. SEO Migration: ما الذي يجب تثبيته قبل تغيير التصميم أو الروابط؟
- 18.كيف تحول أخطاء Technical SEO إلى أولويات مرتبطة بالـLeads والإيراد؟
- 19.مثال تشخيصي: لماذا يخسر موقع Leads بعد إعادة التصميم رغم تحسن الشكل؟
- 20.Technical SEO Audit Checklist: ما الذي يجب إثباته قبل إغلاق التدقيق؟
- 21.القرار النهائي: أصلح ما يمنع الزحف والفهرسة والتحويل قبل مطاردة درجات الأدوات
- 22.مقالات مرتبطة تساعدك على اتخاذ القرار التالي
ما الذي يجب أن يغطيه Technical SEO Audit قبل أن تعتبر الموقع سليمًا؟
السيو التقني لا “يرفع الترتيب” بمجرد إصلاح عشرات الأخطاء في أداة Crawl. وظيفته الأولى أن يضمن أن الصفحات التي تمثل الطلب التجاري يمكن اكتشافها، الوصول إليها، فهمها، فهرستها، اختيار نسختها الصحيحة، وربطها داخليًا دون هدر أو إشارات متضاربة. لذلك تبدأ قائمة التدقيق من أخطاء تمنع الإيراد - مثل صفحات مهمة غير قابلة للفهرسة - قبل تحسينات أقل أثرًا مثل تحذيرات Schema غير الحرجة.
أسئلة يطرحها أصحاب القرار في البحث والذكاء الاصطناعي
ما أهم فحوصات السيو التقني قبل نشر محتوى جديد؟
لماذا Google يزحف للصفحة ولا يفهرسها؟
استخدام robots.txt لإخفاء صفحة من نتائج البحث. Google يفرق بين Crawling وIndexing؛ منع الزحف لا يساوي بالضرورة منع ظهور URL، بينما noindex يحتاج أن يستطيع crawler الوصول للصفحة وقراءة التوجيه.
كيف أرتب أخطاء Technical SEO حسب الأولوية والأثر؟
هذا هو الفرق بين Technical SEO قائم على المخاطر وقائمة Checks مسطحة.
Technical SEO بالأولوية: أصلح ما يمنع الزحف والفهرسة والإيراد أولًا
تقرير Crawl قد يعرض 8,000 Issue، لكن صاحب العمل لا يحتاج “إغلاق العدد”. يحتاج معرفة:
· هل صفحات الخدمات أو المنتجات المهمة متاحة لـGoogle؟
· هل URL الصحيح هو الذي يُفهرس؟
· هل JavaScript يخفي المحتوى أو الروابط؟
· هل الموقع يهدر Crawl على فلاتر ومعلمات لا قيمة لها؟
· هل إعادة التصميم أو Migration سببت فقدًا؟
· هل الأداء السيئ يضر تجربة التحويل؟
لهذا استخدم تصنيفًا حسب المخاطرة:
| الأولوية | معنى المشكلة | مثال |
|---|---|---|
| P0 | تمنع الوصول أو الفهرسة لصفحات المال | noindex خاطئ، 5xx، robots block |
| P1 | تربك النسخة الصحيحة أو تسبب فقد إشارات | Canonical خاطئ، Redirect chains، duplicates واسعة |
| P2 | تقلل اكتشاف/فهم الصفحات | روابط غير قابلة للزحف، Orphans، JS rendering |
| P3 | تحسن التجربة أو الأهلية لميزات إضافية | CWV، Structured Data، صور، Metadata |
ابدأ بـP0 وP1 حتى لو كانت أدوات التدقيق تعطي Issue آخر Score أعلى.
1. Crawl Access: هل يستطيع Googlebot الوصول إلى الصفحات المهمة؟
Google يوضح أن الحد الأدنى للأهلية للفهرسة يتطلب: ألا يكون Googlebot محجوبًا، أن ترجع الصفحة HTTP 200، وأن تحتوي على محتوى قابل للفهرسة. تحقيق هذه الشروط لا يضمن الفهرسة، لكنه نقطة البداية.
Checklist الزحف: Robots وFirewall وStatus Codes وInternal Links
☐ robots.txt لا يحجب أقسامًا مهمة.
☐ لا يوجد Firewall/CDN يمنع Googlebot الحقيقي.
☐ الصفحات التجارية ترجع 200 وليس 3xx/4xx/5xx.
☐ Staging وAdmin محميان بطريقة صحيحة.
☐ لا يوجد noindex على Templates مهمة.
☐ Canonical URL متاح ويعمل.
☐ الموارد الأساسية للعرض ليست محجوبة بشكل يفسد Rendering.
خطأ خطير: موقع يعمل للمستخدم لكنه يحجب محرك البحث
2. Indexability: لماذا يزحف Google إلى الصفحة ولا يفهرسها؟
افحص الصفحات حسب Business Value لا حسب العدد.
اصنع قائمة URL Inventory تحتوي:
· URL.
· Template.
· Page Type.
· Organic role.
· Indexable? نعم/لا.
· Canonical target.
· Status code.
· GSC index status.
· Traffic/Conversions.
ثم اسأل: هل كل صفحة عالية القيمة Indexable؟ وهل كل صفحة منخفضة القيمة تحتاج أصلًا أن تكون في Index؟
أي صفحات يجب أن تبقى خارج الفهرس حتى لا تضعف جودة الموقع؟
حسب الموقع:
· نتائج البحث الداخلي.
· Filters بلا طلب مستقل.
· صفحات حساب/Checkout.
· نسخ مكررة بسبب Parameters.
· صفحات Tag أو Facet رقيقة.
لا تطبق noindex جماعيًا دون فهم الروابط والطلب والـCanonicalization.
3. Canonicalization: كيف تمنع Google من اختيار النسخة الخطأ؟
Google يوضح أن Redirects وrel=canonical إشارات قوية، بينما Sitemap إشارة أضعف لتحديد النسخة المفضلة.
أسئلة Canonical يجب حسمها قبل أي إصلاح تقني
· هل كل صفحة Canonical إلى نفسها عندما تكون الأصل؟
· هل Product Variants أو Parameters تشير للنسخة الصحيحة؟
· هل HTTP/HTTPS وwww/non-www موحدة؟
· هل Canonical يشير إلى صفحة 200 وقابلة للفهرسة؟
· هل Sitemap يحتوي Canonical URLs فقط؟
· هل هناك تعارض بين Redirect وCanonical وSitemap؟
إشارة خطر: Canonical صحيح شكليًا لكنه يتعارض مع الروابط والسitemap
صفحة خدمة A تشير Canonical إلى B لأنهما “متشابهتان”، بينما لكل واحدة نية بحث مستقلة. هنا قد تلغي صفحة تجارية بدل حل duplication.
4. Redirects وStatus Codes: أين تضيع إشارات الصفحات والزيارات؟
استخدم Redirect دائم عند نقل URL بشكل دائم. Google يوضح أن Permanent Redirects إشارة إلى أن الهدف الجديد يجب أن يصبح Canonical.
Checklist:
☐ لا توجد Redirect Chains طويلة.
☐ لا توجد Loops.
☐ الروابط الداخلية تتجه للوجهة النهائية لا URL قديم.
☐ 404 حقيقية لا تعيد 200 بمحتوى “غير موجود”.
☐ الصفحات الملغاة تُقيّم: Redirect إلى بديل مكافئ أم 404/410؟
☐ بعد Migration توجد خريطة Old → New محفوظة ومختبرة.
لا تعيد كل 404 إلى الصفحة الرئيسية؛ هذا يضر المستخدم ولا يحافظ تلقائيًا على قيمة الصفحة القديمة.
5. JavaScript SEO: هل المحتوى المهم موجود في HTML الذي يراه Google؟
المواقع الحديثة قد ترجع HTML أوليًا فقيرًا ثم تضيف المحتوى بالـJavaScript. Google يمكنه Rendering للـJavaScript، لكنه يوضح أن Server-side أو Pre-rendering يظل فكرة جيدة للمستخدمين وCrawlers، وأن ليس كل Bots يشغل JavaScript.
ما الذي يجب مقارنته بين Source HTML وRendered DOM؟
· هل H1 والنص الرئيسي موجودان في Rendered HTML؟
· هل الروابط الداخلية تظهر كـ<a href> قابلة للزحف؟
· هل Product/Service content يحتاج Interaction للظهور؟
· هل Structured Data موجود بعد Rendering؟
· هل Client-side routing يولد URLs قابلة للوصول المباشر؟
· هل أخطاء JS تمنع تحميل المحتوى؟
استخدم URL Inspection / Rich Results Test / View rendered HTML، ولا تعتمد فقط على “الموقع يظهر عندي في المتصفح”.
6. Site Architecture: هل يصل Google والعميل إلى صفحات المال بسهولة؟
أفضل Content لن يحقق كامل قيمته إذا كان مدفونًا على بعد 8 نقرات أو Orphan.
Checklist بنية الموقع والروابط الداخلية
· المسار من Home/Hub إلى الصفحات التجارية.
· الروابط من Articles إلى Money Pages عند السياق المناسب.
· Breadcrumbs.
· صفحات Hub للفئات.
· Anchor Text وصفي غير آلي.
· عدم الاعتماد على JS events بدل links.
· Broken internal links.
نموذج Topic Flow يربط الـHub بالمقالات وصفحات الخدمة
Knowledge Hub → Category Hub → Subcategory/Intent Hub → Article → Service/Commercial Page
هذا يساعد المستخدم وCrawler على فهم العلاقة، لكنه لا يعني أن كل مقال يجب أن يرسل Exact-match Anchor إلى الخدمة.
7. XML Sitemap: هل ترسل لمحركات البحث قائمة نظيفة بالصفحات Canonical؟
Sitemap ليست أداة “إجبار Google على الفهرسة”. وظيفتها مساعدة Google على اكتشاف URLs التي تعتبرها مهمة.
Checklist:
☐ URLs 200 فقط.
☐ Canonical فقط.
☐ لا noindex.
☐ لا Redirects.
☐ lastmod يعكس تعديلًا حقيقيًا لا تحديثًا يوميًا آليًا.
☐ تقسيم Sitemap إذا كان الحجم أو نوع المحتوى يتطلب.
☐ Submission ومراجعة الأخطاء في Search Console.
8. Core Web Vitals: قس تجربة المستخدم الحقيقية لا نتيجة Lighthouse فقط
Google يعرّف Core Web Vitals حاليًا حول LCP وINP وCLS، مع الحدود الإرشادية الجيدة: LCP خلال 2.5 ثانية، INP أقل من 200ms، CLS أقل من 0.1.
لكن لا تجعل مشروع SEO يتحول إلى مطاردة Score 100 في Lab بينما صفحات الخدمة لا تُفهرس.
رتب العمل:
1. استخدم Field Data عندما يتوفر.
2. حدد Templates السيئة لا URLs فردية فقط.
3. اعرف العنصر المسؤول عن LCP.
4. افحص Third-party scripts وJS main thread لمشكلات INP.
5. ثبت المساحات للصور/Ads/Components لتقليل CLS.
6. اربط التحسين بـConversion Metrics.
9. Mobile SEO: هل النسخة التي يراها Google على الهاتف مكتملة؟
في سوق ذي استخدام رقمي مرتفع مثل السعودية، تجربة الجوال ليست “نسخة مصغرة”. تقرير إنترنت السعودية 2025 يعكس بنية استخدام رقمية ومحمولة قوية، لكن قرار SEO يجب أن يستند أيضًا إلى بيانات موقعك.
افحص:
· نفس المحتوى الأساسي متاح على Mobile.
· لا Buttons متداخلة أو CTA مخفي.
· Navigation قابلة للاستخدام.
· Forms لا تنهار.
· صور مناسبة الحجم.
· لا Lazy-loading يمنع المحتوى الأساسي.
10. Structured Data: متى تساعد Schema ومتى تصبح مجرد ضوضاء؟
Schema يساعد محركات البحث على فهم أنواع معينة من المحتوى وقد يؤهل لميزات محددة، لكنه ليس “حيلة Ranking”.
قواعد:
· البيانات المنظمة تطابق المحتوى الظاهر.
· استخدم Types المدعومة والمناسبة.
· لا تضف Reviews أو Ratings غير ظاهرة/غير مؤهلة.
· اختبر JSON-LD.
· راقب Enhancements في Search Console عندما تتوفر.
لا تضف FAQPage لمجرد توقع Rich Result؛ ملف Fikra V7 نفسه يمنع بناء استراتيجية على وعد FAQ Rich Results.
11. International SEO: هل Hreflang يربط اللغة والسوق الصحيحين؟
إذا كان الموقع عربي/إنجليزي أو متعدد الأسواق:
· لكل نسخة URL مستقل.
· hreflang reciprocal.
· Self-reference ضمن مجموعة اللغة.
· Canonical عادة إلى النسخة نفسها في اللغة/المنطقة المناسبة.
· لا تخلط Hreflang مع Canonical يشير لكل اللغات إلى صفحة واحدة.
12. Faceted Navigation: كيف تمنع الفلاتر والParameters من تضخيم الزحف؟
المتاجر قد تولد آلاف URLs من:
· Sort.
· Filter.
· Color/Size.
· Tracking parameters.
· Internal search.
السؤال ليس “كيف نمنعها كلها؟”، بل:
· أي Facet لديه Search Demand ويستحق Landing Page؟
· أي URL تكرار تقني؟
· كيف تمنع Crawl Waste دون قطع Internal Discovery؟
· هل Canonical يعكس الصفحة المفضلة؟
قرار Faceted Navigation يجب أن يتم على مستوى Template/Query Demand، لا Rule عمياء.
13. Log Analysis: أين يصرف Googlebot ميزانية الزحف فعلًا؟
إذا كان الموقع كبيرًا أو لديه مشاكل اكتشاف، Server Logs تكشف:
· ما الذي يطلبه Googlebot فعليًا؟
· أي Sections يستهلك Crawl؟
· هل صفحات المال تُزار؟
· هل Bots تضرب Parameters لا نهائية؟
· هل هناك 5xx أو Latency أثناء Crawl؟
لا تحتاج Log Analysis لكل موقع صغير، لكنه يصبح مهمًا عندما لا تفسر أدوات Crawl وGSC المشكلة.
14. SEO Migration: ما الذي يجب تثبيته قبل تغيير التصميم أو الروابط؟
قبل أي Redesign/Migration:
· Crawl كامل للقديم.
· حفظ Titles/Meta/Headings/Canonicals.
· Export URLs من GSC/Analytics/Backlinks.
· Mapping redirects.
· اختبار Staging مع منع الفهرسة الآمن.
· مقارنة Internal Links.
· إطلاق Monitoring لأول أيام وأسابيع.
أكبر خطأ: اعتبار Migration “مشروع تصميم” ثم استدعاء SEO بعد إطلاق الموقع.
كيف تحول أخطاء Technical SEO إلى أولويات مرتبطة بالـLeads والإيراد؟
استخدم Impact Matrix:
| المشكلة | صفحات متأثرة | قيمة الصفحات | أثر محتمل | الأولوية |
|---|---|---|---|---|
| noindex على صفحات خدمات | 12 | عالية | فقد أهلية الظهور | P0 |
| Canonical غير صحيح لفئة | 30 | عالية | تجميع إشارات خاطئ | P1 |
| CLS في Blog | 80 | منخفضة/متوسطة | تجربة | P3 |
| Broken links إلى صفحات مال | 25 | عالية | اكتشاف/تحويل | P1 |
العدد وحده لا يحدد الأولوية. خطأ واحد على Template Checkout أو Service قد أهم من 10,000 Warning في Tags غير مهمة.
مثال تشخيصي: لماذا يخسر موقع Leads بعد إعادة التصميم رغم تحسن الشكل؟
بعد Redesign، Traffic العضوي انخفض. الفريق يركز على Core Web Vitals، لكن التدقيق يكشف:
· 40 صفحة خدمة قديمة تحولت إلى URLs جديدة دون Redirect فردي.
· Sitemap ما زالت تحتوي URLs القديمة.
· صفحات جديدة Canonical إلى النسخ القديمة التي تعيد Redirect.
· بعض الروابط الداخلية تذهب للقديم.
هنا تحسين LCP لن يعالج أصل المشكلة. ترتيب الإصلاح:
1. Redirect map.
2. Canonical cleanup.
3. Sitemap cleanup.
4. Internal links.
5. Re-inspection/monitoring.
6. ثم Performance improvements.
هذا هو الفرق بين Technical SEO قائم على المخاطر وقائمة Checks مسطحة.
Technical SEO Audit Checklist: ما الذي يجب إثباته قبل إغلاق التدقيق؟
الزحف والوصول: هل الصفحات المهمة قابلة للاكتشاف؟
☐ Robots reviewed
☐ Status codes verified
☐ Critical templates crawlable
☐ Firewall/CDN checked
الفهرسة والCanonical: هل Google يحتفظ بالنسخة الصحيحة؟
☐ noindex intentional
☐ Canonicals consistent
☐ Sitemap clean
☐ Duplicate patterns documented
Rendering والبنية: هل المحتوى والروابط متاحة لمحرك البحث؟
☐ Critical content in rendered HTML
☐ Crawlable links
☐ No orphan money pages
☐ Breadcrumbs/Hub structure
الأداء وتجربة الصفحة: هل المشاكل التقنية تؤثر على المستخدم؟
☐ CWV field data reviewed
☐ Mobile UX reviewed
☐ Images/scripts prioritized by impact
International وSchema: هل الإشارات مفهومة وغير متعارضة؟
☐ hreflang validated when relevant
☐ Structured data matches visible content
القياس: هل نستطيع إثبات أثر الإصلاح بعد التنفيذ؟
☐ GSC baseline saved
☐ Organic conversions tracked
☐ Change log maintained
☐ Post-fix validation scheduled
القرار النهائي: أصلح ما يمنع الزحف والفهرسة والتحويل قبل مطاردة درجات الأدوات
السيو التقني الجيد لا يُقاس بعدد Errors التي اختفت من أداة Audit، بل بقدرة الموقع على جعل الصفحات الصحيحة متاحة ومفهومة ومترابطة وسريعة بما يكفي لخدمة المستخدم والتحويل. ابدأ بالمخاطر التي تمنع صفحات المال من الظهور، ثم انتقل إلى الكفاءة والأداء والتحسينات المتقدمة.
إذا كان تقرير SEO التقني لديك مليئًا بالمئات أو الآلاف من الأخطاء ولا تعرف أيها يؤثر فعليًا على الزيارات أو Leads، أرسل Crawl Export وGSC Coverage/Indexing وأهم صفحات الإيراد لتحديد P0/P1 قبل البدء في إصلاحات منخفضة الأولوية.
مقالات مرتبطة تساعدك على اتخاذ القرار التالي
اقرأ أيضًا: تسريع ووردبريس وCore Web Vitals: كيف تحسن الأداء دون كسر الموقع؟
اقرأ أيضًا: تكلفة تدقيق السيو التقني في السعودية: لماذا لا يمكن تسعيره بعدد الصفحات فقط؟
اقرأ أيضًا: تدقيق جاهزية الموقع للبحث والذكاء الاصطناعي: ماذا تفحص قبل أن تطارد GEO؟
اقرأ أيضًا: SEO شوبيفاي: خطة عملية للفهرسة والتصنيفات وصفحات المنتجات
هل تحتاج خطة تناسب وضع مشروعك؟
شاركنا هدفك والتحديات الحالية، وسنساعدك على تحديد الخطوة الأكثر أثرًا.
تحدث مع فريق فكرةالأسئلة الشائعة
ما أهم فحوصات السيو التقني قبل نشر محتوى جديد؟+
السيو التقني لا “يرفع الترتيب” بمجرد إصلاح عشرات الأخطاء في أداة Crawl. وظيفته الأولى أن يضمن أن الصفحات التي تمثل الطلب التجاري يمكن اكتشافها، الوصول إليها، فهمها، فهرستها، اختيار نسختها الصحيحة، وربطها داخليًا دون هدر أو إشارات متضاربة. لذلك تبدأ قائمة التدقيق من أخطاء تمنع الإيراد - مثل صفحات مهمة غير قابلة للفهرسة - قبل تحسينات أقل أثرًا مثل تحذيرات Schema غير الحرجة.
لماذا Google يزحف للصفحة ولا يفهرسها؟+
استخدام robots.txt لإخفاء صفحة من نتائج البحث. Google يفرق بين Crawling وIndexing؛ منع الزحف لا يساوي بالضرورة منع ظهور URL، بينما noindex يحتاج أن يستطيع crawler الوصول للصفحة وقراءة التوجيه.
كيف أرتب أخطاء Technical SEO حسب الأولوية والأثر؟+
هذا هو الفرق بين Technical SEO قائم على المخاطر وقائمة Checks مسطحة.
اقرأ أيضاً وخدمات قد تهمك
المصادر والمراجع
- https://developers.google.com/search/docs/essentials/technical
- https://developers.google.com/search/docs/crawling-indexing?hl=de
- https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
- https://developers.google.com/search/docs/crawling-indexing/301-redirects?hl=fr
- https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics?hl=es-419
- https://developers.google.com/search/docs/appearance/core-web-vitals
فريق فكرة
فريق فكرة للأبحاث والتسويق
فريق فكرة للأبحاث والتسويق يضم متخصصين في الاستراتيجية والمحتوى وتحسين محركات البحث والأداء الرقمي، ويحوّل البيانات والمصادر الموثوقة إلى قرارات عملية مناسبة للسوق السعودي والخليجي.



