Opus Growth

الموقع الإلكتروني

أوامر جاهزة لـ Claude وChatGPT وغيرها من المساعدين المتصلين بحسابات إعلاناتك. انسخ أحدها، واملأ ما بين الأقواس المربعة، ثم أرسله.

صف مشكلتك وسنجد لك الـ prompts المناسبة

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

جرّب:

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقعًا تحريريًا لخبير مع قسم أدلة وschema للمؤلف

اطلب من مساعدك بناء موقع خبير بصفحة رئيسية بتصميم غلاف مجلة وأدلة مطولة وصفحة تعريف بالمؤلف. الخطوط ذات الحواف (serif) وschema من نوع Article وPerson ومقالات مؤرخة وموثقة المصادر تنتج منشورًا يقرؤه الناس ويمكن لإجابات الذكاء الاصطناعي الاستشهاد به.

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

استخدم اتصالي بـ Opus Growth لهذا الغرض. إذا لم تجد الأداة التي تحتاجها، فابحث بين أدوات Opus Growth (باستخدام search_tools إن كانت في قائمتك)؛ وإذا تعذّر عليك الوصول إلى الأدوات تمامًا، فلا تخمّن وأخبرني.

ابنِ لي موقع خبير بأسلوب تحريري على خادم استضافة Opus Growth الخاص بي [اسم الخادم]. أنا: [الاسم الكامل]، [التخصص، مثل مستشار تصدير]، [المنطقة التي أخدمها، أو "عبر الإنترنت"]. الخدمات: [الخدمات]. الخبرة: [الخبرة الحقيقية والقطاعات التي عملت فيها؛ لا تختلق شيئًا]. الهاتف: [الهاتف]، البريد الإلكتروني: [البريد الإلكتروني]، النطاق: [النطاق]. موضوعا أول دليلين: [الموضوع 1]، [الموضوع 2]. إذا كان مكتبي يستقبل زوارًا، فعنوانه: [العنوان أو "لا يوجد"].

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

اتجاه التصميم تحريري:
1. الخطوط: خط serif ذو شخصية من Fontshare للعناوين (مثل Zodiak 700 و400 مائل) وخط sans هادئ للواجهة والنصوص القصيرة (مثل Author 400 و600). متن المقال بخط serif بحجم 19 بكسل، وارتفاع سطر 1.7، وبحد أقصى 68 حرفًا في السطر.
2. الألوان: خلفية ورق بلون كريمي، ونص بحبر داكن، ورمادي دافئ ثانوي، ولون تمييز داكن واحد (مثل لون العنابي). يظهر لون التمييز فقط في العناوين التمهيدية (kickers) والحرف الاستهلالي الكبير وخطوط الاقتباسات البارزة.
3. الشبكة: 12 عمودًا؛ غلاف غير متماثل بنسبة 7 إلى 5 في الصفحة الرئيسية مع خطوط عمودية رفيعة بين الأعمدة. بلا ظلال ولا زوايا مستديرة.
4. العنصر المميز: ترويسة بخط مزدوج مثل ترويسة الجريدة (مع سطر تاريخ رفيع فوقها)، وفي المقالات حرف استهلالي كبير بلون التمييز مع اقتباس بارز في الهامش.
5. الحركة: لا شيء.

الصفحات ومخططاتها (schema):
1. index.html (الغلاف): عنوان رئيسي وتمهيد تجيب فقرته الأولى عن "من أنت، ومن تساعد وفي ماذا"، وصورة المقال الرئيسي وعنوانه، وعمود جانبي فيه المقال الآخر وصناديق الخدمات والمؤلف، واقتباس بارز، وشريط "كيف أعمل". WebPage وPerson.
2. hizmetler.html: قسم لكل خدمة؛ تذكر الفقرة الأولى لمن الخدمة ومتى، تليها خطوات مرقمة والمخرج المكتوب. Service لكل خدمة مع Person المؤلف بصفة provider.
3. hakkimda.html: الخبرة الحقيقية، ومبادئ العمل (بلا نتائج مضمونة)، وكيف تُنتَج المقالات وسياسة المصادر. ProfilePage مع mainEntity من نوع Person (jobTitle وknowsAbout وworksFor #org).
4. rehber/index.html: المقالات من الأحدث إلى الأقدم، مع التاريخ والمؤلف. CollectionPage وItemList (numberOfItems).
5. rehber/[المقال].html: 700 كلمة على الأقل، وفقرة أولى تجيب عن السؤال مباشرة، وتسلسل عناوين H2، وجدول مع thead وth scope حيث يفيد، واقتباس بارز واحد على الأقل، ومن رابطين إلى أربعة روابط داخلية، ومصادر في النهاية. في الأعلى رابط المؤلف وتاريخا النشر وآخر تحديث داخل <time>. Article (headline وimage وdatePublished وdateModified وauthor عبر @id إلى Person وpublisher #org). إذا استخدمت أرقامًا توضيحية، فاذكر أنها وهمية.
6. iletisim.html: ContactPage. 7. kvkk.html (إشعار الخصوصية) و404.html.

إذا كان المكتب لا يستقبل زوارًا، فاضبط localBusiness: false في site.config.js؛ يكفي Organization مع Person.

القواعد التقنية. اتبعها حرفيًا، لأن البوابات أدناه تقيس هذه الأمور بالضبط:

1. الإعداد. شغّل scaffold_site كمعاينة أولًا، وأرني قائمة الملفات، ثم ثبّت بـ confirm=true بعد موافقتي. بعدها اقرأ site_design_guide وsite_seo_guide كاملين. قبل كتابة أي كود، اكتب الاتجاه في _kaynak/ART.md (الإحساس العام، وتزاوج الخطوط، والألوان مع نسب التباين، والشبكة، والعنصر المميز، وقرار الحركة، وقائمة الصفحات) وأرني إياه.
2. أزل JavaScript. لا تحمّل أي صفحة في هذا الموقع أي JavaScript. أزل من كل صفحة سكربت cdn.tailwindcss.com وسطر tailwind.config ووسوم GSAP وScrollTrigger وSplitText وLenis وSwiper ووسوم السكربت motion.js وchrome.js وsite.config.js؛ واحذف assets/chrome.js وassets/motion.js. أبقِ assets/site.config.js، لكن فقط كمصدر للعلامة التجارية والتواصل وseo لـ seo-stamp.mjs؛ فهو لا يُحمَّل في المتصفح أبدًا.
3. القائمة والتذييل HTML ثابت. يرسم JavaScript المكوّنين <site-nav> و<site-footer>، لذلك لا ترى زواحف البحث والذكاء الاصطناعي القائمة ولا الروابط الداخلية ولا بيانات التواصل. اكتب الترويسة في _kaynak/ust.inc والتذييل (الاسم والعنوان والهاتف والبريد الإلكتروني وروابط كل الصفحات وإشعار الخصوصية و"Web: Opus Growth") في _kaynak/alt.inc. استخدم الامتداد .inc حتى لا يعامل seo-stamp وhtml-validate هذه الأجزاء كصفحات. تحمل كل صفحة العلامتين  و. ثم اكتب سكربت Node بلا اعتمادات خارجية باستخدام site_write_file في _kaynak/parca-bas.mjs: يختم الجزأين بين العلامتين في كل ملف HTML، ويضيف aria-current="page" إلى رابط القائمة للصفحة الحالية، ويعيد كتابة sitemap.xml مستخدمًا dateModified من JSON-LD لكل صفحة كقيمة lastmod (مع تخطي 404 والصفحات noindex). ابنِ قائمة الجوال بلا JavaScript باستخدام <details><summary>Menu</summary>؛ قائمتا سطح المكتب والجوال عنصرا <nav> منفصلان بقيمتي aria-label مختلفتين.
4. استضف الخطوط بنفسك. يستخدم هذا الموقع عائلتين وخمسة ملفات كحد أقصى؛ تظهر خطوط العنوان والتمهيد المائل والمتن كلها في الشاشة الأولى، لذلك حمّل الأربعة مسبقًا بـ preload. في العرض التجريبي، أدى تحميل اثنين فقط مسبقًا إلى رفع CLS في مقال طويل إلى 0.24 وخفض أداء الجوال إلى 86؛ أما تحميل الأربعة مسبقًا فأعطى CLS يساوي 0 وأداء 99. نزّل CSS الخاص بـ Fontshare (https://api.fontshare.com/v2/css?f[]=family@400,600&display=swap، ورمز الوزن 401 للمائل) باستخدام site_fetch إلى _kaynak/fontshare.css، واقرأه بـ site_read_file وخذ فقط روابط woff2 للعائلة التي طلبتها؛ فالخدمة تضيف أحيانًا عائلة لم تطلبها. نزّل كل ملف woff2 بـ site_fetch إلى assets/fonts/. ضع قواعد @font-face (مع font-display: swap) داخل assets/app.css، لأن design-check.mjs يبحث عن الخط المخصص في هذا الملف فقط. لا تستخدم الخطوط الافتراضية Inter وRoboto وPoppins وMontserrat.
5. جمّع Tailwind. يصبح assets/app.css مصدر Tailwind: @tailwind base; @tailwind components; @tailwind utilities; في الأعلى، ثم @font-face وحلقة التركيز ورابط التخطي (skip link) وقاعدة prefers-reduced-motion وفئات المكوّنات الخاصة بك داخل @layer components. لا تسمِّ أبدًا فئة مكوّن باسم فئة أداة في Tailwind (list-item وtable وgrid وcontainer وhidden وغيرها)، لأن التعارض يكسر التخطيط بصمت بعد التجميع. اكتب tailwind.config.js في الجذر (content: ["./*.html", "./**/*.html", "./_kaynak/*.inc"] والألوان وfontFamily). شغّل "npx --yes tailwindcss@3 -i assets/app.css -o assets/site.css --minify" باستخدام site_run_command مع background=true، وانتظره باستخدام site_command_status. يحتوي <head> في كل صفحة، بهذا الترتيب، على: عنصر <link rel="stylesheet" href="/assets/site.css"> واحد فقط، ثم سطر preload واحد لكل ملف خط مستخدم في الشاشة الأولى (العنوان والتمييز والمتن؛ as="font" type="font/woff2" crossorigin). أسطر preload الموضوعة قبل ملف الأنماط تؤخر CSS وتزيد LCP؛ والخط الذي يظهر في الشاشة الأولى بلا preload يتبدل متأخرًا ويزيح الصفحة ويرفع CLS، ثم <link rel="icon" href="/assets/img/favicon.svg" type="image/svg+xml">. سطر favicon إلزامي: بدونه يطلب المتصفح /favicon.ico ويحصل على 404، ويخفض خطأ وحدة التحكم درجة Best Practices.
6. الصور. نزّل الصور باستخدام site_fetch مع resize وimage_format="webp" بعدة عروض (480 و800 و1200 و1600 لصورة الشاشة الأولى، و480 و800 و1200 لبقية الصور؛ بجودة بين 60 و75، وأقل للصور كثيرة التفاصيل). لكل <img> سمة srcset وsizes تطابق التخطيط الفعلي وwidth وheight (لتحقيق CLS صفري) ونص alt ذو معنى وصادق. تُضاف fetchpriority="high" فقط إلى الصورة التي يبلّغ Lighthouse بأنها عنصر LCP، ولا تكون هذه الصورة lazy؛ وتستخدم كل الصور الأخرى loading="lazy". إذا كان عنصر LCP نصًا، فلا تحصل أي صورة على fetchpriority. جهّز أيضًا assets/img/logo.png وملف assets/img/og.jpg بقياس 1200x630 وassets/img/favicon.svg.
7. قواعد HTML (الإعدادات الافتراضية لـ html-validate). <!DOCTYPE html> بأحرف كبيرة؛ لا سمة style مضمّنة (بما فيها style="background:var(--brand)" الموجودة في الطقم، استخدم فئة بدلًا منها)؛ &nbsp; بدل المسافات العادية في نص روابط tel:؛ سمة type في كل <button>؛ بلا مسافات زائدة في نهاية الأسطر؛ جداول مع <thead> و<tbody> وth scope. الروابط داخل الفقرات مسطّرة؛ وروابط القائمة والتذييل ومسار التنقل (breadcrumb) والأزرار لها مساحة لمس لا تقل عن 44x44 بكسل (min-h-[44px] min-w-[44px]).
8. البيانات المنظمة. املأ كتلة seo في site.config.js (siteUrl وdescription وlogo وصورة og ونوع النشاط وحقول العنوان) وشغّل "node seo-stamp.mjs" باستخدام site_run_command؛ فهو يختم Organization وWebSite وعند الحاجة نوعًا فرعيًا من LocalBusiness، إضافة إلى وسوم canonical وOG. أضف يدويًا المخطط الخاص بكل صفحة: في كل صفحة عقدة WebPage مع @id (أو AboutPage أو ContactPage أو CollectionPage أو ProfilePage) وdatePublished وdateModified وisPartOf #site وabout #business أو #org وbreadcrumb يشير إلى BreadcrumbList؛ إضافة إلى Service لكل خدمة وPerson وProfilePage للمؤلف وItemList في فهرس الأدلة وArticle في كل دليل. اكتب كل عقدة في كتلة <script type="application/ld+json"> خاصة بها ولا تستخدم غلاف @graph، لأن seo-check.mjs يقرأ فقط @type في المستوى الأعلى ويفوّت BreadcrumbList داخل @graph. اربط العقد بـ @id. لا تختلق أبدًا ساعات عمل أو إحداثيات أو تقييمات أو مراجعات أو جوائز أو أعداد عملاء أو شهادات؛ واترك الحقول المجهولة.
9. وصول الذكاء الاصطناعي. اكتب robots.txt: الموقع كله مفتوح، ويُغلق فقط /_kaynak/؛ مع Allow: / للزواحف GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot؛ وقرارك بشأن CCBot مع السبب كتعليق؛ وسطر Sitemap في النهاية. أضف llms.txt في الجذر: ملخصًا صحيحًا للنشاط في جملتين، والصفحات المهمة بسطر لكل صفحة، وبيانات التواصل. اكتب 404.html (noindex، مع علامات الترويسة والتذييل).
10. الكتابة. تحتوي كل صفحة على 150 كلمة على الأقل من النص الأصلي داخل <main>، وتجيب الفقرة الأولى مباشرة عن السؤال الرئيسي للصفحة. تتراوح العناوين بين 48 و60 حرفًا، والأوصاف بين 145 و158، وتكون فريدة في كل صفحة. بلا شرطات طويلة أو قصيرة، ولا شعارات مبتذلة، ولا وعود فارغة. إذا كان أي شيء في الموقع غير حقيقي، فاذكر بوضوح أنه وهمي.

البوابات. بعد كل تعديل، شغّل هذه الأوامر باستخدام site_run_command بهذا الترتيب ولا تنتقل قبل أن تنجح كل واحدة بلا مشكلات:
1. node _kaynak/parca-bas.mjs، ثم node seo-stamp.mjs، ثم تجميع Tailwind (مرة أخرى إذا أضفت فئات).
2. node seo-check.mjs: صفر أخطاء وصفر تحذيرات. إذا ظهر التحذير "gövde kısa" (المتن قصير)، فأضف نصًا حقيقيًا، لا حشوًا.
3. node design-check.mjs: صفر أخطاء. التحذير الوحيد المسموح به هو "Hiç hareket yok" (لا حركة)؛ فهو خيار مقصود لتجربة القراءة، فاذكر السبب في التقرير.
4. npx --yes html-validate "**/*.html": صفر أخطاء.
5. افحص كل صفحة باستخدام site_preview عند view="mobile" وview="desktop"، وافحص الصفحة الرئيسية أيضًا عند 360 و768 بكسل. أصلح أي تجاوز أفقي أو عنوان ضيق أو هدف لمس أصغر من 44 بكسل ثم افحص مجددًا.
6. قِس كل صفحة باستخدام core_web_vitals عند strategy="mobile" وstrategy="desktop"، ثم دقّق الصفحة الرئيسية وأطول صفحة باستخدام seo_audit. الهدف: على الجوال، Accessibility وBest Practices وSEO بدرجة 100 وPerformance بدرجة 95 على الأقل؛ وعلى سطح المكتب الأربعة كلها 95 على الأقل. يجب ألا يخرج أي طلب واحد من الموقع. إذا كان LCP مرتفعًا، فاستخدم resources=true لتحديد الملف الذي يعطّله: غالبًا أسطر preload الموضوعة قبل ملف الأنماط، أو fetchpriority الممنوحة لصورة ليست عنصر LCP. إذا تجاوز CLS قيمة 0.1، فابحث عن خط في الشاشة الأولى لم يُحمَّل مسبقًا.
لا تعتبر العمل منتهيًا حتى تنجح كل هذه الفحوص.

بعد النشر، أرسل https://[النطاق]/sitemap.xml باستخدام gsc_submit_sitemap وافحص الصفحة الرئيسية باستخدام gsc_url_inspect. إذا لم يكن هناك موقع في Search Console، فأخبرني؛ ولا تحاول ربط واحد بنفسك.

تقرير التسليم: جدول بدرجات Lighthouse الأربع وLCP لكل صفحة على الجوال وسطح المكتب، ونتيجة البوابات الأربع، وسبب أي تحذير من design-check، وقائمة بالمعلومات الوهمية أو الناقصة في الموقع، وما يجب عليّ فعله بعد ذلك (Business Profile والصور الحقيقية وساعات العمل وغيرها).

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقعًا لنشاط عائلي عريق بمظهر كلاسيكي ومعايير حديثة

اطلب من مساعدك بناء موقع بروح الملصقات القديمة ولافتات المتاجر لمنتج من الجيل الثالث، بإطار وملمس ورقي. المظهر قديم، أما البناء فحديث: الجوال أولًا، بلا JavaScript، خطوط مستضافة ذاتيًا، WebP، وschema من نوع Product وHowTo.

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

ابنِ موقعًا بمظهر تقليدي لعملنا العائلي على خادم استضافة Opus Growth الخاص بي [اسم الخادم]. النشاط: [اسم النشاط]، [ما ننتجه، مثل زيت الزيتون أو الحلقوم التركي]، [المدينة]، [سنة التأسيس والجيل، فقط إن كان صحيحًا]. المنتجات: [لكل منتج: الاسم، حجم العبوة، وصف قصير والسعر المنشور، أو "بدون سعر"]. مراحل الإنتاج: [قائمة قصيرة]. كيف يطلب الناس: [هاتف، متجر، توصيل]. الهاتف: [الهاتف]، البريد الإلكتروني: [البريد الإلكتروني]، عنوان المتجر: [العنوان]، النطاق: [النطاق]. صور العائلة والأرشيف: [أين هي، أو "لا توجد"].

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

اتجاه التصميم تقليدي:
1. الخطوط: عائلة خط serif كلاسيكية واحدة من Fontshare (مثل Gambetta 400 و400 مائل و600). أحرف كبيرة صغيرة باستخدام font-variant-caps: all-small-caps مع تباعد واسع بين الأحرف في القائمة والأزرار والتسميات؛ عناوين في المنتصف.
2. الألوان: خلفية بلون الورق، ونص بني حبري، وبني ثانوي، ولون رئيسي واحد (مثل الأخضر الزيتي)، مع لون دافئ ثانٍ على التسميات الصغيرة فقط. كلها بتباين لا يقل عن 4.5:1.
3. الملمس: ملمس ورق للخلفية على شكل SVG بتقنية feTurbulence كـ data URI داخل CSS؛ بلا ملف صورة إضافي وبلا طلب إضافي.
4. العنصر المميز: إطار ملصق قديم، وصندوق بخطين مزدوجين مع زخارف في الزوايا (border وoutline-offset و::before و::after)، وزخرفة صغيرة مرسومة بـ SVG مضمّن بين الأقسام (مثل غصن زيتون)، مع aria-hidden.
5. التخطيط: في المنتصف وضيق؛ المنتجات في بطاقات ملصقات مؤطرة، عمود واحد على الهاتف.
6. الحركة: لا شيء.
7. الصور: استخدم أرشيف العائلة إن وُجد. وإلا يمكنك استخدام صور أرشيفية من الملكية العامة أو بترخيص مفتوح، لكن اذكر المصدر والترخيص في التعليق ولا تقدمها أبدًا على أنها تخص العائلة.

الصفحات والمخطط (schema) الخاص بكل منها:
1. index.html: شاشة أولى مؤطرة تجيب فقرتها الافتتاحية عن "من، يصنع ماذا، أين، يبيع كيف"، وملصقات المنتجات، وقسم العائلة، وكيفية الطلب. WebPage. اضبط النوع الفرعي الأنسب للنشاط في site.config.js (مثل Store أو FoodEstablishment).
2. urunler.html: كل منتج في بطاقة ملصق خاصة به مع الاسم وحجم العبوة والوصف والسعر المنشور. CollectionPage وعنصر Product لكل منتج (brand وmanufacturer #business وoffers مع price وpriceCurrency وavailability). لا تكتب أبدًا سعرًا لم أعطك إياه؛ وإن لم يوجد سعر فاترك offers خارجًا تمامًا.
3. hikayemiz.html: القصة الحقيقية، جيلًا بعد جيل. AboutPage.
4. uretim.html: المراحل من الحصاد أو المادة الخام إلى العبوة، والتعريف الرسمي لدرجة المنتج واللائحة التي يستند إليها (مثل مدونة الغذاء التركية). WebPage وHowTo.
5. sss.html: ست أسئلة حقيقية عن الطلب والتوصيل والتخزين. FAQPage.
6. iletisim.html: هاتف الطلب وعنوان المتجر ورابط الخريطة؛ اترك ساعات العمل خارجًا إن كانت تتغير بتغير الموسم. ContactPage.
7. kvkk.html (إشعار الخصوصية) و404.html.

القواعد التقنية. اتبعها بدقة، لأن البوابات أدناه تقيس هذه الأمور تحديدًا:

1. الإعداد. شغّل scaffold_site كمعاينة أولًا، وأرني قائمة الملفات، ثم ثبّت باستخدام confirm=true بعد موافقتي. بعد ذلك اقرأ site_design_guide وsite_seo_guide بالكامل. قبل كتابة أي كود، اكتب الاتجاه في _kaynak/ART.md (الإحساس، تزاوج الخطوط، الألوان مع نسب التباين، الشبكة، العنصر المميز، قرار الحركة، قائمة الصفحات) وأرني إياه.
2. أزل JavaScript. لا تُحمّل أي صفحة في هذا الموقع أي JavaScript. أزل من كل صفحة سكربت cdn.tailwindcss.com وسطر tailwind.config ووسوم GSAP وScrollTrigger وSplitText وLenis وSwiper ووسوم السكربت motion.js وchrome.js وsite.config.js؛ واحذف assets/chrome.js وassets/motion.js. احتفظ بـ assets/site.config.js، لكن فقط كمصدر للعلامة والتواصل وseo لـ seo-stamp.mjs؛ ولا يُحمَّل أبدًا في المتصفح.
3. القائمة والتذييل HTML ثابت. المكونان <site-nav> و<site-footer> يُرسمان بواسطة JavaScript، لذا لا ترى برامج الزحف الخاصة بالبحث والذكاء الاصطناعي القائمة ولا الروابط الداخلية ولا بيانات التواصل. اكتب الترويسة في _kaynak/ust.inc والتذييل (الاسم، العنوان، الهاتف، البريد الإلكتروني، روابط كل الصفحات، إشعار الخصوصية، "Web: Opus Growth") في _kaynak/alt.inc. استخدم الامتداد .inc حتى لا يعامل seo-stamp وhtml-validate الأجزاء كصفحات. تحمل كل صفحة العلامات  و. ثم اكتب سكربت Node بلا اعتماديات باستخدام site_write_file في _kaynak/parca-bas.mjs: يدرج الجزأين بين العلامات في كل ملف HTML، ويضيف aria-current="page" إلى رابط القائمة الخاص بالصفحة الحالية، ويعيد كتابة sitemap.xml باستخدام dateModified من JSON-LD لكل صفحة كقيمة lastmod (مع تجاوز 404 والصفحات noindex). ابنِ قائمة الهاتف بدون JavaScript باستخدام <details><summary>Menu</summary>؛ قائمتا سطح المكتب والهاتف عنصرا <nav> منفصلان بقيمتي aria-label مختلفتين.
4. استضف الخطوط بنفسك. يستخدم هذا الموقع عائلة خط serif كلاسيكية واحدة وثلاثة ملفات على الأكثر. نزّل CSS الخاص بـ Fontshare (https://api.fontshare.com/v2/css?f[]=family@400,600&display=swap، ورمز الوزن 401 للمائل) باستخدام site_fetch إلى _kaynak/fontshare.css، واقرأه باستخدام site_read_file وخذ فقط روابط woff2 للعائلة التي طلبتها؛ فالخدمة تضيف أحيانًا عائلة لم تطلبها. نزّل كل ملف woff2 باستخدام site_fetch إلى assets/fonts/. ضع قواعد @font-face (مع font-display: swap) داخل assets/app.css، لأن design-check.mjs لا يبحث عن خط مخصص إلا في هذا الملف. لا تستخدم الخطوط الافتراضية Inter أو Roboto أو Poppins أو Montserrat.
5. ترجم Tailwind. يصبح assets/app.css مصدر Tailwind: @tailwind base; @tailwind components; @tailwind utilities; في الأعلى، ثم @font-face، وحلقة التركيز، ورابط التخطي، وقاعدة prefers-reduced-motion، وفئات المكونات الخاصة بك داخل @layer components. لا تعطِ أبدًا فئة مكوّن اسم فئة أداة من Tailwind (list-item وtable وgrid وcontainer وhidden وهكذا)، لأن التعارض يكسر التخطيط بصمت بعد الترجمة. اكتب tailwind.config.js في الجذر (content: ["./*.html", "./**/*.html", "./_kaynak/*.inc"]، والألوان وfontFamily). شغّل "npx --yes tailwindcss@3 -i assets/app.css -o assets/site.css --minify" باستخدام site_run_command مع background=true، وانتظر باستخدام site_command_status. يحتوي <head> في كل صفحة، بهذا الترتيب، على: رابط واحد <link rel="stylesheet" href="/assets/site.css">، ثم سطر preload واحد لكل ملف خط مستخدم في الشاشة الأولى (العنوان والتمييز والنص؛ as="font" type="font/woff2" crossorigin). أسطر preload الموضوعة قبل ملف الأنماط تؤخر CSS وتزيد LCP؛ والخط في الشاشة الأولى الذي بلا preload يتبدل متأخرًا ويزحزح الصفحة ويرفع CLS، و<link rel="icon" href="/assets/img/favicon.svg" type="image/svg+xml">. سطر favicon مطلوب: فبدونه يطلب المتصفح /favicon.ico ويتلقى 404، ويخفض خطأ وحدة التحكم درجة أفضل الممارسات.
6. الصور. نزّل الصور باستخدام site_fetch مع resize وimage_format="webp" بعدة عروض (480 و800 و1200 و1600 لصورة الشاشة الأولى، و480 و800 و1200 لبقية الصور؛ بجودة بين 60 و75، وأقل للصور الدقيقة التفاصيل). كل <img> لها srcset وsizes مطابقة للتخطيط الفعلي وwidth وheight (CLS صفر) ونص alt ذو معنى وصادق. يوضع fetchpriority="high" فقط على الصورة التي يبلغ عنها Lighthouse كعنصر LCP، ولا تكون هذه الصورة lazy؛ وكل الصور الأخرى تستخدم loading="lazy". إن كان عنصر LCP نصًا فلا تحصل أي صورة على fetchpriority. جهّز أيضًا assets/img/logo.png وassets/img/og.jpg بمقاس 1200x630 وassets/img/favicon.svg.
7. قواعد HTML (الإعدادات الافتراضية لـ html-validate). <!DOCTYPE html> بأحرف كبيرة؛ بلا سمة style مضمّنة (بما في ذلك style="background:var(--brand)" الخاصة بالقالب، استخدم فئة بدلًا منها)؛ &nbsp; بدل المسافات العادية في نص روابط tel:؛ سمة type على كل <button>؛ بلا مسافات زائدة في نهاية الأسطر؛ جداول مع <thead> و<tbody> وth scope. الروابط داخل الفقرات تحتها خط؛ وروابط القائمة والتذييل ومسار التنقل والأزرار لها منطقة لمس لا تقل عن 44x44 بكسل (min-h-[44px] min-w-[44px]).
8. البيانات المنظمة. املأ كتلة seo في site.config.js (siteUrl وdescription وlogo وصورة og ونوع النشاط وحقول العنوان) وشغّل "node seo-stamp.mjs" باستخدام site_run_command؛ فهو يدرج Organization وWebSite، وحيثما لزم نوعًا فرعيًا من LocalBusiness، إضافة إلى وسوم canonical وOG. أضف يدويًا المخطط الخاص بكل صفحة: في كل صفحة عقدة WebPage مع @id (أو AboutPage أو ContactPage أو CollectionPage أو ProfilePage) وdatePublished وdateModified وisPartOf #site وabout #business أو #org وbreadcrumb يشير إلى BreadcrumbList؛ إضافة إلى Product مع Offer لكل منتج في صفحة المنتجات، وHowTo في صفحة الإنتاج، وFAQPage في صفحة الأسئلة الشائعة. اكتب كل عقدة في كتلة <script type="application/ld+json"> خاصة بها ولا تستخدم غلاف @graph، لأن seo-check.mjs يقرأ فقط @type في المستوى الأعلى ويفوّته BreadcrumbList داخل @graph. اربط العقد باستخدام @id. لا تخترع أبدًا ساعات عمل أو إحداثيات أو تقييمات أو مراجعات أو جوائز أو أعداد عملاء أو شهادات؛ واترك الحقول المجهولة خارجًا.
9. وصول الذكاء الاصطناعي. اكتب robots.txt: الموقع كله مفتوح، و/_kaynak/ فقط مغلق؛ Allow: / لكل من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot؛ وقرارك بشأن CCBot مع السبب في تعليق؛ وسطر Sitemap في النهاية. أضف llms.txt في الجذر: ملخص صحيح من جملتين للنشاط، والصفحات المهمة مع سطر لكل منها، وبيانات التواصل. اكتب 404.html (noindex، مع علامات الترويسة والتذييل).
10. الكتابة. لكل صفحة 150 كلمة على الأقل من النص الأصلي داخل <main>، وتجيب الفقرة الأولى مباشرة عن السؤال الرئيسي للصفحة. العناوين من 48 إلى 60 حرفًا، والأوصاف من 145 إلى 158، فريدة في كل صفحة. بلا شرطات طويلة أو متوسطة، وبلا شعارات جاهزة، وبلا وعود فارغة. إن كان أي شيء في الموقع غير حقيقي فقل بوضوح إنه خيالي.

البوابات. بعد كل تغيير، شغّلها باستخدام site_run_command بهذا الترتيب ولا تنتقل حتى تكون كل واحدة نظيفة:
1. node _kaynak/parca-bas.mjs، ثم node seo-stamp.mjs، ثم ترجمة Tailwind (مرة أخرى إن أضفت فئات).
2. node seo-check.mjs: 0 أخطاء و0 تحذيرات. إن حذّر من "gövde kısa" (النص قصير)، أضف نصًا حقيقيًا لا حشوًا.
3. node design-check.mjs: 0 أخطاء. التحذير الوحيد المسموح هو "Hiç hareket yok" (لا توجد حركة)؛ فالأسلوب الكلاسيكي يتطلب ذلك، فاذكر السبب في التقرير.
4. npx --yes html-validate "**/*.html": 0 أخطاء.
5. افحص كل صفحة باستخدام site_preview عند view="mobile" وview="desktop"، وافحص الصفحة الرئيسية أيضًا عند 360 و768 بكسل. أصلح أي تجاوز أفقي أو عنوان ضيق أو هدف لمس أصغر من 44 بكسل ثم افحص مجددًا.
6. قِس كل صفحة باستخدام core_web_vitals عند strategy="mobile" وstrategy="desktop"، ثم دقّق الصفحة الرئيسية وأطول صفحة باستخدام seo_audit. الهدف: على الهاتف، إمكانية الوصول وأفضل الممارسات وSEO بقيمة 100 والأداء 95 على الأقل؛ وعلى سطح المكتب كل الدرجات الأربع 95 على الأقل. يجب ألا يخرج أي طلب واحد من الموقع. إن كان LCP مرتفعًا فاستخدم resources=true لإيجاد الملف الذي يعيقه: غالبًا أسطر preload الموضوعة قبل ملف الأنماط، أو fetchpriority الممنوح لصورة ليست عنصر LCP. وإن تجاوز CLS قيمة 0.1 فابحث عن خط في الشاشة الأولى بلا preload.
لا تعتبر العمل منتهيًا حتى تنجح كل هذه الفحوص.

بعد النشر، أرسل https://[النطاق]/sitemap.xml باستخدام gsc_submit_sitemap وافحص الصفحة الرئيسية باستخدام gsc_url_inspect. إن لم تكن هناك خاصية في Search Console فأخبرني؛ ولا تحاول ربط واحدة بنفسك.

تقرير التسليم: جدول بدرجات Lighthouse الأربع وLCP لكل صفحة على الهاتف وسطح المكتب، ونتيجة البوابات الأربع، وسبب أي تحذير من design-check، وقائمة بالمعلومات في الموقع التي هي خيالية أو ناقصة، وما ما زال عليّ فعله (Business Profile، صور حقيقية، ساعات العمل وغير ذلك).

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقعًا لمكتب محاماة أو محاسبة بأسلوب سويسري بسيط مع إشارات ثقة قوية

يجعل مساعدك يبني موقعًا ثابتًا للمكتب على شبكة صارمة، مع تدرج بصري قائم على عائلة خطوط واحدة. ويضع في الصفحة إشارات الثقة التي يحتاجها مجال YMYL: ملفات تعريفية للممارسين، ومذكرة إرشادية مؤرخة وموثقة بالمصادر، وصياغة تحترم قواعد الإعلان المهني، وschema من نوع Person.

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

ابنِ موقعًا ثابتًا متعدد الصفحات بأسلوب سويسري مينيمالي لمكتبنا على خادم استضافة Opus Growth الخاص بي [اسم الخادم]. المكتب: [اسم المكتب]، [المهنة، مثل مكتب محاماة أو مكتب محاسبة]، [المدينة]. مجالات العمل: [المجالات]. الممارسون: [لكل منهم الاسم والمسمى الوظيفي والنقابة أو الهيئة المسجل لديها ورقم التسجيل والمجالات]. الهاتف: [الهاتف]، البريد الإلكتروني: [البريد الإلكتروني]، العنوان: [العنوان]، النطاق: [النطاق]. موضوع المذكرة الإرشادية: [موضوع متكرر، مثل الحد القانوني لزيادة الإيجار].

هذا مجال يتخذ فيه الناس قرارات تتعلق بأموالهم وحقوقهم، لذا يجب أن تأتي الثقة من الوضوح والمؤهلات والمصادر، لا من الزخرفة. التزم بالقواعد المهنية: بالنسبة للمحامين في تركيا، لائحة حظر الإعلان الصادرة عن اتحاد نقابات المحامين الأتراك؛ وبالنسبة للمحاسبين، القواعد المهنية لـ TÜRMOB؛ أو ما يعادلها في البلد الذي تمارس فيه المهنة. لا تكتب نسب نجاح ولا أعداد قضايا كُسبت ولا أسماء عملاء ولا ادعاءات تفوق مثل "الأفضل" أو "الخبير الأول" ولا مقارنات أتعاب ولا ضمانات ولا وعودًا مبالغًا فيها. اعرض المعلومات مع ملاحظة بأنها عامة ولا تغني عن الاستشارة القانونية أو المالية.

اتجاه التصميم سويسري مينيمالي:
1. الخط: عائلة خطوط غروتسك واحدة من Fontshare (مثل Switzer بالأوزان 400 و500 و600). يأتي التدرج الهرمي من الحجم والوزن فقط: عنوان كبير مضغوط محاذٍ لليسار، ونص أساسي هادئ، وتسميات أقسام صغيرة.
2. اللون: خلفية بيضاء، ونص أسود تقريبًا، ورمادي داكن واحد، ولون مميز واحد (مثل الأحمر السويسري). يظهر اللون المميز فقط في علامة القسم والتسميات وحلقة التركيز. الصور بالأبيض والأسود (grayscale في Tailwind).
3. الشبكة: 12 عمودًا صارمة. في كل قسم تقع التسمية في الأعمدة من 1 إلى 3 والمحتوى في الأعمدة من 4 إلى 12؛ وتفصل بين الأقسام خطوط سوداء بسمك 1 بكسل. بلا زوايا مستديرة ولا ظلال.
4. العنصر المميز: تسميات الأقسام مرقّمة بعلامة § باللون المميز، وخطوط إرشادية باهتة للأعمدة الـ12 مرسومة بـ CSS فقط خلف الشاشة الأولى.
5. الحركة: لا شيء.

الصفحات ومخططاتها (schema):
1. index.html: شاشة أولى تجيب فقرتها الافتتاحية عن "أي موضوع، ولمن، وأين"، ومجالات العمل، وطريقة عملك، وكيفية تحديد الأتعاب (بلا أرقام، مع الإشارة إلى التعرفة الرسمية وعقد خدمة مكتوب)، وأحدث مذكرة إرشادية، وملخص عن الفريق. WebPage.
2. calisma-alanlari.html: قسم لكل مجال؛ تجيب الفقرة الأولى عن أكثر الأسئلة شيوعًا في ذلك المجال، ثم المواضيع الرئيسية والأساس القانوني. Service لكل مجال.
3. ekip.html: ملف تعريفي لكل ممارس (الاسم، المسمى، النقابة أو الهيئة، المجالات، نبذة قصيرة). AboutPage وPerson لكل ممارس (jobTitle وknowsAbout وworksFor #business وmemberOf للنقابة أو الهيئة).
4. bilgi-notlari/[الموضوع].html: مذكرة مبنية على النص القانوني وتبدأ بإجابة قصيرة. في الأعلى: الكاتب والمراجع وتاريخ النشر وتاريخ آخر مراجعة؛ وفي النهاية قائمة بالمصادر. Article (الكاتب والناشر عبر @id وimage وdatePublished وdateModified وcitation) وreviewedBy وlastReviewed على WebPage. لا تكتب أبدًا نقطة قانونية أو مالية لا تعرفها؛ اسألني عن كل جملة لست متأكدًا منها.
5. sss.html: ستة أسئلة حقيقية، FAQPage. 6. iletisim.html: ContactPage. 7. kvkk.html (مع الإشارة إلى السرية المهنية) و404.html.

القواعد التقنية. اتبعها بدقة، لأن البوابات أدناه تقيس هذه الأمور تحديدًا:

1. الإعداد. شغّل scaffold_site أولًا كمعاينة، وأرني قائمة الملفات، ثم ثبّت مع confirm=true بعد موافقتي. بعدها اقرأ site_design_guide وsite_seo_guide بالكامل. قبل كتابة أي شيفرة، اكتب الاتجاه في _kaynak/ART.md (الإحساس العام، وتزاوج الخطوط، والألوان مع نسب التباين، والشبكة، والعنصر المميز، وقرار الحركة، وقائمة الصفحات) وأرني إياه.
2. أزل JavaScript. لا تحمّل أي صفحة في هذا الموقع أي JavaScript. أزل من كل صفحة سكربت cdn.tailwindcss.com وسطر tailwind.config ووسوم GSAP وScrollTrigger وSplitText وLenis وSwiper ووسوم سكربت motion.js وchrome.js وsite.config.js؛ واحذف assets/chrome.js وassets/motion.js. احتفظ بـ assets/site.config.js، لكن فقط كمصدر للـ brand وcontact وseo لأجل seo-stamp.mjs؛ فهو لا يُحمَّل في المتصفح أبدًا.
3. القائمة والتذييل بـ HTML ثابت. المكوّنان <site-nav> و<site-footer> يُرسمان بـ JavaScript، فلا تستطيع زواحف البحث والذكاء الاصطناعي رؤية القائمة والروابط الداخلية وبيانات التواصل. اكتب الترويسة في _kaynak/ust.inc والتذييل (الاسم والعنوان والهاتف والبريد الإلكتروني وروابط كل الصفحات وإشعار الخصوصية و"Web: Opus Growth") في _kaynak/alt.inc. استخدم الامتداد .inc حتى لا يعامل seo-stamp وhtml-validate هذه الأجزاء كصفحات. تحمل كل صفحة العلامات  و. ثم اكتب بـ site_write_file سكربت Node بلا تبعيات في _kaynak/parca-bas.mjs: يختم الجزأين بين العلامات في كل ملف HTML، ويضيف aria-current="page" إلى رابط القائمة للصفحة الحالية، ويعيد كتابة sitemap.xml مستخدمًا dateModified من JSON-LD لكل صفحة كقيمة lastmod (مع تخطي 404 والصفحات noindex). ابنِ قائمة الجوال بلا JavaScript باستخدام <details><summary>Menu</summary>؛ وقائمتا سطح المكتب والجوال عنصرا <nav> منفصلان بقيمتي aria-label مختلفتين.
4. استضف الخطوط بنفسك. يستخدم هذا الموقع عائلة خطوط واحدة وثلاثة ملفات على الأكثر. نزّل CSS الخاص بـ Fontshare (https://api.fontshare.com/v2/css?f[]=family@400,600&display=swap، ورمز الوزن 401 للمائل) عبر site_fetch إلى _kaynak/fontshare.css، واقرأه بـ site_read_file وخذ فقط روابط woff2 للعائلة التي طلبتها؛ فالخدمة تضيف أحيانًا عائلة لم تطلبها. نزّل كل ملف woff2 عبر site_fetch إلى assets/fonts/. ضع قواعد @font-face (مع font-display: swap) داخل assets/app.css، لأن design-check.mjs يبحث عن الخط المخصص في هذا الملف فقط. لا تستخدم الخطوط الافتراضية Inter أو Roboto أو Poppins أو Montserrat.
5. اضبط Tailwind. يصبح assets/app.css مصدر Tailwind: @tailwind base; @tailwind components; @tailwind utilities; في الأعلى، ثم @font-face وحلقة التركيز ورابط التخطي وقاعدة prefers-reduced-motion وفئات المكوّنات الخاصة بك داخل @layer components. لا تعطِ فئة مكوّن اسم فئة أداة في Tailwind (list-item وtable وgrid وcontainer وhidden وما شابه)، لأن التعارض يكسر التخطيط بصمت بعد الترجمة. اكتب tailwind.config.js في الجذر (content: ["./*.html", "./**/*.html", "./_kaynak/*.inc"] والألوان وfontFamily). شغّل "npx --yes tailwindcss@3 -i assets/app.css -o assets/site.css --minify" بـ site_run_command مع background=true، وانتظر نتيجته بـ site_command_status. يحتوي <head> في كل صفحة، بهذا الترتيب، على: <link rel="stylesheet" href="/assets/site.css"> واحد فقط، ثم سطر preload لكل ملف خط مستخدم في الشاشة الأولى (العنوان واللون المميز والنص الأساسي؛ as="font" type="font/woff2" crossorigin). أسطر preload الموضوعة قبل ملف الأنماط تؤخر CSS وتزيد LCP؛ وخط الشاشة الأولى بلا preload يُستبدل متأخرًا ويزحزح الصفحة ويرفع CLS، ثم <link rel="icon" href="/assets/img/favicon.svg" type="image/svg+xml">. سطر الأيقونة إلزامي: من دونه يطلب المتصفح /favicon.ico فيحصل على 404، ويخفض خطأ وحدة التحكم درجة Best Practices.
6. الصور. نزّل الصور بـ site_fetch مع resize وimage_format="webp" بعدة عروض (480 و800 و1200 و1600 لصورة الشاشة الأولى، و480 و800 و1200 للبقية؛ الجودة بين 60 و75، وأقل للصور المفصّلة). لكل <img> قيمة srcset وsizes مطابقة للتخطيط الفعلي وwidth وheight (انزياح تخطيط صفري) ونص alt ذو معنى وصادق. تُضاف fetchpriority="high" فقط إلى الصورة التي يحددها Lighthouse كعنصر LCP، ولا تكون هذه الصورة lazy؛ وكل الصور الأخرى تستخدم loading="lazy". إذا كان عنصر LCP نصًا فلا تحصل أي صورة على fetchpriority. جهّز أيضًا assets/img/logo.png وassets/img/og.jpg بمقاس 1200x630 وassets/img/favicon.svg.
7. قواعد HTML (الإعدادات الافتراضية لـ html-validate). <!DOCTYPE html> بأحرف كبيرة؛ بلا سمة style مضمّنة (بما فيها style="background:var(--brand)" الموجودة في القالب، استخدم فئة بدلًا منها)؛ &nbsp; بدل المسافات العادية في نص روابط tel:؛ سمة type في كل <button>؛ بلا مسافات زائدة في نهاية الأسطر؛ جداول مع <thead> و<tbody> وth scope. الروابط داخل الفقرات تحتها خط؛ وروابط القائمة والتذييل ومسار التنقل والأزرار لها منطقة لمس لا تقل عن 44x44 بكسل (min-h-[44px] min-w-[44px]).
8. البيانات المنظّمة. املأ كتلة seo في site.config.js (siteUrl وdescription وlogo وصورة og ونوع النشاط وحقول العنوان) وشغّل "node seo-stamp.mjs" بـ site_run_command؛ فهو يختم Organization وWebSite، وعند الاقتضاء نوعًا فرعيًا من LocalBusiness، إضافة إلى وسوم canonical وOG. أضف يدويًا مخطط كل صفحة: في كل صفحة عقدة WebPage مع @id (أو AboutPage أو ContactPage أو CollectionPage أو ProfilePage) وdatePublished وdateModified وisPartOf #site وabout #business أو #org وbreadcrumb يشير إلى BreadcrumbList؛ إضافة إلى Service لكل مجال عمل، وPerson لكل ممارس في صفحة الفريق، وArticle وreviewedBy في المذكرة الإرشادية، وFAQPage في صفحة الأسئلة الشائعة. اكتب كل عقدة في كتلة <script type="application/ld+json"> خاصة بها ولا تستخدم غلاف @graph، لأن seo-check.mjs يقرأ فقط @type في المستوى الأعلى ويفوّت BreadcrumbList داخل @graph. اربط العقد بـ @id. لا تخترع أبدًا ساعات عمل أو إحداثيات أو تقييمات أو مراجعات أو جوائز أو أعداد عملاء أو شهادات؛ واترك الحقول المجهولة.
9. وصول الذكاء الاصطناعي. اكتب robots.txt: الموقع كله مفتوح، و/_kaynak/ فقط مغلق؛ Allow: / لكل من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot؛ وقرارك بشأن CCBot مع السبب في تعليق؛ وسطر Sitemap أخيرًا. أضف llms.txt في الجذر: ملخص صحيح من جملتين للنشاط، والصفحات المهمة مع سطر واحد لكل منها، وبيانات التواصل. اكتب 404.html (noindex، مع علامتي الترويسة والتذييل).
10. الكتابة. لكل صفحة 150 كلمة على الأقل من نص أصلي داخل <main>، وتجيب الفقرة الأولى مباشرة عن السؤال الرئيسي للصفحة. تتراوح العناوين بين 48 و60 حرفًا والأوصاف بين 145 و158، وتكون فريدة في كل صفحة. بلا شرطات طويلة أو قصيرة، وبلا شعارات جاهزة، وبلا وعود فارغة. إذا كان أي شيء في الموقع غير حقيقي فاذكر بوضوح أنه خيالي.

البوابات. بعد كل تغيير، شغّل هذه بـ site_run_command بالترتيب ولا تنتقل حتى تنجح كل واحدة:
1. node _kaynak/parca-bas.mjs، ثم node seo-stamp.mjs، ثم بناء Tailwind (مرة أخرى إذا أضفت فئات).
2. node seo-check.mjs: 0 أخطاء و0 تحذيرات. إذا ظهر تحذير "gövde kısa" (النص قصير جدًا) فأضف نصًا حقيقيًا لا حشوًا.
3. node design-check.mjs: 0 أخطاء. التحذير الوحيد المسموح هو "Hiç hareket yok" (لا توجد حركة)؛ فالأسلوب يقتضي ذلك، لذا اذكر السبب في التقرير.
4. npx --yes html-validate "**/*.html": 0 أخطاء.
5. افحص كل صفحة بـ site_preview عند view="mobile" وview="desktop"، وافحص الصفحة الرئيسية أيضًا عند 360 و768 بكسل. أصلح أي تمرير أفقي أو عنوان ضيق أو هدف لمس أصغر من 44 بكسل ثم افحص مجددًا.
6. قِس كل صفحة بـ core_web_vitals عند strategy="mobile" وstrategy="desktop"، ثم دقّق الصفحة الرئيسية وأطول صفحة بـ seo_audit. الهدف: على الجوال، Accessibility وBest Practices وSEO بقيمة 100 وPerformance لا تقل عن 95؛ وعلى سطح المكتب كل الأربعة لا تقل عن 95. يجب ألا يخرج أي طلب خارج الموقع. إذا كان LCP مرتفعًا فاستخدم resources=true لتجد الملف المعطِّل: غالبًا أسطر preload الموضوعة قبل ملف الأنماط، أو fetchpriority الممنوحة لصورة ليست عنصر LCP. وإذا تجاوز CLS القيمة 0.1 فابحث عن خط في الشاشة الأولى بلا preload.
لا تعتبر العمل منجزًا حتى تنجح كل هذه البنود.

بعد النشر، أرسل https://[النطاق]/sitemap.xml بـ gsc_submit_sitemap وافحص الصفحة الرئيسية بـ gsc_url_inspect. إذا لم تكن هناك خاصية في Search Console فأخبرني؛ ولا تحاول ربط واحدة بنفسك.

تقرير التسليم: جدول بدرجات Lighthouse الأربع وقيمة LCP لكل صفحة على الجوال وسطح المكتب، ونتيجة البوابات الأربع، وسبب أي تحذير من design-check، وقائمة بالمعلومات في الموقع التي هي خيالية أو ناقصة، وما يجب عليّ فعله بعد ذلك (Business Profile، وصور حقيقية، وساعات العمل وغيرها).

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقعًا مؤسسيًا متعدد الصفحات بدون JavaScript وسلّمه بدرجة 100

اطلب من مساعدك بناء موقع ثابت وسريع وسهل الوصول لأعمال مؤسسية مثل العمارة أو الهندسة أو الاستشارات. القائمة والتذييل بصيغة HTML ثابتة، والخطوط وملفات CSS مستضافة ذاتيًا، وتُقاس كل صفحة قبل التسليم.

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

أنشئ موقعًا مؤسسيًا متعدد الصفحات وثابتًا بالكامل لنشاطي التجاري على خادم استضافة Opus Growth الخاص بي [اسم الخادم]. النشاط: [اسم النشاط التجاري]، [القطاع، مثل مكتب هندسة وعمارة]، [المدينة/منطقة الخدمة]. الخدمات: [الخدمات مع وصف قصير لكل منها]. الهاتف: [الهاتف]، البريد الإلكتروني: [البريد الإلكتروني]، العنوان: [العنوان]، النطاق: [النطاق]. تفضيل الألوان: [تفضيل اللون/العلامة التجارية، أو "اختيارك"]. الصور: [مكان الصور الحقيقية، أو "استخدم صورًا مناسبة من مكتبات الصور"].

يضع هذا الموقع السرعة وإمكانية الوصول في المقام الأول. لا سطر JavaScript واحد في أي صفحة؛ ولا يتم تحميل GSAP وLenis وSwiper أبدًا. كل شيء، بما في ذلك القائمة وقائمة الجوال والأسئلة الشائعة، يعمل بـ HTML وCSS.

اتجاه التصميم هو "لوحة الرسم الهندسي":
1. الخطوط: خط عناوين غروتسك مضغوط من Fontshare (مثل Cabinet Grotesk 800) وخط نص هادئ (مثل General Sans 400 و600). ثلاثة ملفات خطوط كحد أقصى.
2. اللون: خلفية فاتحة بلون الورق، ونص بحبر داكن، ورمادي ثانوي، ولون تمييز واحد كإشارة. يظهر لون التمييز فقط في التسميات والخطوط الرفيعة والزر الرئيسي. يصل كل لون نص إلى تباين 4.5:1 على الأقل.
3. الشبكة: 12 عمودًا، وتفصل بين الأقسام خطوط بسمك 1 بكسل؛ بدون ظلال أو زوايا مستديرة أو تدرجات.
4. العنصر المميز: تحت صورة الشاشة الأولى، شريط من أربع خلايا بتصميم يشبه لوحة بيانات الرسم المعماري (مثل نوع المشروع، الكود المتبع، المقياس، رقم اللوحة)، وشبكة مليمترية خافتة جدًا مرسومة بـ CSS فقط خلف الشاشة الأولى.
5. الحركة: لا شيء. ولا حتى مدد انتقال؛ فقط يتغير التسطير واللون فورًا عند التمرير بالمؤشر.

الصفحات والمخطط الخاص بكل منها:
1. index.html: شاشة أولى تجيب فقرتها الافتتاحية مباشرة عن سؤال "ماذا تفعلون، ولمن، وأين"، وثلاث بطاقات خدمات (كل منها يرتبط بقسمه)، وعملية من أربع خطوات (مرقمة "الخطوة 1" بعداد CSS، وليس 01/02)، ومثالان على المشاريع، وشريط للهاتف. WebPage.
2. hizmetler.html: قسم لكل خدمة؛ وتجيب الفقرة الأولى عن "متى تلزم، وماذا تفعل"، ثم قائمة النطاق، والمدة المعتادة، والمخرجات. WebPage بالإضافة إلى Service لكل خدمة (provider #business، areaServed).
3. projeler.html: أمثلة مع نوع المبنى والطريقة والنتيجة؛ ولا تُذكر أسماء العملاء إلا بإذنهم. CollectionPage.
4. hakkimizda.html: من نحن، وقواعد عملنا، وأين نعمل. AboutPage.
5. sss.html: ستة أسئلة حقيقية على الأقل داخل <details>. WebPage وFAQPage.
6. iletisim.html: الهاتف والبريد الإلكتروني والعنوان داخل <address>، ورابط خريطة؛ واترك ساعات العمل إن لم تكن تعرفها. ContactPage مع mainEntity #business.
7. kvkk.html (إشعار الخصوصية) و404.html.

القواعد التقنية. اتبعها حرفيًا، لأن الاختبارات أدناه تقيس هذه الأمور بالضبط:

1. الإعداد. شغّل scaffold_site كمعاينة أولًا، وأرني قائمة الملفات، ثم ثبّت باستخدام confirm=true بعد موافقتي. بعد ذلك اقرأ site_design_guide وsite_seo_guide بالكامل. قبل كتابة أي كود، اكتب الاتجاه في _kaynak/ART.md (الإحساس العام، ثنائية الخطوط، الألوان مع نسب التباين، الشبكة، العنصر المميز، قرار الحركة، قائمة الصفحات) وأرني إياه.
2. أزل JavaScript. لا تحمّل أي صفحة في هذا الموقع أي JavaScript. أزل من كل صفحة سكربت cdn.tailwindcss.com وسطر tailwind.config ووسوم GSAP وScrollTrigger وSplitText وLenis وSwiper ووسوم سكربت motion.js وchrome.js وsite.config.js؛ واحذف assets/chrome.js وassets/motion.js. أبقِ على assets/site.config.js، لكن فقط كمصدر للعلامة التجارية وبيانات الاتصال وseo لصالح seo-stamp.mjs؛ ولا يتم تحميله في المتصفح أبدًا.
3. القائمة والتذييل بصيغة HTML ثابتة. يتم رسم المكونين <site-nav> و<site-footer> بواسطة JavaScript، لذلك لا تستطيع زواحف البحث والذكاء الاصطناعي رؤية القائمة والروابط الداخلية وبيانات الاتصال. اكتب الترويسة في _kaynak/ust.inc والتذييل (الاسم، العنوان، الهاتف، البريد الإلكتروني، روابط كل الصفحات، إشعار الخصوصية، "Web: Opus Growth") في _kaynak/alt.inc. استخدم الامتداد .inc حتى لا يعامل seo-stamp وhtml-validate هذه الأجزاء كصفحات. تحمل كل صفحة العلامات  و. ثم اكتب سكربت Node بلا اعتماديات باستخدام site_write_file في _kaynak/parca-bas.mjs: يضع الجزأين بين العلامات في كل ملف HTML، ويضيف aria-current="page" إلى رابط القائمة للصفحة الحالية، ويعيد كتابة sitemap.xml مستخدمًا dateModified من JSON-LD لكل صفحة كـ lastmod (مع تخطي 404 والصفحات noindex). ابنِ قائمة الجوال بدون JavaScript باستخدام <details><summary>Menu</summary>؛ وقائمتا سطح المكتب والجوال عنصرا <nav> منفصلان بقيمتي aria-label مختلفتين.
4. استضف الخطوط بنفسك. يستخدم هذا الموقع ثلاثة ملفات خطوط كحد أقصى. نزّل CSS الخاص بـ Fontshare (https://api.fontshare.com/v2/css?f[]=family@400,600&display=swap، ورمز الوزن 401 للخط المائل) باستخدام site_fetch إلى _kaynak/fontshare.css، واقرأه بـ site_read_file وخذ فقط روابط woff2 للعائلة التي طلبتها؛ فالخدمة تضيف أحيانًا عائلة لم تطلبها. نزّل كل ملف woff2 باستخدام site_fetch إلى assets/fonts/. ضع قواعد @font-face (مع font-display: swap) داخل assets/app.css، لأن design-check.mjs يبحث عن الخط المخصص في هذا الملف فقط. لا تستخدم الخطوط الافتراضية Inter وRoboto وPoppins وMontserrat.
5. اجعل Tailwind يُترجم. يصبح assets/app.css مصدر Tailwind: @tailwind base; @tailwind components; @tailwind utilities; في الأعلى، ثم @font-face، وحلقة التركيز، ورابط التخطي، وقاعدة prefers-reduced-motion، وفئات المكونات الخاصة بك داخل @layer components. لا تسمِّ فئة مكوّن أبدًا باسم فئة Tailwind (list-item وtable وgrid وcontainer وhidden وغيرها)، لأن التعارض يكسر التخطيط بصمت بعد الترجمة. اكتب tailwind.config.js في الجذر (content: ["./*.html", "./**/*.html", "./_kaynak/*.inc"]، والألوان وfontFamily). شغّل "npx --yes tailwindcss@3 -i assets/app.css -o assets/site.css --minify" باستخدام site_run_command مع background=true، وانتظر باستخدام site_command_status. يحتوي <head> في كل صفحة، بهذا الترتيب، على: عنصر واحد <link rel="stylesheet" href="/assets/site.css">، ثم سطر preload واحد لكل ملف خط مستخدم في الشاشة الأولى (العناوين والتمييز والنص؛ as="font" type="font/woff2" crossorigin). أسطر preload الموضوعة قبل ملف الأنماط تؤخر CSS وتزيد LCP؛ والخط في الشاشة الأولى بلا preload يتبدل متأخرًا ويزحزح الصفحة ويرفع CLS، و<link rel="icon" href="/assets/img/favicon.svg" type="image/svg+xml">. سطر الأيقونة إلزامي: بدونه يطلب المتصفح /favicon.ico ويحصل على 404، ويخفض خطأ وحدة التحكم درجة أفضل الممارسات.
6. الصور. نزّل الصور باستخدام site_fetch مع resize وimage_format="webp" بعدة عروض (480 و800 و1200 و1600 لصورة الشاشة الأولى، و480 و800 و1200 للبقية؛ بجودة بين 60 و75، وأقل للصور كثيرة التفاصيل). لكل <img> سمة srcset وsizes تطابق التخطيط الفعلي وwidth وheight (انزياح صفري) ونص alt مفيد وصادق. توضع fetchpriority="high" فقط على الصورة التي يحددها Lighthouse كعنصر LCP، ولا تكون هذه الصورة lazy؛ وكل صورة أخرى تستخدم loading="lazy". إذا كان عنصر LCP نصًا، فلا تحصل أي صورة على fetchpriority. جهّز أيضًا assets/img/logo.png وassets/img/og.jpg بمقاس 1200x630 وassets/img/favicon.svg.
7. قواعد HTML (الإعدادات الافتراضية لـ html-validate). <!DOCTYPE html> بأحرف كبيرة؛ لا سمة style مضمّنة (بما فيها style="background:var(--brand)" الخاصة بالحزمة، استخدم فئة بدلًا منها)؛ استخدم &nbsp; بدل المسافات العادية في نص روابط tel:؛ سمة type في كل <button>؛ لا مسافات زائدة في نهاية الأسطر؛ جداول بـ <thead> و<tbody> وth scope. الروابط داخل الفقرات تحتها خط؛ وروابط القائمة والتذييل ومسار التنقل والأزرار لها مساحة لمس لا تقل عن 44x44 بكسل (min-h-[44px] min-w-[44px]).
8. البيانات المنظمة. املأ كتلة seo في site.config.js (siteUrl وdescription وlogo وصورة og ونوع النشاط وحقول العنوان) وشغّل "node seo-stamp.mjs" باستخدام site_run_command؛ فهو يضع Organization وWebSite، وعند الحاجة نوعًا فرعيًا من LocalBusiness، بالإضافة إلى وسوم canonical وOG. أضف يدويًا المخطط الخاص بكل صفحة: في كل صفحة عقدة WebPage مع @id (أو AboutPage أو ContactPage أو CollectionPage أو ProfilePage)، وdatePublished وdateModified، وisPartOf #site، وabout #business أو #org، وbreadcrumb يشير إلى BreadcrumbList؛ بالإضافة إلى Service لكل خدمة في صفحة الخدمات وFAQPage في صفحة الأسئلة الشائعة. اكتب كل عقدة في كتلة <script type="application/ld+json"> خاصة بها ولا تستخدم غلاف @graph، لأن seo-check.mjs يقرأ فقط @type في المستوى الأعلى ولا يلتقط BreadcrumbList داخل @graph. اربط العقد بـ @id. لا تختلق أبدًا ساعات عمل أو إحداثيات أو تقييمات أو مراجعات أو جوائز أو أعداد عملاء أو شهادات؛ واترك الحقول غير المعروفة.
9. وصول الذكاء الاصطناعي. اكتب robots.txt: الموقع كله مفتوح، و/_kaynak/ فقط مغلق؛ Allow: / لكل من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot؛ وقرارك بشأن CCBot مع السبب في تعليق؛ وسطر Sitemap أخيرًا. أضف llms.txt في الجذر: ملخص صحيح للنشاط في جملتين، والصفحات المهمة بسطر لكل منها، وبيانات الاتصال. اكتب 404.html (noindex، مع علامات الترويسة والتذييل).
10. الكتابة. كل صفحة تحتوي على 150 كلمة على الأقل من نص أصلي داخل <main>، وتجيب الفقرة الأولى مباشرة عن السؤال الرئيسي للصفحة. تتراوح العناوين بين 48 و60 حرفًا، والأوصاف بين 145 و158، وتكون فريدة في كل صفحة. بلا شرطات طويلة أو متوسطة، ولا شعارات جاهزة، ولا وعود فارغة. إذا كان أي شيء في الموقع غير حقيقي، فاذكر بوضوح أنه خيالي.

الاختبارات. بعد كل تغيير، شغّلها باستخدام site_run_command بهذا الترتيب ولا تنتقل إلى التالي حتى يكون كل اختبار نظيفًا:
1. node _kaynak/parca-bas.mjs، ثم node seo-stamp.mjs، ثم ترجمة Tailwind (مرة أخرى إن أضفت فئات).
2. node seo-check.mjs: 0 أخطاء و0 تحذيرات. إذا ظهر التحذير "gövde kısa" (النص قصير جدًا)، فأضف نصًا حقيقيًا وليس حشوًا.
3. node design-check.mjs: 0 أخطاء. التحذير الوحيد المسموح به هو "Hiç hareket yok" (لا توجد حركة)؛ فهذا اختيار متعمد لهذا الموقع، فاذكر السبب في التقرير.
4. npx --yes html-validate "**/*.html": 0 أخطاء.
5. افحص كل صفحة باستخدام site_preview عند view="mobile" وview="desktop"، وافحص الصفحة الرئيسية أيضًا عند 360 و768 بكسل. أصلح أي تجاوز أفقي أو عنوان ضيق أو هدف لمس أصغر من 44 بكسل ثم افحص مرة أخرى.
6. قِس كل صفحة باستخدام core_web_vitals عند strategy="mobile" وstrategy="desktop"، ثم دقّق الصفحة الرئيسية وأطول صفحة باستخدام seo_audit. الهدف: على الجوال، إمكانية الوصول وأفضل الممارسات وSEO بدرجة 100 والأداء 95 على الأقل؛ وعلى سطح المكتب الأربعة 95 على الأقل. يجب ألا يخرج أي طلب واحد من الموقع. إذا كان LCP مرتفعًا، فاستخدم resources=true لإيجاد الملف الذي يعطله: غالبًا أسطر preload الموضوعة قبل ملف الأنماط، أو fetchpriority الممنوحة لصورة ليست عنصر LCP. وإذا تجاوز CLS القيمة 0.1، فابحث عن خط في الشاشة الأولى لا يملك preload.
لا تعتبر العمل منتهيًا حتى تنجح كل هذه الاختبارات.

بعد النشر، أرسل https://[النطاق]/sitemap.xml باستخدام gsc_submit_sitemap وافحص الصفحة الرئيسية باستخدام gsc_url_inspect. إذا لم يكن هناك موقع مضاف في Search Console، فأخبرني؛ ولا تحاول ربط واحد بنفسك.

تقرير التسليم: جدول بدرجات Lighthouse الأربع وLCP لكل صفحة على الجوال وسطح المكتب، ونتيجة الاختبارات الأربعة، وسبب أي تحذير من design-check، وقائمة بالمعلومات في الموقع التي تكون خيالية أو ناقصة، وما لا يزال عليّ فعله (Business Profile، وصور حقيقية، وساعات العمل وغيرها).

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ صفحة حملة بلا نموذج لزيارات الإعلانات تدفع إلى المكالمات وWhatsApp، مع وسم التحويلات

تنشئ صفحة واحدة لزيارات Google Ads وMeta تكرر وعد الإعلان وتوفر أزرار الاتصال وWhatsApp والحجز. تسجّل النقرات كأحداث dataLayer، وتضبط وضع الموافقة، وتضيف مشغّلات ووسوم Tag Manager بعد موافقتك، وتقيس سرعة الصفحة مع الوسوم وبدونها.

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

على خادم الاستضافة الخاص بي في Opus Growth [اسم الخادم]، أنشئ صفحة حملة واحدة لزيارات إعلانات Google Ads وMeta، بالإضافة إلى صفحة خصوصية. لا يوجد نموذج؛ يتواصل الزوار معنا عبر الهاتف أو WhatsApp أو رابط حجز. التفاصيل: النشاط التجاري [اسم النشاط]، الخدمة [الخدمة]، المنطقة [الأحياء]، الهاتف [الهاتف]، WhatsApp [الرقم]، رابط الحجز [الرابط أو "لا يوجد"]، العنوان [العنوان]، ساعات العمل [ساعات العمل]، عناوين الإعلانات والعرض الرئيسي [العناوين والعرض]، حاوية Tag Manager [GTM-XXXXXXX]، حساب Google Ads [اسم الحساب]، حساب إعلانات Meta [اسم الحساب].

تطابق الرسالة: يكرر وسم h1 وعد عنوان الإعلان بالكلمات نفسها (الخدمة، المنطقة، العرض الرئيسي). لا تضع في الصفحة وعدًا غير موجود في الإعلان، ولا في الإعلان وعدًا غير موجود في الصفحة. إذا اختلف عنوانا Google وMeta، فاستخدم عنوان الإعلان الأكثر إنفاقًا، واقترح كيف يمكن مواءمة الإعلان الآخر مع الصفحة. في المجالات الصحية أو القانونية أو المالية، لا تعد بنتيجة مؤكدة ("مضمون"، "100%").

بنية الصفحة: يحتوي الشريط العلوي على اسم العلامة التجارية وزر اتصال فقط، بلا قائمة، حتى لا ينصرف الزوار عن الصفحة. القسم الرئيسي: h1، ووصف من جملة واحدة، وثلاثة أزرار (اتصل الآن، راسلنا على WhatsApp، اختر موعدًا)، وأربع نقاط طمأنة قصيرة تحتها، وصورة. ثم العملية في ثلاث خطوات، وما الذي يحدد السعر (الإجابة أولًا إذا كنت لا تنشر الأسعار)، والأسئلة الشائعة، ودعوة ختامية لاتخاذ إجراء، وتذييل يضم الاسم والعنوان والهاتف ورابط الخصوصية. على الجوال، ثبّت شريطًا من زرين (اتصال، WhatsApp) أسفل الشاشة، وأضف إلى الجسم حشوة سفلية بالارتفاع نفسه حتى لا يختفي شيء تحته ولا يتحرك شيء. يستخدم رابط WhatsApp الصيغة wa.me مع رسالة معبأة مسبقًا. حافظ على مظهر بسيط وموثوق: عائلة خطوط واحدة (مثل General Sans بوزنين)، ولون تمييز واحد، وزر WhatsApp أخضر داكن بتباين لا يقل عن 4.5:1 مع النص الأبيض.

قواعد الحركة والقياس:
1. حركة خفيفة بلا مكتبات: لا تحمّل GSAP أو Lenis أو Swiper. انتقالات التمرير والضغط على الأزرار؛ وفي بطاقات الخطوات، ارتفاع صغير مرتبط بالتمرير يستخدم transform فقط، داخل `@supports (animation-timeline: view())` ولا يُطبَّق إلا على الزوار الذين لم يطلبوا تقليل الحركة. لا تستخدم opacity: في العرض التجريبي، فشلت البطاقات الباهتة أسفل الشاشة في اختبار التباين وأنزلت إمكانية الوصول إلى 96. لا شيء في الشاشة الأولى يبدأ برسوم متحركة للظهور.
2. حمّل طبقة القياس باسم `assets/tag.js` مع defer:
   أ. `window.dataLayer` والإعدادات الافتراضية لـ Consent Mode v2: ad_storage وad_user_data وad_personalization وanalytics_storage بقيمة "denied"، وwait_for_update بقيمة 500.
   ب. أعطِ كل رابط إجراء data-conv="phone" أو "whatsapp" أو "booking" وسمة data-conv-place باسم قسمه. يدفعها مستمع نقر واحد إلى dataLayer على شكل `{event: "phone_click" | "whatsapp_click" | "booking_click", conv_place, page_path}`.
   ج. لا تضع مقتطف GTM الكلاسيكي في `<head>`؛ بل أدرجه بعد حدث load باستخدام requestIdleCallback، حتى لا تؤخر الوسوم أول عرض للصفحة.
   د. أضف شريط موافقة صغيرًا ثابتًا: زرا الرفض والقبول بوزن متساوٍ، ويُخزَّن الاختيار في المتصفح ويُرسل كتحديث للموافقة. على الجوال يظهر فوق شريط الإجراءات وبمستوى منخفض بما يكفي حتى لا يغطي الزر الرئيسي في القسم الرئيسي.
3. Tag Manager: اعرض أولًا الحالة الحالية باستخدام list_gtm_containers وlist_gtm_triggers وgtm_workspace_status. اقترح ثلاثة مشغلات من نوع Custom Event باستخدام create_gtm_trigger (phone_click وwhatsapp_click وbooking_click). ابحث عن تحويل التواصل وقيمة send_to الخاصة به في Google Ads باستخدام list_conversion_actions وget_conversion_tags. حتى لا يُحتسب الشخص الذي يتصل ويراسل معًا مرتين، اقترح ربط الهاتف وWhatsApp بتحويل واحد باسم "نقرة تواصل" يُحتسب مرة واحدة؛ وإن لم يكن موجودًا، فاذكر ما كنت ستنشئه وانتظر موافقتي. اقترح وسم تحويل لـ Google Ads باستخدام create_gtm_tag (tag_type "sp"). بالنسبة إلى Meta، ابحث عن البكسل باستخدام list_meta_pixels؛ وإن لم يكن كود البكسل الأساسي في الحاوية، فاقترحه كوسم Custom HTML على جميع الصفحات، واقترح بشكل منفصل الوسوم التي ترسل `fbq('track','Contact')` عند النقرات و`fbq('track','Schedule')` عند الحجز. شغّل كل أداة أولًا بالقيمة confirm=false، واعرض قائمة التغييرات، وأنشئها بعد موافقتي. اعرض publish_gtm_container أولًا بالقيمة confirm=false، وانشر بعد موافقتي، وأشِر إلى النسخة التي يمكن استعادتها.
4. خطة الاختبار: اكتب خطوة بخطوة كيف يمكنني أن أرى في وضع المعاينة في GTM أي وسم يعمل عند كل زر من الأزرار الثلاثة، وأنه لا يُكتب أي ملف تعريف ارتباط إعلاني عند رفض الموافقة.
5. بعد إضافة GTM والوسوم، شغّل core_web_vitals مرة أخرى، لأن الوسوم قد تخفض الدرجة، واعرض الفرق في جدول. وحتى لا تحجب مانعات الإعلانات وسم Google، اعرض معاينة لمسار القياس من الطرف الأول باستخدام site_tag_gateway وأعدّه بعد موافقتي.

الإعداد والمزالق المعروفة (كل واحدة منها خفضت درجة في قياسات العرض التجريبي، فلا تتجاوز أيًا منها):
1. إذا كان هناك موقع يعمل بالفعل على الخادم، فأخبرني أولًا، لأن الإعداد يستبدل index.html ومجلد assets. اعرض معاينة scaffold_site مع confirm=false واستدعه مع confirm=true بعد موافقتي. ثم اقرأ site_design_guide وsite_seo_guide. قبل كتابة الكود، ضع اتجاه التصميم (الخطوط، والألوان، والشبكة، والعنصر المميز، ولغة الحركة، والمكتبات التي لن تُحمَّل) في ملف ART.md قصير خارج assets واعرضه علي.
2. اجعل Tailwind مُجمَّعًا بدل تحميله من CDN. ثبّته باستخدام site_run_command مع background=true: `npm i -D tailwindcss@3`، ثم تابعه بـ site_command_status. يجب أن تغطي مسارات content في `tailwind.config.js` كل ملفات HTML والقوالب وأي ملف JS يكتب أسماء الفئات. يحتوي `_src/tw.css` على السطر `@import "../assets/app.css";` وأسطر `@tailwind` الثلاثة؛ جمّعه في ملف واحد بالأمر `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. أزل سكربت cdn.tailwindcss.com وإعداد tailwind.config المضمّن من كل صفحة، واربط `/assets/site.css` فقط. أعد التجميع بعد كل تغيير في HTML.
3. استضف الخطوط بنفسك. اقرأ CSS لعائلات Fontshare التي اخترتها، ونزّل ملف woff2 لكل وزن إلى `assets/fonts/` باستخدام site_fetch، واكتب قواعد @font-face مع `font-display: swap` في `assets/app.css`؛ فـ design-check يبحث هناك عن خط مخصص. تحقق من اسم font-family في CSS الذي نزّلته، لأن Fontshare قد تعيد عائلة مختلفة عندما لا يتوفر وزن ما. نفّذ preload لخط عنوان الشاشة الأولى وخط النص الأساسي في كل صفحة باستخدام `<link rel="preload" as="font" type="font/woff2" crossorigin>`؛ في العرض التجريبي أزال هذا اهتزاز التخطيط الناتج عن تبديل الخط (CLS من 0.024 إلى 0). معظم خطوط Fontshare لا تحتوي على رمز ₺، لذا اكتب "TL" في الأسعار.
4. اجعل القائمة والتذييل HTML ثابتًا. لا تحمّل chrome.js أو site.config.js في الصفحات. اكتب ملف `chrome-stamp.mjs` صغيرًا يقرأ قائمة التنقل في site.config.js ويختم `_src/header.tpl` و`_src/footer.tpl` بين العلامتين `` و`` في كل صفحة، مع إضافة aria-current="page" إلى الرابط الحالي. لا تعطِ القوالب امتداد .html واستخدم عناصر نائبة مثل `[[NAV]]` بدل `{{...}}`، وإلا فسيقرأها design-check وseo-check على أنها صفحات غير مكتملة. ابنِ قائمة الجوال بدون JS باستخدام `<details>`. أبقِ اسم النشاط والعنوان والهاتف في التذييل كنص عادي.
5. حوّل الصور أثناء تنزيلها باستخدام site_fetch: اكتب الصورة نفسها في ملفات منفصلة مع resize="480x" و"800x" و"1200x"، وimage_format="webp"، وquality=65. أعطِ كل `<img>` السمات srcset وsizes وwidth وheight. الصورة الرئيسية في الشاشة الأولى تأخذ fetchpriority="high" ولا تكون lazy أبدًا؛ وباقي الصور تأخذ loading="lazy" decoding="async". إذا كانت الصورة الرئيسية تملأ شاشة الجوال، فقدّم اقتطاعًا أعرض وأصغر على الجوال باستخدام `<picture>` (في العرض التجريبي انخفض حجم صورة القسم الرئيسي على الجوال من 89 KB إلى 43 KB).
6. أنشئ أيقونة favicon بصيغة PNG بحجم 48 px من الشعار باستخدام site_fetch وأضف `<link rel="icon">` إلى كل صفحة. بدونها يسجل المتصفح خطأ 404 وتنخفض Best Practices إلى 96.
7. قواعد مدقق HTML: ابدأ كل مستند بـ `<!DOCTYPE html>` بأحرف كبيرة (ملفات البداية في الحزمة تستخدم أحرفًا صغيرة)، واستخدم `&nbsp;` للمسافات في النص المرئي لروابط tel:، ولا تستخدم السمة style="" أبدًا، وأعطِ كل زر type="button".

SEO وAEO وGEO:
1. استخدم عناوين URL للمجلدات مع شرطة مائلة في النهاية (/gizlilik/). املأ كتلة seo في site.config.js وشغّل `node seo-stamp.mjs`. اكتب مخطط schema الخاص بكل صفحة (في صفحة الحملة WebPage، وService مرتبط بـ #business بصفته provider مع areaServed، وFAQPage؛ وفي صفحة الخصوصية WebPage وBreadcrumbList. في site.config.js استخدم النوع الفرعي الأدق من LocalBusiness، مثل HousePainter أو Plumber أو Dentist. تشرح صفحة الخصوصية ملفات تعريف الارتباط ووسوم القياس وكيفية تغيير اختيار الموافقة) في كتل `<script type="application/ld+json">` منفصلة واربطها بالرسم البياني الأساسي عبر @id. لا تدفن BreadcrumbList داخل @graph؛ أعطه كتلته الخاصة، لأنها الطريقة الوحيدة التي يراه بها seo-check.
2. العناوين من 48 إلى 60 حرفًا (يعدّ seo-check أي عنوان يتجاوز 65 خطأً)، والأوصاف من 145 إلى 158 حرفًا، وh1 واحد لكل صفحة. تحتاج كل صفحة إلى 150 كلمة على الأقل من المحتوى الرئيسي؛ وصفحتا التواصل والخصوصية تميلان إلى أن تكونا أقصر.
3. تجيب الفقرة الأولى في كل صفحة مباشرة عن سؤال الصفحة. اكتب قسم أسئلة شائعة خاصًا بالصفحة باستخدام `<details>` ووسمه بـ FAQPage. أظهر المؤسسة الناشرة وتاريخ "آخر تحديث" باستخدام `<time>`.
4. في robots.txt، اكتب قرارك مع سببه لكل من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot وCCBot، وأشِر إلى خريطة الموقع. يحمل sitemap.xml تواريخ lastmod حقيقية. يضم llms.txt ملخصًا دقيقًا للموقع في جملتين وقائمة بالصفحات الرئيسية.
5. لا تخترع شيئًا: لا مراجعات ولا تقييمات ولا جوائز ولا أعداد عملاء ولا شهادات ولا ساعات عمل ولا إحداثيات ولا أسعار ما لم أزودك بها. اترك الحقول المجهولة خارج schema.

بوابات التحقق (بالترتيب؛ لا تعتبر العمل منتهيًا حتى تنجح جميعها):
1. باستخدام site_run_command شغّل `node chrome-stamp.mjs` وبناء Tailwind و`node seo-stamp.mjs` و`node seo-check.mjs` (0 أخطاء، 0 تحذيرات) و`node design-check.mjs` (0 أخطاء؛ برّر أي تحذير متبقٍ) و`npx html-validate "**/*.html"` (0 أخطاء).
2. اعرض كل صفحة باستخدام site_preview مع view="mobile" وview="desktop". يلتقط site_preview الصفحة مع إيقاف الحركة (reduced-motion)، فإذا كان هناك محتوى مفقود في تلك الصورة، فهذا يعني أن حالة عدم الحركة معطلة. في لقطات الصفحة الكاملة قد تظهر الصور الكسولة في الأسفل فارغة؛ هذا ليس خطأً، لكن تحقق من مساراتها.
3. شغّل core_web_vitals لكل صفحة مع strategy="mobile" وstrategy="desktop". النجاح: على الجوال Performance لا تقل عن 95، وAccessibility وBest Practices وSEO تساوي 100؛ وعلى سطح المكتب الأربعة جميعها لا تقل عن 95. في أي صفحة تفشل، استخدم resources=true للعثور على الملف الذي يعطلها، وأصلحه، ثم قِس مجددًا. بعد ذلك شغّل seo_audit على الصفحة الرئيسية مع strategy="mobile" وruns=2. يجب ألا تحتوي قائمة طلبات الشبكة على أي مضيف غير نطاقك الخاص.
4. لا تمرير أفقي عند العروض 360 و390 و768 و1440 px، وأهداف اللمس لا تقل عن 44 px، ولا أخطاء في وحدة التحكم.

ولأن هذه صفحة هبوط إعلانية، قِسها أيضًا بدون الوسوم: درجات البوابات خاصة بالصفحة بدون وسوم، وتُقاس الصفحة مع الوسوم بشكل منفصل في الخطوة 5.

بعد النشر: اعرض معاينة القاعدة `/assets/* Cache-Control: public, max-age=31536000, immutable` باستخدام site_headers وطبّقها بعد موافقتي؛ ومن ذلك الحين، غيّر أسماء ملفات CSS أو JS عندما تتغير (site-v2.css وهكذا). أرسل sitemap.xml باستخدام gsc_submit_sitemap وافحص الصفحة الرئيسية باستخدام gsc_url_inspect. اختم بجدول درجات لكل صفحة (الصفحة، أربع درجات للجوال، أربع درجات لسطح المكتب، LCP، CLS)، ونتائج البوابات، وقائمة الإصلاحات التي طبقتها.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقع SaaS داكنًا وسريعًا بقصة منتج مثبّتة تتحرك مع التمرير باستخدام GSAP

ينشئ موقع منتج متعدد الصفحات على خادم الاستضافة الخاص بك، بقصة منتج مثبّتة باستخدام ScrollTrigger ومرتبطة بحركة التمرير، وظهور للعناوين عبر SplitText، وتمرير سلس بواسطة Lenis. تُحمَّل مكتبات الحركة فقط حيث تلزم وبعد الرسم الأول، ويُقاس Lighthouse على الجوال ويُحافظ عليه فوق 95.

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

على خادم الاستضافة الخاص بي في Opus Growth [اسم الخادم]، ابنِ موقعًا داكنًا متعدد الصفحات للمنتج [اسم المنتج] يروي قصته أثناء تمرير الزائر للصفحة. المنتج: [ما يفعله، ولمن هو موجّه]. الخطوات الثلاث التي يتبعها المستخدم في المنتج: [ثلاث خطوات]. الميزات الرئيسية: [من 4 إلى 6 ميزات]. التواصل: [البريد الإلكتروني]، [الهاتف]، [رقم WhatsApp]، [العنوان إن وُجد]. النطاق: [النطاق]. تفضيل اللون: [اللون أو "اختر أنت"]. لقطات شاشة أو صور حقيقية للمنتج: [روابط أو "لا يوجد"].

الصفحات: الرئيسية (/)، المنتج (/urun/)، من نحن (/hakkimizda/)، اتصل بنا (/iletisim/)، الخصوصية (/gizlilik/) و404.html. أقسام الصفحة الرئيسية بالترتيب: القسم الرئيسي hero (h1، وصف من جملتين، زران، صورة المنتج)، قصة المنتج بوصفها العنصر المميّز، الميزات، لمن هو موجّه، الأسئلة الشائعة FAQ، ودعوة ختامية لاتخاذ إجراء. لا نموذج في صفحة اتصل بنا؛ استخدم البريد الإلكتروني والهاتف ورابط WhatsApp مع رسالة معبأة مسبقًا، لأن الخادم يقدّم الملفات الثابتة فقط.

الأسلوب: حركة داكنة. خلفية داكنة، ولون تمييز واحد هادئ (ليس نيون)، وخط عناوين grotesk مضغوط من Fontshare (مثل Cabinet Grotesk) وخط نص هادئ (مثل Switzer). بلا تدرجات لونية وبلا WebGL؛ احتفظ بالجرأة لقصة المنتج.

قواعد الحركة (الجزء الأصعب، اتبعها حرفيًا):
1. المكتبات: GSAP 3.13 core وScrollTrigger وSplitText وLenis. نزّلها من jsdelivr إلى `assets/vendor/` باستخدام site_fetch وثبّت الإصدار. حمّلها في الصفحتين الرئيسية والمنتج فقط؛ صفحات من نحن واتصل بنا والخصوصية لا تحمل أي سكربت إطلاقًا. لا تحمّل Swiper.
2. لا تضف هذه المكتبات بـ `<script defer>`. ضع محمّلًا صغيرًا في نهاية الصفحة: بعد حدث load ينتظر استدعاءين لـ requestAnimationFrame ثم requestIdleCallback، ويضيف السكربتات بالترتيب مع async=false، ولا ينزّل شيئًا إذا لم يكن في `<html>` الصنف `anim`. في العرض التجريبي، دفعت المكتبات المؤجلة LCP على الجوال إلى 3.2 ثانية وتركت الأداء عند 92؛ ومع هذا المحمّل وصل إلى 99.
3. سكربت من سطر واحد في `<head>` يضيف الصنف `js` إلى `<html>`، والصنف `anim` ما لم تكن قيمة prefers-reduced-motion هي "reduce". عرّف حالات البداية المخفية تحت `.anim` فقط، بحيث يكون المحتوى ظاهرًا من البداية عند تعطيل JS أو للزوار الذين يفضّلون حركة أقل، ولا تُنزَّل المكتبات لهم أبدًا. كشبكة أمان في حال فشل تحميل إحدى المكتبات، أضف حركة CSS تجعل كل عنصر مخفي ظاهرًا بعد 2.5 ثانية. إذا وصل JS بعد ذلك، فلا تُخفِ المحتوى الظاهر مرة أخرى؛ ابنِ القصة المثبتة فقط.
4. دخول العنوان بـ SplitText: العنوان h1 في الشاشة الأولى هو عنصر LCP، فلا تبدأه مخفيًا أبدًا. يبدأ h1 ظاهرًا بلون خافت ما زال يجتاز تباين AA، ويقوم SplitText بإحضار أسطره إلى اللون الكامل واحدًا تلو الآخر (مع تفعيل خياري mask وaria). أبقِ دخول الأسطر المقنّعة الصاعدة لعناوين h2 الأبعد في الصفحة وشغّله عند التمرير باستخدام ScrollTrigger.
5. العنصر المميّز: في قصة المنتج، استخدم pin وscrub من ScrollTrigger عبر gsap.matchMedia فقط عند عرض 768 بكسل فأكثر (scrub نحو 0.6، وend "+=180%"). في اليسار تصبح الخطوات الثلاث نشطة واحدة تلو الأخرى؛ وفي اليمين تمتلئ شاشة المنتج خطوة بخطوة. لا تُعتّم الخطوات غير النشطة بـ opacity؛ غيّر لون العنوان وخط الحد فقط. في العرض التجريبي، فشلت الخطوات المعتّمة بـ opacity في التباين على سطح المكتب وأنزلت إمكانية الوصول إلى 95. على الجوال لا يوجد pin؛ تظهر الخطوات في التدفق العادي. بدون JS، تعرض شاشة المنتج حالتها النهائية.
6. فعّل Lenis فقط على الأجهزة `(pointer: fine)` لتحتفظ أجهزة اللمس بالتمرير الأصلي. شغّل Lenis من gsap.ticker وانقل التركيز إلى الهدف بعد التمرير إلى رابط داخل الصفحة.
7. شاشة المنتج شكل زخرفي مع aria-hidden وfigcaption يوضح ما تعرضه. كل تفاعل يعمل بلوحة المفاتيح وتبقى حلقة التركيز ظاهرة.

الإعداد والمزالق المعروفة (كل واحدة منها خفضت درجة في قياسات العرض التجريبي، فلا تتجاوزها):
1. إذا كان هناك موقع يعمل بالفعل على الخادم، فأخبرني أولًا، لأن الإعداد يستبدل index.html ومجلد assets. اعرض معاينة لـ scaffold_site مع confirm=false واستدعه مع confirm=true بعد موافقتي. ثم اقرأ site_design_guide وsite_seo_guide. قبل كتابة الكود، ضع اتجاه التصميم (الطباعة، اللون، الشبكة، العنصر المميّز، لغة الحركة والمكتبات التي لن تُحمَّل) في ملف ART.md قصير خارج assets وأره لي.
2. اعمل على ترجمة Tailwind إلى ملف جاهز بدلًا من تحميله من CDN. ثبّته باستخدام site_run_command مع background=true: `npm i -D tailwindcss@3`، ثم تابعه بـ site_command_status. يجب أن تغطي مسارات content في `tailwind.config.js` كل ملفات HTML والقوالب وأي ملف JS يكتب أسماء الأصناف. يحتوي `_src/tw.css` على السطر `@import "../assets/app.css";` وأسطر `@tailwind` الثلاثة؛ ترجمه إلى ملف واحد بالأمر `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. أزل سكربت cdn.tailwindcss.com وإعداد tailwind.config المضمّن من كل الصفحات واربط `/assets/site.css` فقط. أعد الترجمة بعد كل تغيير في HTML.
3. استضف الخطوط بنفسك. اقرأ CSS لعائلات Fontshare التي اخترتها، ونزّل ملف woff2 لكل وزن إلى `assets/fonts/` باستخدام site_fetch، واكتب قواعد @font-face مع `font-display: swap` في `assets/app.css`؛ فأداة design-check تبحث عن خط مخصص هناك. تحقق من اسم font-family في CSS الذي نزّلته، لأن Fontshare قد تعيد عائلة مختلفة عندما لا يوجد وزن معين. أضف preload لخط عنوان الشاشة الأولى وخط النص في كل صفحة بـ `<link rel="preload" as="font" type="font/woff2" crossorigin>`؛ في العرض التجريبي أزال هذا انزياح التخطيط الناتج عن تبديل الخط (CLS من 0.024 إلى 0). معظم خطوط Fontshare لا تحتوي على رمز ₺، لذا اكتب "TL" للأسعار.
4. اجعل القائمة والتذييل HTML ثابتًا. لا تحمّل chrome.js ولا site.config.js في الصفحات. اكتب `chrome-stamp.mjs` صغيرًا يقرأ قائمة التنقل في site.config.js ويختم `_src/header.tpl` و`_src/footer.tpl` بين علامتي `` و`` في كل صفحة، مع إضافة aria-current="page" إلى الرابط الحالي. لا تعطِ القوالب امتداد .html واستخدم عناصر نائبة مثل `[[NAV]]` بدل `{{...}}`، وإلا قرأتها design-check وseo-check كصفحات غير مكتملة. ابنِ قائمة الجوال بدون JS باستخدام `<details>`. أبقِ اسم النشاط والعنوان والهاتف في التذييل نصًا عاديًا.
5. حوّل الصور أثناء تنزيلها بـ site_fetch: اكتب الصورة نفسها في ملفات منفصلة مع resize="480x" و"800x" و"1200x"، وimage_format="webp"، وquality=65. أعطِ كل `<img>` الخصائص srcset وsizes وwidth وheight. تحصل الصورة الرئيسية في الشاشة الأولى على fetchpriority="high" ولا تكون lazy أبدًا؛ أما الباقي فتحصل على loading="lazy" decoding="async". إذا كانت الصورة الرئيسية تملأ شاشة الهاتف، فقدّم اقتطاعًا أعرض وأصغر على الجوال باستخدام `<picture>` (في العرض التجريبي انخفض حجم صورة hero على الجوال من 89 KB إلى 43 KB).
6. أنشئ favicon بصيغة PNG بحجم 48 بكسل من الشعار باستخدام site_fetch وأضف `<link rel="icon">` إلى كل صفحة. بدونه يسجّل المتصفح خطأ 404 وتنخفض أفضل الممارسات إلى 96.
7. قواعد مدقّق HTML: ابدأ كل مستند بـ `<!DOCTYPE html>` بأحرف كبيرة (ملفات البداية في الحزمة تستخدم أحرفًا صغيرة)، واستخدم `&nbsp;` للمسافات في النص المرئي لروابط tel:، ولا تستخدم أبدًا السمة style=""، وأعطِ كل زر type="button".

SEO وAEO وGEO:
1. استخدم روابط المجلدات مع الشرطة المائلة في النهاية (/urun/، /hakkimizda/، /iletisim/، /gizlilik/). املأ كتلة seo في site.config.js ونفّذ `node seo-stamp.mjs`. اكتب schema الخاص بكل صفحة (الرئيسية WebPage وFAQPage؛ المنتج SoftwareApplication وFAQPage؛ من نحن AboutPage؛ اتصل بنا ContactPage؛ وBreadcrumbList في الصفحات الداخلية. وإذا كانت شركة برمجيات بلا متجر فعلي فاضبط localBusiness:false في site.config.js) في كتل `<script type="application/ld+json">` منفصلة واربطها بالرسم الأساسي عبر @id. لا تدفن BreadcrumbList داخل @graph؛ أعطه كتلته الخاصة، لأن هذه هي الطريقة الوحيدة التي يراه بها seo-check.
2. العناوين من 48 إلى 60 حرفًا (يعدّ seo-check أي عنوان فوق 65 خطأ)، والأوصاف من 145 إلى 158 حرفًا، وh1 واحد في كل صفحة. كل صفحة تحتاج إلى 150 كلمة على الأقل من المحتوى الرئيسي؛ وصفحتا اتصل بنا والخصوصية غالبًا ما تقصران عن ذلك.
3. الفقرة الأولى في كل صفحة تجيب مباشرة عن سؤال الصفحة. اكتب أسئلة شائعة خاصة بالصفحة باستخدام `<details>` ووسمها بـ FAQPage. أظهر الجهة الناشرة وتاريخ "آخر تحديث" باستخدام `<time>`.
4. في robots.txt، اكتب قرارك مع سببه لكل من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot وCCBot، وأشر إلى خريطة الموقع. يحمل sitemap.xml تواريخ lastmod حقيقية. ويحتوي llms.txt على ملخص دقيق للموقع من جملتين وقائمة بالصفحات الرئيسية.
5. لا تخترع شيئًا: لا مراجعات ولا تقييمات ولا جوائز ولا أعداد عملاء ولا شهادات ولا ساعات عمل ولا إحداثيات ولا أسعار ما لم أعطك إياها. اترك الحقول غير المعروفة خارج schema.

بوابات القبول (بالترتيب؛ لا تعلن الانتهاء حتى تُجتاز جميعها):
1. باستخدام site_run_command نفّذ `node chrome-stamp.mjs` وبناء Tailwind و`node seo-stamp.mjs` و`node seo-check.mjs` (0 أخطاء، 0 تحذيرات) و`node design-check.mjs` (0 أخطاء؛ برّر أي تحذير متبقٍ) و`npx html-validate "**/*.html"` (0 أخطاء).
2. اعرض كل صفحة بـ site_preview مع view="mobile" وview="desktop". يلتقط site_preview الصفحة مع إيقاف الحركة (reduced-motion)، فإذا غاب محتوى في تلك الصورة فحالة عدم الحركة معطّلة. في اللقطات الكاملة للصفحة قد تظهر الصور lazy البعيدة فارغة؛ وهذا ليس خطأ، لكن تحقق من مساراتها.
3. نفّذ core_web_vitals لكل صفحة مع strategy="mobile" وstrategy="desktop". شرط النجاح: على الجوال أداء 95 على الأقل وإمكانية الوصول وأفضل الممارسات وSEO جميعها 100؛ وعلى سطح المكتب كل الأربعة 95 على الأقل. في الصفحة التي تفشل، استخدم resources=true لإيجاد الملف الذي يعطّلها، وأصلحه ثم قِس مجددًا. بعد ذلك نفّذ seo_audit على الصفحة الرئيسية مع strategy="mobile" وruns=2. يجب ألا تحتوي قائمة طلبات الشبكة على أي مضيف غير نطاقك.
4. لا تمرير أفقي عند عرض 360 و390 و768 و1440 بكسل، وأهداف اللمس 44 بكسل على الأقل، ولا أخطاء في وحدة التحكم.

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

بعد النشر: اعرض معاينة للقاعدة `/assets/* Cache-Control: public, max-age=31536000, immutable` باستخدام site_headers وطبّقها بعد موافقتي؛ ومن ذلك الحين غيّر أسماء ملفات CSS أو JS عند تغيّرها (site-v2.css وهكذا). أرسل sitemap.xml باستخدام gsc_submit_sitemap وافحص الصفحة الرئيسية بـ gsc_url_inspect. اختم بجدول درجات لكل صفحة (الصفحة، أربع درجات للجوال، أربع درجات لسطح المكتب، LCP، CLS)، ونتائج بوابات القبول، وقائمة الإصلاحات التي طبّقتها.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقعًا حديثًا بدون JavaScript: رسوم CSS متحركة مرتبطة بالتمرير وView Transitions وcontainer queries

ينشئ موقعًا متعدد الصفحات على خادم استضافتك لا يحمّل أي سكربتات، بحركة عبر animation-timeline وانتقالات بين الصفحات عبر View Transitions وبطاقات متجاوبة عبر container queries. كل ميزة محمية بـ @supports وبتفضيل تقليل الحركة، لذا تحصل المتصفحات غير الداعمة على الصفحة كاملة أيضًا.

متى تستخدمهعندما تريد أن يبدو موقعك حديثًا وسلسًا لكن يُفتح في أخف صورة ممكنة، دون تحميل أي JavaScript.

على خادم استضافة Opus Growth الخاص بي [اسم الخادم]، أنشئ موقعًا متعدد الصفحات لـ [اسم النشاط] لا يحمّل أي JavaScript إطلاقًا، وينفّذ حركته وانتقالات صفحاته بميزات CSS المدمجة في المتصفح. النشاط: [ما يفعله ولمن]، المدينة: [المدينة، الحي]. الخدمات أو المنتجات: [القائمة]. الأعمال: [لكل عمل: الاسم، الخامة أو النطاق، المدة، المشكلة التي تم حلها، رابط الصورة]. التواصل: [البريد الإلكتروني]، [الهاتف]، [رقم WhatsApp]، [العنوان]. النطاق: [النطاق].

الصفحات: الرئيسية (hero، أحدث الأعمال، طريقة العمل، الأسئلة الشائعة)، الأعمال (/isler/)، من نحن (/hakkimizda/)، اتصل بنا (/iletisim/، بدون نموذج)، الخصوصية (/gizlilik/) و404.html.

الأسلوب: تحريري وطبيعي. خط عناوين serif (مثل Zodiak) مع خط نص هادئ (مثل Switzer)، خلفية بلون الكتان، لون مميز واحد داكن، مساحات واسعة. احتفظ بالجرأة لبطاقات الأعمال.

قواعد CSS الحديثة (تحسين تدريجي؛ في متصفح لا يدعمها يجب أن تبقى الصفحة ثابتة لكن كاملة):
1. لا تحمّل أي ملف JavaScript إطلاقًا؛ لا GSAP ولا Lenis ولا Swiper. تعمل قائمة الجوال بوسم `<details>`.
2. انتقالات الصفحات (View Transitions بين صفحات الأصل نفسه): اكتب `@media (prefers-reduced-motion: no-preference) { @view-transition { navigation: auto; } }` وأبقِ المدة حوالي 0.35 ثانية. امنح الشريط العلوي view-transition-name: site-header. امنح صورة بطاقة عمل في الصفحة الرئيسية والصورة نفسها في صفحة الأعمال view-transition-name فريدًا واحدًا، حتى تكبر الصورة إلى مكانها في الصفحة الجديدة. استخدم كل اسم مرة واحدة فقط في الصفحة.
3. الحركات المرتبطة بالتمرير: خط تقدم في الأعلى ينمو بـ scaleX عبر `animation-timeline: scroll(root)` (يكون display:none افتراضيًا ويظهر فقط عند توفر الدعم)؛ على البطاقات وعناوين الأقسام `animation-timeline: view()` مع `animation-range: entry 0% entry 70%` باستخدام translateY فقط؛ وعلى صورة hero تكبير وإزاحة خفيفان أثناء وجودها في مجال الرؤية. لا تستخدم opacity: العناصر الباهتة الموجودة أسفل الشاشة تفشل في فحص التباين في Lighthouse. ضع كل هذه القواعد داخل `@supports (animation-timeline: scroll())` و`prefers-reduced-motion: no-preference`.
4. Container queries: اجعل بطاقة العمل مكوّنًا بـ `container-type: inline-size`. مع `@container (min-width: 34rem)` تكون الصورة في الأعلى في الحاوية الضيقة وبجانب النص في الحاوية العريضة. البطاقة نفسها ضيقة في شبكة من ثلاثة أعمدة في الصفحة الرئيسية وعريضة في عمود واحد في صفحة الأعمال. لا تحتوي نواة Tailwind 3 على فئات container query؛ اكتب هذه القواعد كـ CSS عادي في app.css.
5. يجب أن يناسب مستوى عنوان البطاقة الصفحة التي توجد فيها: في صفحة الأعمال ضع h2 بين h1 وعناوين h3 الخاصة بالبطاقات. عندما غاب هذا في العرض التجريبي انخفض Accessibility إلى 98 بسبب heading-order.
6. في صفحة الأعمال، أول صورة بطاقة تدخل الشاشة الأولى لا تكون lazy وتحصل على fetchpriority="high".

الإعداد والمشكلات المعروفة (كل واحدة منها خفّضت درجة في قياسات العرض التجريبي، لا تتخطَّ أيًا منها):
1. إذا كان هناك موقع يعمل بالفعل على الخادم، أخبرني أولًا، لأن الإعداد يستبدل index.html ومجلد assets. اعرض معاينة scaffold_site مع confirm=false واستدعِها مع confirm=true بعد موافقتي. ثم اقرأ site_design_guide وsite_seo_guide. قبل كتابة الكود، ضع اتجاه التصميم (الخطوط، اللون، الشبكة، العنصر المميز، لغة الحركة، والمكتبات التي لن تُحمَّل) في ملف ART.md قصير خارج assets وأرِني إياه.
2. اجعل Tailwind مُجمّعًا بدل تحميله من CDN. ثبّته عبر site_run_command مع background=true: `npm i -D tailwindcss@3`، ثم تابعه بـ site_command_status. يجب أن تغطي مسارات content في `tailwind.config.js` كل ملفات HTML والقوالب وأي ملف JS يكتب أسماء الفئات. يحتوي `_src/tw.css` على السطر `@import "../assets/app.css";` وأسطر `@tailwind` الثلاثة؛ جمّعه في ملف واحد بالأمر `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. أزل سكربت cdn.tailwindcss.com وtailwind.config المضمَّن من كل الصفحات واربط `/assets/site.css` فقط. أعد التجميع بعد كل تغيير في HTML.
3. استضف الخطوط بنفسك. اقرأ CSS لعائلات Fontshare التي اخترتها، ونزّل ملف woff2 لكل وزن إلى `assets/fonts/` عبر site_fetch، واكتب قواعد @font-face مع `font-display: swap` في `assets/app.css`؛ فـ design-check يبحث هناك عن خط مخصص. تحقق من اسم font-family في CSS الذي نزّلته، لأن Fontshare قد تعيد عائلة مختلفة عندما لا يتوفر وزن ما. نفّذ preload لخط عنوان الشاشة الأولى وخط النص في كل صفحة عبر `<link rel="preload" as="font" type="font/woff2" crossorigin>`؛ في العرض التجريبي أزال هذا إزاحة التخطيط الناتجة عن تبديل الخط (CLS من 0.024 إلى 0). معظم خطوط Fontshare لا تحتوي على رمز ₺، لذا اكتب "TL" للأسعار.
4. اجعل القائمة والتذييل HTML ثابتًا. لا تحمّل chrome.js ولا site.config.js في الصفحات. اكتب `chrome-stamp.mjs` صغيرًا يقرأ قائمة التنقل في site.config.js ويختم `_src/header.tpl` و`_src/footer.tpl` بين علامتي `` و`` في كل صفحة، مضيفًا aria-current="page" للرابط الحالي. لا تمنح القوالب امتداد .html واستخدم عناصر نائبة مثل `[[NAV]]` بدل `{{...}}`، وإلا فسيقرؤها design-check وseo-check كصفحات غير مكتملة. ابنِ قائمة الجوال بدون JS باستخدام `<details>`. أبقِ اسم النشاط والعنوان والهاتف في التذييل كنص عادي.
5. حوّل الصور أثناء تنزيلها عبر site_fetch: اكتب الصورة نفسها في ملفات منفصلة مع resize="480x" و"800x" و"1200x"، وimage_format="webp"، وquality=65. امنح كل `<img>` srcset وsizes وwidth وheight. تحصل صورة الشاشة الأولى الرئيسية على fetchpriority="high" ولا تكون lazy أبدًا؛ وبقية الصور تحصل على loading="lazy" decoding="async". إذا كانت الصورة الرئيسية تملأ شاشة الهاتف، فقدّم قصّة أعرض وأصغر على الجوال عبر `<picture>` (في العرض التجريبي انخفض حجم hero على الجوال من 89 KB إلى 43 KB).
6. أنشئ favicon بصيغة PNG بحجم 48 px من الشعار عبر site_fetch وأضف `<link rel="icon">` إلى كل الصفحات. بدونه يسجّل المتصفح خطأ 404 وينخفض Best Practices إلى 96.
7. قواعد مدقق HTML: ابدأ كل مستند بـ `<!DOCTYPE html>` بأحرف كبيرة (ملفات البداية في الحزمة تستخدم أحرفًا صغيرة)، واستخدم `&nbsp;` للمسافات في النص المرئي لروابط tel:، ولا تستخدم سمة style="" أبدًا، وامنح كل زر type="button".

SEO وAEO وGEO:
1. استخدم عناوين URL بنمط المجلدات مع شرطة مائلة في النهاية (/isler/ و/hakkimizda/ و/iletisim/ و/gizlilik/). املأ كتلة seo في site.config.js ونفّذ `node seo-stamp.mjs`. اكتب schema خاصًا بكل صفحة (الرئيسية: WebPage وFAQPage؛ الأعمال: CollectionPage مع CreativeWork واحد لكل عمل ضمن hasPart (مع material إن كانت معروفة)؛ من نحن: AboutPage؛ اتصل بنا: ContactPage؛ BreadcrumbList في الصفحات الداخلية. أدق نوع فرعي من LocalBusiness في site.config.js) في كتل `<script type="application/ld+json">` منفصلة واربطه بالرسم البياني الأساسي عبر @id. لا تدفن BreadcrumbList داخل @graph؛ امنحه كتلة خاصة به، لأن هذه هي الطريقة الوحيدة التي يراه بها seo-check.
2. عناوين من 48 إلى 60 حرفًا (يعدّ seo-check كل ما يتجاوز 65 خطأ)، وأوصاف من 145 إلى 158 حرفًا، وh1 واحد لكل صفحة. تحتاج كل صفحة إلى 150 كلمة على الأقل من المحتوى الرئيسي؛ وصفحتا الاتصال والخصوصية تميلان إلى النقص.
3. تجيب الفقرة الأولى في كل صفحة مباشرة عن سؤال الصفحة. اكتب قسم أسئلة شائعة خاصًا بالصفحة باستخدام `<details>` ووسّمه كـ FAQPage. أظهر الجهة الناشرة وتاريخ "آخر تحديث" باستخدام `<time>`.
4. في robots.txt، اكتب قرارك مع سببه لكل من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot وCCBot، وأشِر إلى خريطة الموقع. يحمل sitemap.xml تواريخ lastmod حقيقية. يحتوي llms.txt على ملخص دقيق من جملتين للموقع وقائمة بالصفحات الأساسية.
5. لا تخترع شيئًا: لا مراجعات ولا تقييمات ولا جوائز ولا أعداد عملاء ولا شهادات ولا ساعات عمل ولا إحداثيات ولا أسعار إلا إذا زوّدتك بها. اترك الحقول غير المعروفة خارج schema.

بوابات الجودة (بالترتيب؛ لا تعلن الانتهاء حتى تنجح جميعها):
1. عبر site_run_command نفّذ `node chrome-stamp.mjs`، ثم تجميع Tailwind، ثم `node seo-stamp.mjs`، ثم `node seo-check.mjs` (0 أخطاء، 0 تحذيرات)، ثم `node design-check.mjs` (0 أخطاء؛ برّر أي تحذير متبقٍ)، ثم `npx html-validate "**/*.html"` (0 أخطاء).
2. اعرض كل صفحة عبر site_preview مع view="mobile" وview="desktop". يلتقط site_preview الصفحة مع إيقاف الحركة (reduced-motion)، لذا إذا غاب محتوى في تلك الصورة فحالة عدم الحركة معطلة. في اللقطات الكاملة للصفحة قد تظهر الصور lazy الأبعد في الأسفل فارغة؛ هذا ليس خطأ، لكن تحقق من مساراتها.
3. نفّذ core_web_vitals لكل صفحة مع strategy="mobile" وstrategy="desktop". شرط النجاح: على الجوال Performance لا يقل عن 95 وAccessibility وBest Practices وSEO تساوي 100؛ وعلى سطح المكتب الدرجات الأربع كلها لا تقل عن 95. في الصفحة التي تفشل، استخدم resources=true لإيجاد الملف الذي يعيقها، وأصلحه ثم قِس مجددًا. بعد ذلك نفّذ seo_audit على الصفحة الرئيسية مع strategy="mobile" وruns=2. يجب ألا تحتوي قائمة طلبات الشبكة على أي مضيف غير نطاقك الخاص.
4. لا تمرير أفقي عند عرض 360 و390 و768 و1440 px، وأهداف اللمس 44 px على الأقل، ولا أخطاء في وحدة التحكم.

فحص الدعم: يلتقط site_preview مع إيقاف الحركة، لذلك لا يستطيع إظهار الانتقالات. أخبرني كيف أتحقق في Chrome من أن الصورة تكبر إلى مكانها عند النقر على عمل في الصفحة الرئيسية، وأن الخط العلوي يمتلئ أثناء التمرير، وأن البطاقة تغيّر تخطيطها عند تضييق النافذة وتوسيعها، وأن الصفحة تُفتح كاملة في متصفح لا يدعم هذه الميزات.

بعد النشر: اعرض معاينة القاعدة `/assets/* Cache-Control: public, max-age=31536000, immutable` عبر site_headers وطبّقها بعد موافقتي؛ ومن ثم غيّر أسماء ملفات CSS أو JS عند تغييرها (site-v2.css وهكذا). أرسل sitemap.xml عبر gsc_submit_sitemap وافحص الصفحة الرئيسية عبر gsc_url_inspect. اختم بجدول درجات لكل صفحة (الصفحة، أربع درجات للجوال، أربع درجات لسطح المكتب، LCP، CLS)، ونتائج البوابات، وقائمة الإصلاحات التي طبّقتها.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقع معرض أعمال لوكالتك مع معاينات تتبع المؤشر ومعرض صور بأسلوب Webflow، من دون Webflow

ينشئ موقع وكالة حديثًا بأسلوب بروتاليست على خادم الاستضافة الخاص بك، مع معاينات للمشاريع تتبع المؤشر، وعناوين أقسام تنكشف عند التمرير، ومعرض صور Swiper. التفاعلات مكتوبة بـ 3 KB من JS الخالص مع ما يعادلها للمس ولوحة المفاتيح، ويُحمَّل المعرض عند أول تفاعل، ويتم قياس أداء كل صفحة.

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

على خادم الاستضافة الخاص بي في Opus Growth [اسم الخادم]، أنشئ موقع معرض أعمال ثابتًا وسريعًا لـ [اسم الاستوديو] يعطي إحساس مواقع الوكالات التفاعلية المبنية في Webflow، دون استخدام Webflow. الاستوديو: [ما يقدمه ولمن]، المدينة والحي: [المدينة، الحي]. الخدمات: [3 خدمات]. المشاريع: [لكل مشروع: الاسم، نوع العمل، السنة، جملة عن المشكلة، جملة عن الحل، رابط الصورة]. التواصل: [البريد الإلكتروني]، [الهاتف]، [رقم WhatsApp]، [العنوان]. النطاق: [النطاق].

الصفحات: الرئيسية (hero، فهرس الأعمال المختارة، ما نقدمه، آلية العمل، الأسئلة الشائعة، دعوة ختامية لاتخاذ إجراء)، الأعمال (/isler/: معرض صور مع المشكلة والعمل المنجز وملاحظة التسليم لكل مشروع)، الاستوديو (/hakkimizda/)، التواصل (/iletisim/، بدون نموذج؛ بريد إلكتروني وWhatsApp برسالة معبأة مسبقًا وهاتف)، الخصوصية (/gizlilik/) و404.html. بدون بيانات معتمدة من العميل، لا تكتب نسبًا مئوية ولا أرقام نمو لنتائج المشاريع؛ صف النتيجة بالكلمات.

الأسلوب: بروتاليست حديث. زوايا حادة، وخطوط شبكة مرئية بسمك 1 px، وخط عناوين grotesk عريض بأحرف كبيرة (مثل Clash Grotesk) وخط نص هادئ (مثل Supreme)، ولون تمييز واحد فسفوري يُستخدم كخلفية فقط مع نص أسود عليه. حالات hover تغيّر اللون والخلفية؛ وحلقة التركيز سميكة وواضحة على أي خلفية.

قواعد التفاعل (إحساس Webflow IX2 بدون مكتبة):
1. لا تحمّل GSAP ولا Lenis. اكتب التفاعلات في ملف JS خالص صغير واحد (IntersectionObserver وrequestAnimationFrame) وحمّله بـ defer في الصفحتين الرئيسية والأعمال فقط. لا سكربت في الصفحات الأخرى.
2. العنصر المميز، فهرس "الأعمال المختارة": كل صف هو رابط حقيقي إلى المشروع ويحمل مسار صورة المعاينة في خاصية data-img. افتراضيًا (بدون JS أو على جهاز لمس) يعرض كل صف صورة صغيرة ضمن التدفق. فقط على الأجهزة التي تطابق `(hover: hover) and (pointer: fine)` ولا تطلب تقليل الحركة، يضيف JS الفئة cursor-fx إلى `<html>`، ويخفي الصور المضمنة، ويعرض صندوق معاينة واحدًا يتبع المؤشر. حرّك الصندوق بمتغيرات CSS وtransform: translate3d بدلًا من left وtop، وأوقف حلقة requestAnimationFrame عندما يسكن المؤشر. عند التركيز بلوحة المفاتيح تُفتح المعاينة نفسها ثابتة بجانب الصف وتُغلق عندما يغادر التركيز.
3. أضف حلقة المؤشر المخصصة فقط تحت الشرط نفسه؛ لا تُخفِ المؤشر الأصلي أبدًا، وضع على الحلقة aria-hidden ودعها تكبر فوق الروابط.
4. انتقالات الأقسام: تنكشف عناوين الأقسام من اليسار إلى اليمين باستخدام clip-path عند التمرير. يمنح JS الحالة الابتدائية المخفية فقط للعناوين الواقعة أسفل الشاشة عند فتح الصفحة؛ ولا يُخفى أبدًا محتوى الشاشة الأولى. سمِّ الخاصية data-reveal؛ فـ design-check يتعرف على الحركة بهذا الاسم وإلا يحذر "no motion".
5. معرض Swiper في صفحة الأعمال فقط. بدون JS يكون HTML المعرض شريط CSS scroll-snap أفقيًا، وتبقى أزرار السابق والتالي مخفية حتى يبدأ Swiper. نزّل حزمة Swiper 14 (js وcss) إلى `assets/vendor/` باستخدام site_fetch. حمّلها عندما يدخل المؤشر المعرض، أو عند اللمس، أو عند التركيز، أو عند أول تمرير للصفحة. في العرض التجريبي، أدى تحميلها عندما اقترب المعرض من منطقة العرض إلى رفع LCP على الجوال إلى 3 ثوانٍ بسبب حزمة بحجم 150 KB (الأداء 94)؛ أما التحميل عند أول تفاعل فأعطى 99. فعّل وحدات Navigation وKeyboard وA11y برسائل بالتركية، واضبط سرعة الانتقال على 0 عند تقليل الحركة.
6. ابنِ الشرائح باستخدام div بدلًا من ul وli. يمنح Swiper الشرائح role="group"؛ وعلى li تسبب هذا الدور في أخطاء aria-allowed-role وأخطاء قوائم وخفّض إمكانية الوصول إلى 96.

الإعداد والمصائد المعروفة (كل واحدة منها خفّضت درجة في قياسات العرض التجريبي، فلا تتجاوز أيًّا منها):
1. إذا كان هناك موقع يعمل بالفعل على الخادم، أخبرني أولًا، لأن الإعداد يستبدل index.html ومجلد assets. اعرض معاينة scaffold_site مع confirm=false واستدعه مع confirm=true بعد موافقتي. ثم اقرأ site_design_guide وsite_seo_guide. قبل كتابة الكود، ضع اتجاه التصميم (الطباعة، اللون، الشبكة، العنصر المميز، لغة الحركة، والمكتبات التي لن تُحمَّل) في ملف ART.md قصير خارج assets واعرضه عليّ.
2. اجعل Tailwind يُترجم بدلًا من تحميله من CDN. ثبّته باستخدام site_run_command مع background=true: `npm i -D tailwindcss@3`، ثم تابعه بـ site_command_status. يجب أن تغطي مسارات content في `tailwind.config.js` كل ملفات HTML والقوالب وأي ملف JS يكتب أسماء الفئات. يحتوي `_src/tw.css` على السطر `@import "../assets/app.css";` وأسطر `@tailwind` الثلاثة؛ ترجمه إلى ملف واحد بالأمر `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. احذف سكربت cdn.tailwindcss.com وtailwind.config المضمّن من كل الصفحات واربط `/assets/site.css` فقط. أعد الترجمة بعد كل تعديل على HTML.
3. استضف الخطوط بنفسك. اقرأ CSS لعائلات Fontshare التي اخترتها، ونزّل ملف woff2 لكل وزن إلى `assets/fonts/` باستخدام site_fetch، واكتب قواعد @font-face مع `font-display: swap` في `assets/app.css`؛ فـ design-check يبحث عن خط مخصص هناك. تحقق من اسم font-family في CSS الذي نزّلته، لأن Fontshare قد يُرجع عائلة مختلفة عندما لا يوجد الوزن. نفّذ preload لخط عنوان الشاشة الأولى ولخط النص في كل صفحة باستخدام `<link rel="preload" as="font" type="font/woff2" crossorigin>`؛ في العرض التجريبي أزال هذا انزياح التخطيط الناتج عن تبديل الخط (CLS من 0.024 إلى 0). معظم خطوط Fontshare لا تحتوي على رمز ₺، لذا اكتب "TL" للأسعار.
4. اجعل القائمة والتذييل HTML ثابتًا. لا تحمّل chrome.js ولا site.config.js في الصفحات. اكتب `chrome-stamp.mjs` صغيرًا يقرأ قائمة التنقل في site.config.js ويطبع `_src/header.tpl` و`_src/footer.tpl` بين علامتي `` و`` في كل صفحة، مضيفًا aria-current="page" إلى الرابط الحالي. لا تمنح القوالب امتداد .html واستخدم عناصر نائبة مثل `[[NAV]]` بدلًا من `{{...}}`، وإلا يقرؤها design-check وseo-check كصفحات غير مكتملة. ابنِ قائمة الجوال بدون JS باستخدام `<details>`. أبقِ اسم النشاط والعنوان والهاتف في التذييل كنص عادي.
5. حوّل الصور أثناء تنزيلها باستخدام site_fetch: اكتب الصورة نفسها في ملفات منفصلة مع resize="480x" و"800x" و"1200x"، وimage_format="webp"، وquality=65. أعطِ كل `<img>` الخصائص srcset وsizes وwidth وheight. تحصل الصورة الرئيسية في الشاشة الأولى على fetchpriority="high" ولا تكون lazy أبدًا؛ وتحصل البقية على loading="lazy" decoding="async". إذا ملأت الصورة الرئيسية شاشة الهاتف، فقدّم اقتطاعًا أعرض وأصغر على الجوال باستخدام `<picture>` (في العرض التجريبي انخفض حجم hero على الجوال من 89 KB إلى 43 KB).
6. أنشئ favicon بصيغة PNG بحجم 48 px من الشعار باستخدام site_fetch وأضف `<link rel="icon">` إلى كل الصفحات. بدونه يسجل المتصفح خطأ 404 وتنخفض أفضل الممارسات إلى 96.
7. قواعد مدقق HTML: ابدأ كل مستند بـ `<!DOCTYPE html>` بأحرف كبيرة (ملفات البداية في الحزمة تستخدم الأحرف الصغيرة)، واستخدم `&nbsp;` للمسافات في النص المرئي لروابط tel:، ولا تستخدم خاصية style="" أبدًا، وأعطِ كل زر type="button".

SEO وAEO وGEO:
1. استخدم عناوين URL للمجلدات مع شرطة مائلة في النهاية (/isler/ و/hakkimizda/ و/iletisim/ و/gizlilik/). املأ كتلة seo في site.config.js ونفّذ `node seo-stamp.mjs`. اكتب schema الخاص بكل صفحة (الرئيسية WebPage وFAQPage؛ الأعمال CollectionPage مع CreativeWork واحد لكل مشروع ضمن hasPart؛ الاستوديو AboutPage؛ التواصل ContactPage؛ وBreadcrumbList في الصفحات الداخلية. لاستوديو له مكتب فعلي استخدم businessType ProfessionalService) في كتل `<script type="application/ld+json">` منفصلة واربطه بالرسم الأساسي عبر @id. لا تدفن BreadcrumbList داخل @graph؛ امنحه كتلته الخاصة، لأن هذه هي الطريقة الوحيدة التي يراه بها seo-check.
2. العناوين من 48 إلى 60 حرفًا (يعدّ seo-check أي عنوان فوق 65 خطأً)، والأوصاف من 145 إلى 158 حرفًا، وh1 واحد لكل صفحة. تحتاج كل صفحة إلى 150 كلمة على الأقل من المحتوى الرئيسي؛ وتميل صفحتا التواصل والخصوصية إلى أن تكونا أقل من ذلك.
3. تجيب الفقرة الأولى في كل صفحة مباشرة عن سؤال الصفحة. اكتب أسئلة شائعة خاصة بالصفحة باستخدام `<details>` ووسمها كـ FAQPage. أظهر الجهة الناشرة وتاريخ "آخر تحديث" باستخدام `<time>`.
4. في robots.txt، اكتب قرارك مع سببه لكل من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot وCCBot، وأشِر إلى خريطة الموقع. يحمل sitemap.xml تواريخ lastmod حقيقية. ويحتوي llms.txt على ملخص دقيق من جملتين للموقع وقائمة بالصفحات الرئيسية.
5. لا تخترع شيئًا: لا مراجعات ولا تقييمات ولا جوائز ولا أعداد عملاء ولا شهادات ولا ساعات عمل ولا إحداثيات ولا أسعار ما لم أقدمها لك. اترك الحقول غير المعروفة خارج schema.

بوابات التحقق (بالترتيب؛ لا تعلن الانتهاء حتى تنجح جميعها):
1. باستخدام site_run_command نفّذ `node chrome-stamp.mjs` ثم بناء Tailwind ثم `node seo-stamp.mjs` ثم `node seo-check.mjs` (0 أخطاء، 0 تحذيرات) ثم `node design-check.mjs` (0 أخطاء؛ برّر أي تحذير متبقٍ) ثم `npx html-validate "**/*.html"` (0 أخطاء).
2. اعرض كل صفحة باستخدام site_preview مع view="mobile" وview="desktop". يلتقط site_preview الصفحة مع إيقاف الحركة (reduced-motion)، لذا إذا غاب محتوى في تلك الصورة فحالة عدم الحركة معطوبة. في اللقطات الكاملة للصفحة قد تظهر الصور lazy البعيدة في الأسفل فارغة؛ وهذا ليس خطأً، لكن تحقق من مساراتها.
3. شغّل core_web_vitals لكل صفحة مع strategy="mobile" وstrategy="desktop". معيار النجاح: على الجوال أداء لا يقل عن 95 وإمكانية الوصول وأفضل الممارسات وSEO كلها 100؛ وعلى سطح المكتب جميع الأربعة لا تقل عن 95. في الصفحة التي تفشل، استخدم resources=true لإيجاد الملف الذي يعطلها، وأصلحه وأعد القياس. ثم شغّل seo_audit على الصفحة الرئيسية مع strategy="mobile" وruns=2. يجب ألا تحتوي قائمة طلبات الشبكة على أي مضيف غير نطاقك الخاص.
4. لا تمرير أفقي عند العرض 360 و390 و768 و1440 px، وأهداف اللمس لا تقل عن 44 px، ولا أخطاء في وحدة التحكم.

فحص التفاعل: لا يستطيع site_preview عرض hover أو تأثيرات المؤشر. أخبرني كيف أتحقق في متصفح سطح المكتب من أن المعاينة تتبع المؤشر فوق صفوف الفهرس، ومن أنها تُفتح بجانب الصف عند التنقل بمفتاح Tab، ومن أن الهاتف يعرض الصور المضمنة، ومن أن المعرض يتحرك بسحب الإصبع.

بعد النشر: اعرض معاينة للقاعدة `/assets/* Cache-Control: public, max-age=31536000, immutable` باستخدام site_headers وطبّقها بعد موافقتي؛ ومن بعدها غيّر أسماء ملفات CSS أو JS عندما تتغير (site-v2.css وهكذا). أرسل sitemap.xml باستخدام gsc_submit_sitemap وافحص الصفحة الرئيسية باستخدام gsc_url_inspect. اختم بجدول درجات لكل صفحة (الصفحة، أربع درجات للجوال، أربع درجات لسطح المكتب، LCP، CLS)، ونتائج البوابات، وقائمة الإصلاحات التي طبقتها.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقعًا فاخرًا ثنائي اللغة لفندق بوتيك أو مشروع عقاري، بصور كبيرة وتأثير بارالاكس هادئ وhreflang

ينشئ موقعًا دافئًا وفاخرًا بالتركية والإنجليزية لفندق بوتيك أو مشروع سكني على خادم الاستضافة الخاص بك. يعرض الصور الكبيرة بسرعة مع قصّ منفصل للجوال، ويضيف تأثير بارالاكس بدون JavaScript يحترم تفضيل تقليل الحركة، ويضبط schema الخاص بـ Hotel أو RealEstateListing وhreflang بشكل صحيح.

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

أنشئ موقعًا بالتركية والإنجليزية لـ[فندقي / مشروعي السكني] على خادم الاستضافة الخاص بي [اسم الخادم]. التفاصيل:
1. الاسم: [اسم النشاط أو المشروع]، الموقع: [الموقع]، النوع: [فندق بوتيك / مشروع سكني]
2. للفندق: أنواع الغرف (المساحة، السرير، عدد النزلاء، الإطلالة، المرافق)، أوقات تسجيل الوصول والمغادرة، الموسم وقواعد الإقامة: [تفاصيل الغرف]
3. للمشروع: أنواع الوحدات (الغرف، المساحة بالمتر المربع، الطابق، موعد التسليم) وبيانات مكتب المبيعات: [تفاصيل الوحدات]
4. الهاتف: [الهاتف]، WhatsApp: [WhatsApp]، البريد الإلكتروني: [البريد الإلكتروني]، العنوان: [العنوان]
5. النطاق: [النطاق]، الصور الحقيقية: [مكان الصور، أو "use stock"]
6. من سيراجع النص الإنجليزي: [الشخص، أو "لا أحد"]

أكّد الخادم أولًا باستخدام list_servers ونفّذ scaffold_site مع style="universal"، أولًا مع confirm=false ثم مع confirm=true بعد موافقتي. اقرأ site_design_guide و site_seo_guide. اكتب قرار تصميم فاخرًا ودافئًا في _kaynak/ART.md وأرِني إياه: خط عناوين serif أنيق من Fontshare (مثل Boska 300) مع خط نص بسيط (مثل Synonym)، ودرجات القهوة الداكنة والكتان، ولون نحاسي واحد للتمييز، وتسميات صغيرة بتباعد واسع بين الأحرف وتصوير بملء الشاشة. العنصر المميز هو الصورة الأولى بملء الشاشة في الصفحة الرئيسية مع حركة parallax هادئة. لا تضع ترويسة شفافة فوق الصورة؛ ففي الصفحات الفاتحة يختفي نص القائمة الفاتح (في النسخة التجريبية أدى ذلك إلى انخفاض إمكانية الوصول إلى 95 في صفحتي الغرف والتواصل). اجعل خلفية الشريط داكنة.

بنية اللغات:
1. تقع الصفحات التركية في الجذر ونظيراتها الإنجليزية تحت /en/. لكل صفحة تركية نظيرة إنجليزية وتشير كل منهما إلى الأخرى. احتفظ بأزواج الصفحات في قائمة واحدة داخل assets/site.config.js وابنِ منها القائمة والتذييل ومبدّل اللغة؛ ينتقل المبدّل دائمًا إلى نظيرة تلك الصفحة، وليس إلى الصفحة الرئيسية أبدًا.
2. يحمل <head> في كل صفحة hreflang="tr" و hreflang="en" و hreflang="x-default" تشير إلى الصفحة التركية، وكلها بعناوين URL مطلقة؛ اكتب الأزواج نفسها في sitemap.xml كعناصر xhtml:link.
3. تستخدم الصفحات الإنجليزية <html lang="en"> وعنوانًا ووصفًا ومسار تنقل (breadcrumb) بالإنجليزية، و WebPage inLanguage "en". يضع seo-stamp.mjs القيمة og:locale tr_TR على كل صفحة؛ وفي build.mjs، بعد الختم، غيّرها إلى en_GB في الصفحات الإنجليزية وأضف og:locale:alternate باللغتين.
4. اكتب الإنجليزية كما يكتبها كاتب أصلي، لا كترجمة، وأبقِ أسماء الأماكن بإملائها التركي.

الصفحات والمخطط (schema) (كل منها باللغتين):
1. الرئيسية: صورة أولى بملء الشاشة، وفقرة واحدة تشرح ما هو المكان، وحقائق مختصرة (عدد الغرف، تسجيل الوصول، المغادرة، الموسم)، وبطاقات الغرف ورابط إلى الدليل المحلي. المخطط: WebPage، وعلى عقدة النشاط النوع Hotel مع checkinTime و checkoutTime و numberOfRooms و amenityFeature والغرف ضمن containsPlace. للمشروع السكني استخدم Residence أو ApartmentComplex بدلًا من ذلك.
2. صفحة للغرف وصفحة لكل نوع غرفة: المساحة، السرير، عدد النزلاء، المرافق، لمن تناسب، ورابط إلى نوع الغرفة الآخر. المخطط: HotelRoom (bed, occupancy, floorSize, amenityFeature, containedInPlace #business). للمشروع السكني، RealEstateListing لكل نوع وحدة مع Apartment بداخله (numberOfRooms, floorSize). إذا لم أعطك أسعارًا فلا تكتب offers، وقل في النص "أرسل لنا تواريخك وسنخبرك بالسعر لها".
3. الدليل المحلي: معرفة محلية مع تاريخ آخر تحديث. المخطط: WebPage.
4. التواصل والحجز: الهاتف، نموذج WhatsApp، البريد الإلكتروني، العنوان، "احصل على الاتجاهات"، ملاحظات السفر وشروط الحجز. المخطط: ContactPage.
5. صفحة 404 (قصيرة، باللغتين).

لا تذكر تصنيف نجوم أو جوائز أو تقييمات نزلاء أو عبارة "الأفضل"؛ ولا تضف starRating أو aggregateRating.

لفتح الصور الكبيرة بسرعة: قدّم الصورة الأولى باستخدام <picture>؛ في الشاشات حتى 767 بكسل استخدم قصًّا طوليًا بعرض 600 و900 بكسل (يُقصّ عند عنوان المصدر ويُجلب باستخدام site_fetch)، وفي الشاشات الأعرض النسخة الأفقية بعرض 1200 و1600 و2000 بكسل. بدون القص الطولي تُكبَّر الصورة الأفقية لتملأ شاشة الهاتف فتبدو غير حادة أو تُنزّل ملفًا كبيرًا دون داعٍ.

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

أعمال SEO المشتركة: تحصل كل صفحة على title فريد من 48 إلى 60 حرفًا، و description من 145 إلى 158 حرفًا، وعنوان H1 واحد، و canonical ينتهي بشرطة مائلة. أضف لكل صفحة عقدة WebPage و BreadcrumbList خاصة بها، مرتبطتين بالمخطط الأساسي عبر @id. في robots.txt اكتب Allow: / لكل من Googlebot و Bingbot و OAI-SearchBot و ChatGPT-User و GPTBot و Claude-SearchBot و Claude-User و ClaudeBot و PerplexityBot و Perplexity-User و Google-Extended و Applebot-Extended و CCBot، واشرح القرار في تعليق ودوّن ما يجب تغييره إذا أردت حظر زواحف التدريب. يحمل sitemap.xml تواريخ lastmod حقيقية. يصف llms.txt النشاط بدقة في جملتين ويسرد NAP والصفحات المهمة مع روابطها.

الإعداد التقني (لا يُستخدم المسار الافتراضي للأداة في هذا الموقع، للأسباب التالية):
1. ترجم Tailwind مسبقًا وتخلَّ عن CDN. تحمّل الأداة Tailwind عبر Play CDN الذي يترجم داخل المتصفح ويطبع تحذيرًا في وحدة التحكم ويخفض أداء الهاتف. اكتب _kaynak/package.json باستخدام site_write_file، وثبّت باستخدام site_run_command("cd _kaynak && npm i -D tailwindcss@3 html-validate", background=true) وانتظر باستخدام site_command_status. في _kaynak/tailwind.config.js اضبط content على "./*.html" و "./**/*.html" و "!./_kaynak/**" و "./_kaynak/chrome.mjs". انقل قواعد @font-face وسطور @tailwind وحلقة التركيز ورابط التخطي وحارس overflow من app.css الخاص بالأداة إلى _kaynak/site.css. اجعل المخرجات في assets/app.css لأن design-check.mjs يبحث عن الخطوط في هذا الملف، وأضف ?v=<hash المحتوى> إلى الرابط في كل صفحة حتى لا تقدّم ذاكرة الحافة الملف القديم أبدًا.
2. استضف الخطوط بنفسك. اقرأ عنوان CSS لعائلات Fontshare التي اخترتها (api.fontshare.com/v2/css?f[]=...) باستخدام site_read_url، ونزّل ملفات woff2 الخاصة بها باستخدام site_fetch إلى assets/fonts/، وأعلنها باستخدام @font-face و font-display: swap. أضف preload لكل وزن مستخدم في الجزء المرئي أولًا باستخدام <link rel="preload" as="font" type="font/woff2" crossorigin>، بحد أقصى ثلاثة ملفات. إذا تخطيت هذا فإن تبديل الخط يزحزح التخطيط؛ في النسخة التجريبية كان CLS على سطح المكتب 0.078 لهذا السبب وانخفض إلى 0 مع preload.
3. اجعل القائمة والتذييل HTML ثابتًا. مكوّنا <site-nav> و <site-footer> في الأداة يعتمدان على JavaScript، ومعظم زواحف الذكاء الاصطناعي لا ترى القائمة ولا العنوان ولا رقم الهاتف. أزل سكربتي chrome.js و motion.js من كل صفحة. في _kaynak/chrome.mjs اكتب دالتين تبنيان HTML الترويسة والتذييل من assets/site.config.js؛ وابنِ قائمة الجوال بدون JavaScript باستخدام <details> و <summary>، وعلّم الصفحة الحالية بـ aria-current="page". اكتب build.mjs في جذر الموقع بحيث ينفّذ بالترتيب node seo-stamp.mjs، ثم يعيد ختم كل ما بين  و  (وكذلك التذييل) في كل صفحة، ثم يترجم Tailwind ويحدّث الـ hash في رابط CSS. بعد كل تغيير، نفّذ فقط site_run_command("node build.mjs").
4. Parallax بدون JavaScript. أعطِ الصورة الأولى data-parallax وحرّكها ببطء باستخدام حركة CSS مرتبطة بالتمرير (animation-timeline: scroll(root)) باستخدام transform فقط؛ وأعطِ الأقسام ظهورًا data-reveal يستخدم transform فقط أيضًا، وليس opacity أبدًا. ضع القواعد داخل @media (prefers-reduced-motion: no-preference) و @supports (animation-timeline: scroll())؛ ومع تقليل الحركة، أو في متصفح لا يدعمها، تبقى الصورة ثابتة. لا تحمّل GSAP ولا Lenis ولا Swiper.
5. قلّل حجم الصور. نزّل كل صورة باستخدام site_fetch إلى ملفات منفصلة مع resize="480x" و "800x" و "1200x" و "1600x" و image_format="webp" وجودة بين 60 و68. أعطِ كل <img> قيم srcset و sizes و width و height تطابق النسبة الحقيقية؛ وإذا قصصت الصورة فأضف صنف نسبة مثل aspect-[4/3] مع object-cover، وإلا يتزحزح التخطيط عند تحميل الصورة. تحصل صورة الشاشة الأولى على fetchpriority="high" وليست lazy؛ وتحصل كل الصور الأخرى على loading="lazy". نزّل صورة المشاركة بصيغة JPG بقياس 1200x630 باستخدام site_fetch.
6. تفاصيل صغيرة تكلّف نقاطًا: أضف أيقونة موقع SVG باستخدام <link rel="icon"> (وإلا يطلب المتصفح /favicon.ico ويظهر الـ 404 كخطأ في وحدة التحكم وتنخفض أفضل الممارسات). اكتب DOCTYPE بأحرف كبيرة، ولا تستخدم سمات style ولا تترك مسافات زائدة في نهاية الأسطر. استخدم &nbsp; بدل المسافات في النص المرئي لروابط الهاتف (قاعدة tel-non-breaking في html-validate). يجب ألا يقل ارتفاع وعرض الروابط في القائمة والتذييل ومسار التنقل والعناوين عن 44 بكسل. لا تضمّن iframe من Google Maps؛ يجب ألا يجري الموقع أي طلبات خارجية، لذا اعرض العنوان ورابط "احصل على الاتجاهات".
7. يجب ألا يغادر أي طلب الموقع: الخطوط والسكربتات والأنماط والصور كلها على خادمك الخاص. لا يوجد معالج نماذج، لذا فنموذج التواصل هو نموذج method="get" يشير إلى https://wa.me/[رقم WhatsApp] مع textarea معبأة مسبقًا باسم "text"؛ ولا حاجة إلى JavaScript.

البوابات (بهذا الترتيب؛ لا تعتبر العمل منتهيًا حتى تنجح كلها):
1. نفّذ node build.mjs باستخدام site_run_command ثم node seo-check.mjs: 0 أخطاء، 0 تحذيرات. تحذير المحتوى المكرر يعني أن صفحتين لا تختلفان بما يكفي؛ أعد كتابتهما.
2. node design-check.mjs: 0 أخطاء. إذا اخترت أسلوبًا بلا حركة، فأبلغ عن تحذير "no motion" كقرار مقصود مع ذكر السبب.
3. _kaynak/node_modules/.bin/html-validate على كل ملف HTML: 0 أخطاء. ضع سطر _kaynak/ في ملف .htmlvalidateignore في جذر الموقع حتى لا تُفحص الاعتماديات.
4. فحص اللغات: أظهر في جدول أن نظيرة hreflang لكل صفحة موجودة وتعيد 200 وتشير إلى الصفحة الأصلية؛ ويجب ألا يعطي seo-check أي تحذير hreflang.
5. شاهد كل صفحة باستخدام site_preview عند view="mobile" و view="desktop"، وكذلك عند عرض 360 و768. أصلح التمرير الأفقي والعناوين المتجاوزة والأزرار الضيقة والنص غير المقروء ثم انظر مرة أخرى.
6. قِس كل صفحة باستخدام core_web_vitals عند strategy="mobile" و strategy="desktop"، واحصل على درجات إمكانية الوصول وأفضل الممارسات و SEO باستخدام seo_audit. الهدف على الجوال 100 في إمكانية الوصول وأفضل الممارسات و SEO و95 على الأقل في الأداء؛ وعلى سطح المكتب 95 على الأقل في الأربعة. في صفحة لا تحقق الهدف، نفّذ core_web_vitals مع resources=true، وابحث عن عنصر LCP وأي صورة كبيرة أكثر من اللازم، وأصلحها وكرّر seo_audit مع runs=2، لأن تشغيلًا مخبريًا واحدًا قد يتذبذب.
7. يجب ألا تحتوي طلبات الشبكة على أي عنوان خارج نطاق الموقع نفسه.

بعد النشر: أرسل sitemap.xml باستخدام gsc_submit_sitemap وافحص الصفحة الرئيسية وأهم ثلاث صفحات باستخدام gsc_inspect_urls. لا توجد أداة تستطيع الضغط على "طلب الفهرسة"؛ اذكر ما يجب أن أطلبه يدويًا في Search Console.

اختم بهذا التقرير: قائمة الصفحات مع درجات الجوال وسطح المكتب لكل صفحة في جدول (الأداء، إمكانية الوصول، أفضل الممارسات، SEO، LCP، CLS)، ونتيجة كل بوابة، والإصلاحات التي أجريتها، والمعلومات التي ما زلت تحتاجها مني. إذا لم يتحقق أحد الأهداف فقل ذلك بوضوح بدلًا من اعتبار العمل منتهيًا.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقعًا لمطعم أو مقهى غنيًا بالصور وسريعًا، مع قائمة طعام بصيغة HTML ومسار للحجز والموقع

ينشئ موقعًا دافئًا بطابع طبيعي ومتعدد الصفحات لمطعم أو مقهى على خادم الاستضافة الخاص بك. ينشر قائمة الطعام بصيغة HTML مع schema من نوع Menu بدلًا من PDF، ويربط الحجز بالهاتف وWhatsApp، ويجتاز اختبار السرعة على الجوال رغم كثرة الصور.

متى تستخدمهقائمة طعامك موجودة في ملف PDF أو في صورة، ويجد الناس صعوبة في العثور على ساعات عملك وطريقة الحجز، أو يتحمّل موقعك الغني بالصور ببطء على الجوال.

أنشئ موقعًا جديدًا لمطعمي من الصفر على خادم الاستضافة الخاص بي [اسم الخادم]. التفاصيل:
1. الاسم: [اسم النشاط]، النوع: [مطعم / مقهى / مكان لتقديم الإفطار]، المطبخ: [نوع المطبخ]
2. قائمة الطعام مع الأقسام والأوصاف والأسعار: [القائمة والأسعار]
3. معلومات الأطباق النباتية والخالية من اللحوم ومنتجات الحيوان والخالية من الغلوتين ومسببات الحساسية: [المعلومات الغذائية]
4. ساعات العمل (بشكل منفصل للإفطار والعشاء إذا اختلفت): [ساعات العمل]
5. طريقة استقبال الحجوزات: [هاتف / WhatsApp / كلاهما]، الهاتف: [الهاتف]، WhatsApp: [WhatsApp]
6. العنوان وملاحظات الوصول: [العنوان]، [مواقف السيارات والمواصلات]
7. مصدر المكونات وقصتنا: [المنتجون والقصة]
8. النطاق: [النطاق]، الصور الحقيقية: [مكان الصور، أو "استخدم صورًا جاهزة"]

أكّد الخادم أولًا باستخدام list_servers ثم شغّل scaffold_site مع style="restaurant"، أولًا مع confirm=false ثم مع confirm=true بعد موافقتي. اقرأ site_design_guide وsite_seo_guide. اكتب قرار تصميم طبيعيًا وعضويًا في _kaynak/ART.md واعرضه عليّ: خط عناوين دافئ بحواف (serif) من Fontshare (مثل Gambarino) مع خط نصوص ناعم (مثل Supreme)، وخلفية بلون الرمل، ونصوص بألوان ترابية، ولونان دافئان هما الأخضر الزيتي والتيراكوتا، ونفس الزاوية المستديرة في كل البطاقات. العنصر المميز هو صندوق "لوحة اليوم" في صفحة القائمة. إذا لم يكن في الخط الذي اخترته رمز ₺، فاكتب الأسعار بالصيغة "TL".

الصفحات والـ schema:
1. الرئيسية: الشاشة الأولى تقول ما الذي تقدمه وأين، مع زرّي "احجز طاولة" و"شاهد القائمة" وصورة كبيرة واحدة. بعدها ثلاثة أطباق من القائمة، ومصدر المكونات، وملخص لساعات العمل والموقع، و4 أسئلة شائعة. الـ schema: WebPage وFAQPage، وأضف servesCuisine وacceptsReservations (رابط صفحة الحجز) وhasMenu إلى عقدة #business.
2. القائمة: بصيغة HTML وليس PDF. لكل قسم عنوان ورابط مرجعي، ولكل طبق اسمه ووصفه وسعره وعلامات النظام الغذائي، وأعلى الصفحة يعرض تاريخ آخر تحديث وملاحظة عن مسببات الحساسية. خذ الأسعار من القائمة التي أعطيتك إياها فقط؛ ولا تخترع أبدًا سعرًا ناقصًا. الـ schema: Menu مع MenuSection ضمن hasMenuSection وMenuItem ضمن hasMenuItem وOffer ضمن offers (price وpriceCurrency TRY) وsuitableForDiet حيثما ينطبق.
3. الحجز: كيف تتم الحجوزات، والهاتف وWhatsApp، ونموذج WhatsApp برسالة معبأة مسبقًا (التاريخ والوقت وعدد الأشخاص والحديقة أو الداخل)، و3 أسئلة شائعة (التأخر، المجموعات الكبيرة، الإلغاء). الـ schema: WebPage وFAQPage.
4. قصتنا والمنتجون: من يدير المكان، ومن أين تأتي المكونات، وجدول موسمي يوضح أي مكون يكون في القائمة في أي أشهر. الـ schema: AboutPage.
5. الموقع وساعات العمل: العنوان، وجدول ساعات العمل، ورابط "احصل على الاتجاهات"، وكيفية الوصول بالسيارة ومن وسط المدينة وبالمواصلات العامة، وملاحظة عن إمكانية الوصول. الـ schema: ContactPage.
6. صفحة 404.

للبقاء سريعًا رغم الصور: صورة كبيرة واحدة في الشاشة الأولى وكل الصور الأخرى بتحميل lazy؛ صيغة WebP بجودة 60 إلى 65 وبحد أقصى ثماني صور في الصفحة؛ لا تحمّل مكتبة سلايدر للمعرض.

بدون اختلاق: لا تكتب تقييمات أو درجات أو جوائز أو شهادات أو أعداد عملاء أو عبارات مثل "الأفضل" غير حقيقية. لا تضف إلى الـ schema أو النص ساعات عمل أو إحداثيات أو أسعارًا أو بريدًا إلكترونيًا لم أعطك إياها؛ اترك الحقل خارجًا وأدرجه كمعلومة ناقصة في التقرير. لا تستخدم الشرطات الطويلة ولا الشعارات الجاهزة، واجعل الفقرة الأولى في كل صفحة تجيب مباشرة عن سؤال تلك الصفحة.

عمل SEO المشترك: كل صفحة تحصل على title فريد من 48 إلى 60 حرفًا، وdescription من 145 إلى 158 حرفًا، وH1 واحد، وcanonical ينتهي بشرطة مائلة. أضف عقدة WebPage خاصة بكل صفحة وBreadcrumbList، مرتبطتين بالرسم الأساسي عبر @id. في robots.txt اكتب Allow: / لكل من Googlebot وBingbot وOAI-SearchBot وChatGPT-User وGPTBot وClaude-SearchBot وClaude-User وClaudeBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وCCBot، واشرح القرار في تعليق ووضّح ما يجب تغييره إذا أردت حظر زواحف التدريب. يحتوي sitemap.xml على تواريخ lastmod حقيقية. يصف llms.txt النشاط بدقة في جملتين ويسرد NAP والصفحات المهمة مع الروابط.

الإعداد التقني (المسار الافتراضي للحزمة غير مستخدم في هذا الموقع، للأسباب التالية):
1. جمّع Tailwind وتخلَّ عن CDN. تحمّل الحزمة Tailwind عبر Play CDN الذي يُجمَّع داخل المتصفح ويطبع تحذيرًا في وحدة التحكم ويخفض الأداء على الجوال. اكتب _kaynak/package.json باستخدام site_write_file، وثبّت باستخدام site_run_command("cd _kaynak && npm i -D tailwindcss@3 html-validate", background=true) وانتظر باستخدام site_command_status. في _kaynak/tailwind.config.js اجعل content هو "./*.html" و"./**/*.html" و"!./_kaynak/**" و"./_kaynak/chrome.mjs". انقل قواعد @font-face وأسطر @tailwind وحلقة التركيز ورابط التخطي وحارس overflow من app.css الخاص بالحزمة إلى _kaynak/site.css. اجعل المخرجات في assets/app.css لأن design-check.mjs يبحث عن الخطوط في هذا الملف، وأضف ?v=<hash المحتوى> إلى الرابط في كل صفحة حتى لا تقدّم ذاكرة الحافة (edge cache) الملف القديم أبدًا.
2. استضف الخطوط بنفسك. اقرأ رابط CSS لعائلات Fontshare التي اخترتها (api.fontshare.com/v2/css?f[]=...) باستخدام site_read_url، ونزّل ملفات woff2 الخاصة به باستخدام site_fetch إلى assets/fonts/، وعرّفها باستخدام @font-face مع font-display: swap. نفّذ preload لكل وزن مستخدم أعلى الطيّة باستخدام <link rel="preload" as="font" type="font/woff2" crossorigin>، بحد أقصى ثلاثة ملفات. إذا تخطيت هذا فإن تبديل الخط يزحزح التخطيط؛ في العرض التجريبي كان CLS على سطح المكتب 0.078 لهذا السبب وانخفض إلى 0 مع preload.
3. اجعل القائمة والتذييل HTML ثابتًا. مكوّنات <site-nav> و<site-footer> في الحزمة تعمل بـ JavaScript، ومعظم زواحف الذكاء الاصطناعي لا ترى القائمة ولا العنوان ولا رقم الهاتف أبدًا. أزل سكربتي chrome.js وmotion.js من كل الصفحات. في _kaynak/chrome.mjs اكتب دالتين تبنيان HTML الرأس والتذييل من assets/site.config.js؛ ابنِ قائمة الجوال بدون JavaScript باستخدام <details> و<summary>، وعلّم الصفحة الحالية بـ aria-current="page". اكتب build.mjs في جذر الموقع بحيث ينفّذ بالترتيب node seo-stamp.mjs، ثم يعيد ختم كل ما بين  و (ونفس الشيء للتذييل) في كل الصفحات، ثم يجمّع Tailwind ويحدّث الـ hash في رابط CSS. بعد كل تعديل، شغّل فقط site_run_command("node build.mjs").
4. الحركة عبر CSS فقط، وبلطف. ضع data-reveal على بطاقات الصور وابنِ تأثير الظهور بتحريك CSS مرتبط بالتمرير (animation-timeline: view()) باستخدام transform فقط؛ لا تحرّك opacity، لأن النص الذي يبدأ بشفافية صفر يختفي في المتصفحات بدون JavaScript ويفشل في فحص التباين في تدقيقات إمكانية الوصول. ضع القاعدة داخل @media (prefers-reduced-motion: no-preference) و@supports (animation-timeline: view()). لا تحمّل GSAP أو Lenis أو Swiper.
5. صغّر الصور. نزّل كل صورة باستخدام site_fetch في ملفات منفصلة باستخدام resize="480x" و"800x" و"1200x" و"1600x" وimage_format="webp" وجودة بين 60 و68. أعطِ كل <img> قيم srcset وsizes وwidth وheight تطابق النسبة الحقيقية؛ وإذا قصصت الصورة فأضف صنف نسبة مثل aspect-[4/3] مع object-cover، وإلا يتحرك التخطيط عند تحميل الصورة. صورة الشاشة الأولى تحصل على fetchpriority="high" وليست lazy؛ وكل الصور الأخرى تحصل على loading="lazy". نزّل صورة المشاركة بصيغة JPG بمقاس 1200x630 باستخدام site_fetch.
6. تفاصيل صغيرة تكلّف نقاطًا: أضف favicon بصيغة SVG باستخدام <link rel="icon"> (وإلا يطلب المتصفح /favicon.ico ويظهر الـ 404 كخطأ في وحدة التحكم وتنخفض درجة أفضل الممارسات). اكتب DOCTYPE بأحرف كبيرة، ولا تستخدم سمات style، ولا تترك مسافات زائدة في نهاية الأسطر. استخدم &nbsp; بدل المسافات في النص المرئي لروابط الهاتف (قاعدة tel-non-breaking في html-validate). يجب أن تكون الروابط في القائمة والتذييل ومسار التنقل والعناوين بارتفاع وعرض 44 بكسل على الأقل. لا تضمّن iframe من Google Maps؛ يجب ألا يجري الموقع أي طلبات خارجية، لذا اعرض العنوان ورابط "احصل على الاتجاهات".
7. يجب ألا يغادر أي طلب الموقع: الخطوط والسكربتات والأنماط والصور كلها على خادمك. لا يوجد معالج نماذج، لذا نموذج الاتصال هو نموذج method="get" يشير إلى https://wa.me/[رقم WhatsApp] مع textarea معبأ مسبقًا باسم "text"؛ ولا حاجة إلى JavaScript.

البوابات (بهذا الترتيب؛ لا تعتبر العمل منتهيًا حتى تنجح كلها):
1. شغّل node build.mjs باستخدام site_run_command ثم node seo-check.mjs: 0 أخطاء، 0 تحذيرات. تحذير المحتوى المكرر يعني أن صفحتين ليستا مختلفتين بما يكفي؛ أعد كتابتهما.
2. node design-check.mjs: 0 أخطاء. إذا اخترت أسلوبًا بلا حركة، فاذكر تحذير "لا توجد حركة" كقرار متعمد مع السبب.
3. _kaynak/node_modules/.bin/html-validate على كل ملفات HTML: 0 أخطاء. ضع سطر _kaynak/ في ملف .htmlvalidateignore في جذر الموقع حتى لا تُفحص الاعتمادات.
4. شاهد كل صفحة باستخدام site_preview على view="mobile" وview="desktop" وأيضًا بعرض 360 و768. أصلح التمرير الأفقي والعناوين التي تفيض والأزرار الضيقة والنصوص غير المقروءة ثم شاهد مجددًا.
5. قس كل صفحة باستخدام core_web_vitals على strategy="mobile" وstrategy="desktop"، واحصل على درجات إمكانية الوصول وأفضل الممارسات وSEO باستخدام seo_audit. الهدف على الجوال هو 100 في إمكانية الوصول وأفضل الممارسات وSEO و95 على الأقل في الأداء؛ وعلى سطح المكتب 95 على الأقل في الأربعة. في الصفحة التي لا تحقق الهدف، شغّل core_web_vitals مع resources=true، وابحث عن عنصر LCP وأي صورة كبيرة الحجم، وأصلح ثم كرر seo_audit مع runs=2، لأن تشغيلًا مخبريًا واحدًا قد يتذبذب.
6. يجب ألا تحتوي طلبات الشبكة على أي عنوان خارج نطاق الموقع نفسه.

اختم بهذا التقرير: قائمة الصفحات مع درجات الجوال وسطح المكتب لكل صفحة في جدول (الأداء، إمكانية الوصول، أفضل الممارسات، SEO، LCP، CLS)، ونتيجة كل بوابة، والإصلاحات التي أجريتها، والمعلومات التي ما زلت تحتاجها مني. إذا لم يتحقق أحد الأهداف، فاذكر ذلك بوضوح بدلًا من اعتبار العمل منتهيًا.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقع عيادة أسنان أو تجميل متوافقًا مع لائحة الإعلانات الصحية في تركيا، مع بيانات الطبيب والإشعار القانوني ومسار الحجز

ينشئ موقعًا سريعًا ومتعدد الصفحات لعيادة أسنان أو تجميل على خادم الاستضافة الخاص بك. يطبّق محظورات اللائحة بندًا بندًا، ويضيف الإشعار القانوني وبيانات الطبيب إلى كل صفحة، ويفحص النص وJSON-LD بسكربت فحص.

متى تستخدمهتبني موقعًا جديدًا لعيادتك، أو تريد مواءمة موقعك الحالي مع اللائحة التنظيمية، دون التضحية بالسرعة أو الظهور في نتائج البحث.

أنشئ موقعًا جديدًا لعيادتي من الصفر على خادم الاستضافة الخاص بي [اسم الخادم]. التفاصيل:
1. الاسم المرخّص: [الاسم المرخص]، النوع: [مجمع عيادات أسنان / عيادة خاصة / عيادة تجميل]
2. المدير المسؤول: [المدير المسؤول]، الطبيب المسؤول عن المحتوى: [الطبيب المسؤول عن المحتوى]، محرر الموقع: [محرر الموقع]
3. الأطباء مع ألقابهم ومؤهلاتهم ومجالات عملهم: [قائمة الأطباء]
4. العلاجات التي تُكتب لها صفحات معلومات، والطبيب الذي يُعدّ كل صفحة: [العلاجات]
5. الهاتف: [الهاتف]، WhatsApp: [WhatsApp]، العنوان: [العنوان]، ساعات العمل: [ساعات العمل]
6. النطاق: [النطاق]، تفضيل الألوان: [تفضيل اللون]، الصور الحقيقية: [مكان الصور، أو "لا يوجد"]

يجب أن يلتزم هذا الموقع التزامًا كاملًا بلائحة تركيا الخاصة بأنشطة الترويج والإعلام في الخدمات الصحية (الجريدة الرسمية 12.11.2025، رقم 33075). القواعد:
1. لا آراء مرضى ولا رسائل شكر ولا نجوم ولا تقييمات. ولا aggregateRating ولا review في JSON-LD أيضًا؛ فـ Google لا تقبل في الترميز تقييمًا يمنحه النشاط التجاري لنفسه.
2. لا رسوم ولا خصومات ولا حملات ولا تقسيط ولا طرق دفع ولا عبارات مثل "استشارة مجانية". ولا offers ولا price ولا priceRange في JSON-LD.
3. لا ترويج لمنتجات أو علامات تجارية: لا تذكر أسماء علامات الزرعات أو المقوّمات الشفافة أو الحشوات أو الأجهزة.
4. لا تفوّق ولا وعود بالنتائج: تجنّب "الأفضل" و"الرائد" و"مضمون" و"حل دائم" و"بلا ألم" و"مثالي" و"100 بالمئة". استخدم "يختلف من شخص لآخر ويتضح بعد الفحص".
5. لا أرقام لا يمكن التحقق منها: لا "15 عامًا من الخبرة" ولا "5,000 مريض" ولا "آلاف الزرعات".
6. ألقاب صحيحة: طبيب الأسنان بلا تخصص هو "Dt."، والمتخصص هو "Uzm. Dt."؛ ولا يُستخدم "Dr." إلا مع الدكتوراه. المجمّع الطبي يسمّي "mesul müdür" (المدير المسؤول)، وليس "كبير الأطباء".
7. لا صور مرضى، ولا صور جراحة أو مناطق حساسة. لا يجوز نشر صور قبل وبعد إلا بموافقة المريض الخطية، وبنفس الظروف والتقنية، مع تاريخ الإجراء وتاريخ التقاط الصورة؛ وإن لم تتوفر لدي هذه، فلا تستخدم صور قبل وبعد. وإذا استخدمتها فأضف هذه الجملة حرفيًا أسفلها: "Her cerrahi veya girişimsel işlemde sonuçlar kişiden kişiye değişiklik gösterebilir. İşlem öncesinde hekiminizden detaylı görüş almanız önerilir." وضعها في صفحات الإجراءات التداخلية أيضًا.
8. بيانات تعريفية في كل صفحة: الاسم المرخّص، والمدير المسؤول، والطبيب المسؤول عن المحتوى، ومحرر الموقع، وتاريخ آخر تحديث.
9. محتوى السياحة العلاجية لا مكان له في هذا الموقع؛ فهو يحتاج إلى ترخيص منفصل ومنصة منفصلة.

للتحقق من هذه القواعد تلقائيًا، اكتب uyum-check.mjs في جذر الموقع. يفحص النص المرئي والنص البديل للصور في كل صفحة، منفصلًا عن كتل JSON-LD: عبارات الآراء والتقييم؛ الأرقام مع TL و₺؛ كلمات السعر والرسوم والخصم والحملة والتقسيط والمجاني والأفضل والضمان وبلا ألم والحل الدائم؛ أسماء العلامات التجارية؛ أرقام مثل "15+ عامًا" أو "5000 مريض"؛ "Dr." و"كبير الأطباء"؛ "قبل وبعد"؛ السياحة العلاجية؛ وaggregateRating وreview وoffers وprice في JSON-LD. ويتحقق أيضًا من الحقول الخمسة للبيانات التعريفية في كل صفحة، ومن lastReviewed وreviewedBy في صفحات العلاج، ومن جملة التحذير في صفحات الإجراءات التداخلية. ضع data-uyum="aciklama" على الجمل التي تشرح اللائحة (مثل "لا يعرض هذا الموقع أي رسوم")؛ فالسكربت لا يحسبها أخطاءً لكنه يدرجها للمراجعة اليدوية. أنهِ التنفيذ برمز الخروج 1 عند أي مخالفة.

ثم أكّد الخادم باستخدام list_servers ونفّذ scaffold_site مع style="clinic"، أولًا مع confirm=false ثم مع confirm=true بعد موافقتي. اقرأ site_design_guide وsite_seo_guide. اكتب قرارًا تحريريًا للتصميم في _kaynak/ART.md واعرضه علي: خط عرض رفيع ذو زوائد (serif) من Fontshare (مثل Zodiak) مع خط نص هادئ (مثل Switzer)، وخلفية بلون الكريم، ونص بلون أخضر داكن يميل إلى الأسود، ولون تمييز واحد هو الأزرق المخضر العميق، ومساحات بيضاء واسعة. العنصر المميز هو بطاقة "الطبيب الذي أعدّ هذه الصفحة" بجانب كل صفحة علاج: اسم الطبيب مع لقبه ومجاله وتاريخ المراجعة الطبية. وإن لم تتوفر صورة للطبيب فلا تستخدم صورة جاهزة لشخص؛ استخدم شارة بسيطة بالأحرف الأولى. ولا يجوز أن يظهر أي مريض في صور المكان.

الصفحات والـ schema:
1. الرئيسية: ما هي العيادة، وكم طبيبًا يعمل في أي مجالات، ونهج "الفحص أولًا ثم نقرر معًا"، والعلاجات، والأطباء، وخطوات الحجز، و4 أسئلة شائعة. Schema: WebPage وFAQPage. في الرسم البياني الأساسي يكون نوع النشاط Dentist (وMedicalClinic للعيادة التجميلية).
2. صفحة للعلاجات وصفحة معلومات لكل علاج: تذكر الفقرة الأولى ما هو العلاج ولمن يُنظر فيه؛ ثم لمن يناسب أو لا يناسب، وخطوات التقييم، ومسار العلاج، والمخاطر والاحتياطات، والعناية اللاحقة، و3 أسئلة شائعة. Schema: MedicalWebPage (about عن MedicalProcedure، وreviewedBy وauthor هما عقدة Person الخاصة بالطبيب، وlastReviewed)، وFAQPage.
3. أطباؤنا: اسم كل طبيب مع لقبه وتخصصه ومؤهلاته ومجالات عمله. Schema: عقدة Person مع @id لكل طبيب (honorificPrefix وjobTitle وworksFor #business وknowsAbout). نوع Physician في schema.org يصف منظمة؛ فلا تستخدمه لشخص.
4. الحجز والتواصل: الهاتف، ونموذج WhatsApp، والعنوان، والساعات، وقائمة "ما الذي يجب إحضاره"، وطريقة الوصول. Schema: ContactPage.
5. صفحة للبيانات التعريفية والخصوصية ومبادئ النشر، وصفحة 404.

لا اختلاق: لا تكتب آراء ولا تقييمات ولا جوائز ولا شهادات ولا أعداد عملاء ولا ادعاءات مثل "الأفضل" ما لم تكن حقيقية. لا تضف إلى الـ schema أو النص ساعات عمل أو إحداثيات أو أسعارًا أو بريدًا إلكترونيًا لم أزودك بها؛ اترك الحقل واذكره على أنه ناقص في التقرير. لا تستخدم شرطات طويلة ولا شعارات جاهزة، واجعل الفقرة الأولى في كل صفحة تجيب مباشرة عن سؤال تلك الصفحة.

عمل SEO المشترك: كل صفحة تحصل على title فريد من 48 إلى 60 حرفًا، وdescription من 145 إلى 158 حرفًا، وH1 واحد، وcanonical ينتهي بشرطة مائلة. أضف لكل صفحة عقدة WebPage خاصة بها وBreadcrumbList، مرتبطتين بالرسم البياني الأساسي عبر @id. في robots.txt اكتب Allow: / لكل من Googlebot وBingbot وOAI-SearchBot وChatGPT-User وGPTBot وClaude-SearchBot وClaude-User وClaudeBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وCCBot، واشرح القرار في تعليق، ودوّن ما يجب تغييره إن أردت حظر زواحف التدريب. يحمل sitemap.xml تواريخ lastmod حقيقية. يصف llms.txt النشاط بدقة في جملتين ويدرج NAP والصفحات المهمة مع روابطها.

الإعداد التقني (لا يُستخدم المسار الافتراضي للحزمة في هذا الموقع، للأسباب التالية):
1. صرّف Tailwind وتخلَّ عن CDN. تحمّل الحزمة Tailwind عبر Play CDN الذي يصرّف داخل المتصفح ويطبع تحذيرًا في وحدة التحكم ويخفض الأداء على الجوال. اكتب _kaynak/package.json باستخدام site_write_file، وثبّت عبر site_run_command("cd _kaynak && npm i -D tailwindcss@3 html-validate", background=true) وانتظر باستخدام site_command_status. في _kaynak/tailwind.config.js اضبط content على "./*.html" و"./**/*.html" و"!./_kaynak/**" و"./_kaynak/chrome.mjs". انقل قواعد @font-face وأسطر @tailwind وحلقة التركيز ورابط التخطي وحارس التجاوز (overflow) من app.css الخاص بالحزمة إلى _kaynak/site.css. اجعل المخرجات في assets/app.css، لأن design-check.mjs يبحث عن الخطوط في ذلك الملف، وأضف ?v=<hash المحتوى> إلى الرابط في كل صفحة حتى لا تقدّم ذاكرة الحافة الملف القديم أبدًا.
2. استضف الخطوط ذاتيًا. اقرأ رابط CSS لعائلات Fontshare التي اخترتها (api.fontshare.com/v2/css?f[]=...) باستخدام site_read_url، ونزّل ملفات woff2 الخاصة بها باستخدام site_fetch إلى assets/fonts/، وعرّفها باستخدام @font-face وfont-display: swap. حمّل مسبقًا (preload) كل وزن يُستخدم في الجزء العلوي من الصفحة باستخدام <link rel="preload" as="font" type="font/woff2" crossorigin>، بحد أقصى ثلاثة ملفات. إن تخطيت ذلك فإن استبدال الخط يزحزح التخطيط؛ ففي العرض التجريبي كان CLS على سطح المكتب 0.078 لهذا السبب وانخفض إلى 0 مع التحميل المسبق.
3. اجعل القائمة والتذييل HTML ثابتًا. مكوّنا <site-nav> و<site-footer> في الحزمة يعملان بـ JavaScript، ومعظم زواحف الذكاء الاصطناعي لا ترى القائمة ولا العنوان ولا رقم الهاتف. أزل سكربتي chrome.js وmotion.js من كل صفحة. في _kaynak/chrome.mjs اكتب دالتين تبنيان HTML الترويسة والتذييل من assets/site.config.js؛ وابنِ قائمة الجوال بلا JavaScript باستخدام <details> و<summary>، وعلّم الصفحة الحالية بـ aria-current="page". اكتب في جذر الموقع build.mjs الذي ينفّذ بالترتيب node seo-stamp.mjs، ثم يعيد ختم كل ما بين  و (والأمر نفسه للتذييل) في كل صفحة، ثم يصرّف Tailwind ويحدّث الـ hash في رابط CSS. بعد كل تغيير، نفّذ فقط site_run_command("node build.mjs").
4. بلا حركة. لا تحمّل GSAP ولا Lenis ولا Swiper ولا أي سكربت حركة؛ فالمطلوب موقع معلومات هادئ وسهل القراءة.
5. صغّر الصور. نزّل كل صورة باستخدام site_fetch في ملفات منفصلة مع resize="480x" و"800x" و"1200x" و"1600x" وimage_format="webp" وجودة بين 60 و68. أعطِ كل <img> قيم srcset وsizes وwidth وheight مطابقة للنسبة الحقيقية؛ وإذا قصصت الصورة فأضف فئة نسبة مثل aspect-[4/3] مع object-cover، وإلا فسيتحرك التخطيط عند تحميل الصورة. صورة الشاشة الأولى تحصل على fetchpriority="high" وليست lazy؛ وكل الصور الأخرى تحصل على loading="lazy". نزّل صورة المشاركة بصيغة JPG بمقاس 1200x630 باستخدام site_fetch.
6. تفاصيل صغيرة تكلّف نقاطًا: أضف أيقونة favicon بصيغة SVG مع <link rel="icon"> (وإلا طلب المتصفح /favicon.ico، وظهر الخطأ 404 كخطأ في وحدة التحكم وانخفضت درجة أفضل الممارسات). اكتب DOCTYPE بأحرف كبيرة، ولا تستخدم سمات style، ولا تترك مسافات زائدة في نهاية الأسطر. استخدم &nbsp; بدل المسافات في النص المرئي لروابط الهاتف (قاعدة tel-non-breaking في html-validate). يجب ألا يقل ارتفاع وعرض الروابط في القائمة والتذييل ومسار التنقل والعناوين عن 44 بكسل. لا تضمّن iframe من Google Maps؛ فلا ينبغي للموقع إجراء أي طلبات خارجية، لذا اعرض العنوان ورابط "احصل على الاتجاهات".
7. يجب ألا يخرج أي طلب من الموقع: الخطوط والسكربتات والأنماط والصور كلها على خادمك. لا يوجد معالج نماذج، لذا فإن نموذج التواصل هو نموذج method="get" يشير إلى https://wa.me/[رقم WhatsApp] مع textarea معبّأ مسبقًا باسم "text"؛ ولا حاجة إلى JavaScript.

بوابات الفحص (بهذا الترتيب؛ لا تعلن الانتهاء حتى تنجح جميعها):
1. نفّذ node build.mjs باستخدام site_run_command ثم node seo-check.mjs: 0 أخطاء، 0 تحذيرات. يعني تحذير المحتوى المكرر أن صفحتين ليستا مختلفتين بما يكفي؛ أعد كتابتهما.
2. node design-check.mjs: 0 أخطاء. وإذا اخترت أسلوبًا بلا حركة، فبلّغ عن تحذير "بلا حركة" بوصفه قرارًا متعمدًا مع ذكر السبب.
3. _kaynak/node_modules/.bin/html-validate على كل ملفات HTML: 0 أخطاء. ضع سطر _kaynak/ في ملف .htmlvalidateignore في جذر الموقع حتى لا تُفحص الاعتماديات.
4. node uyum-check.mjs: 0 مخالفات. اقرأ كل جملة توضيحية في قائمة المراجعة اليدوية وتأكد أنها تشرح ولا تروّج.
5. اطّلع على كل الصفحات باستخدام site_preview مع view="mobile" وview="desktop"، وكذلك بعرض 360 و768. أصلح التمرير الأفقي والعناوين المتجاوزة والأزرار الضيقة والنص غير المقروء ثم افحص مرة أخرى.
6. قس كل الصفحات باستخدام core_web_vitals مع strategy="mobile" وstrategy="desktop"، واحصل على درجات إمكانية الوصول وأفضل الممارسات وSEO باستخدام seo_audit. الهدف على الجوال هو 100 في إمكانية الوصول وأفضل الممارسات وSEO و95 على الأقل في الأداء؛ وعلى سطح المكتب 95 على الأقل في الأربعة جميعًا. في الصفحة التي تخفق في الهدف، نفّذ core_web_vitals مع resources=true، وابحث عن عنصر LCP وأي صورة كبيرة أكثر من اللازم، وأصلحها وكرر seo_audit مع runs=2، لأن التشغيل المخبري الواحد قد يتذبذب.
7. يجب ألا تحتوي طلبات الشبكة على أي عنوان خارج نطاق الموقع نفسه.

بعد النشر: أرسل sitemap.xml باستخدام gsc_submit_sitemap وافحص الصفحة الرئيسية وأهم ثلاث صفحات باستخدام gsc_inspect_urls. لا توجد أداة تستطيع الضغط على "طلب الفهرسة"؛ فاذكر لي ما يجب أن أطلبه يدويًا في Search Console.

اختم بهذا التقرير: قائمة الصفحات مع درجات الجوال وسطح المكتب لكل صفحة في جدول (الأداء، إمكانية الوصول، أفضل الممارسات، SEO، LCP، CLS)، ونتيجة كل بوابة، والإصلاحات التي أجريتها، والمعلومات التي لا تزال تحتاجها مني. وإذا لم يتحقق أي هدف فقل ذلك بوضوح بدل أن تعلن الانتهاء.

في نهاية التقرير أضف قائمة التحقق من اللائحة: لكل قاعدة من القواعد التسع، "متوافقة" أو "غير متوافقة" مع الدليل. هذا العمل ليس استشارة قانونية؛ اسألني عن أي عبارة لست متأكدًا منها.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقعًا يركز على الاتصال وWhatsApp لنشاط خدمات محلي، مع صفحات مناطق حقيقية وبيانات NAP مطابقة لـ Business Profile الخاص بك

ينشئ موقعًا سريعًا متعدد الصفحات وبدون JavaScript على خادم الاستضافة الخاص بك لسبّاك أو حدّاد أقفال أو خدمة تكييف. يكتب صفحة بمحتوى محلي حقيقي لكل منطقة خدمة، ويجعل الاسم والعنوان والهاتف مطابقة تمامًا لقائمتك في Business Profile.

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

أنشئ موقعًا جديدًا لنشاطي من الصفر على خادم الاستضافة الخاص بي [اسم الخادم]. التفاصيل:
1. اسم النشاط: [اسم النشاط]، المجال: [سبّاك / حدّاد أقفال / خدمة تكييف / غير ذلك]
2. اسم Business Profile أو النطاق: [اسم Business Profile]
3. الخدمات (لكل خدمة صفحتها الخاصة): [الخدمات]
4. الأحياء التي أخدمها ومكان ورشتي: [الأحياء]، [موقع الورشة]
5. الهاتف: [الهاتف]، WhatsApp: [WhatsApp]، العنوان: [العنوان، أو "أخفي عنواني"]، ساعات العمل: [الساعات]
6. النطاق: [النطاق]، تفضيل اللون: [تفضيل اللون]، صور حقيقية: [مكان الصور، أو "لا توجد"]
7. الأعمال التي لا أقوم بها: [الخدمات غير المقدمة]

اقرأ أولًا قائمة [اسم Business Profile] باستخدام gbp_location_details. قارن في جدول واحد الاسم والهاتف والعنوان والموقع الإلكتروني وساعات العمل والفئة الرئيسية والخدمات ورابط الخريطة بما قدمته لك. إذا وُجد اختلاف، اسألني أيهما الصحيح، ولا تغيّر أي شيء في Business Profile. استخدم في الموقع الاسم والعنوان والهاتف تمامًا كما هي مكتوبة في Business Profile. إذا كانت القائمة تخفي العنوان، فلا تعرض عنوان شارع في الموقع واكتفِ بذكر مناطق الخدمة. خذ الإحداثيات من دبوس الخريطة في القائمة فقط، ولا تخمّنها أبدًا. اختر النوع الفرعي لـ LocalBusiness في schema بحسب الفئة الرئيسية (Plumber وLocksmith وHVACBusiness وElectrician وهكذا).

ثم تأكد من الخادم باستخدام list_servers، واستدعِ scaffold_site مع style="service" وconfirm=false أولًا لعرض ما سيتم استبداله، ونفّذه مع confirm=true بعد موافقتي. اقرأ site_design_guide وsite_seo_guide. قبل كتابة الكود، اكتب قرار التصميم في _kaynak/ART.md واعرضه علي: تخطيط سويسري بسيط، وخط عناوين grotesk سميك من Fontshare (مثل Cabinet Grotesk 800) مع خط نصوص بسيط (مثل General Sans 400 و600)، وخلفية بيضاء مائلة للرمادي، ونص كحلي داكن، ولون إشارة واحد بتباين لا يقل عن 4.5:1 مع النص الأبيض، ولون أخضر منفصل لـ WhatsApp. العنصر المميز هو زوج من الأزرار الكبيرة المثبتة أسفل الشاشة على الجوال: "اتصل الآن" و"راسلنا عبر WhatsApp".

الصفحات وschema:
1. الرئيسية: تقول الشاشة الأولى في جملة واحدة ما تقدمه وما الأحياء التي تغطيها، مع زرّي الاتصال وWhatsApp وساعات العمل. ثم بطاقات الخدمات وبطاقات الأحياء وخطوات الزيارة وأسئلة شائعة من 4 أسئلة. Schema: WebPage وFAQPage.
2. صفحة للخدمات وصفحة لكل خدمة: تجيب الفقرة الأولى مباشرة عن "ماذا تفعلون وكيف"؛ ثم الأعراض وخطوات العمل في الموقع ومتى تكون الحالة طارئة وكيف يُحدد السعر (دون اختلاق أرقام) و3 أسئلة شائعة خاصة بالصفحة والكاتب والتاريخ. Schema: Service (provider هو #business وareaServed هي الأحياء) وFAQPage.
3. صفحة منطقة لكل حي. يجب ألا تكون نسخًا مع تبديل اسم المدينة فقط. تتضمن كل صفحة أسماء أحياء تلك المنطقة، وأكثر الأعطال التي تصادفها هناك بحسب طبيعة المباني المحلية (جدول تختلف صفوفه من حي إلى آخر)، وملاحظة عن التنقل ومواقف السيارات، والمسافة من الورشة، وسؤالين شائعين خاصين بذلك الحي وروابط إلى المناطق الأخرى. اكتب 300 كلمة على الأقل من نص أصلي؛ وإذا وجد فحص التكرار في seo-check تداخلًا يزيد على 50 بالمئة بين صفحتي منطقة، فأعد كتابتهما. لا تنشئ صفحة لحي لا أخدمه فعلًا. Schema: AdministrativeArea (containedInPlace المحافظة وcontainsPlace الأحياء) وService وFAQPage.
4. من نحن: من أنت وكيف تعمل وبأي معدات وما الأعمال التي لا تقبلها. Schema: AboutPage وPerson إذا أعطيتك اسمًا حقيقيًا.
5. اتصل بنا: NAP وساعات العمل ورابط "احصل على الاتجاهات" ونموذج WhatsApp. Schema: ContactPage مع mainEntity هو #business.
6. صفحة إشعار الخصوصية وصفحة 404.

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

عمل SEO المشترك: تحصل كل صفحة على title فريد من 48 إلى 60 حرفًا، وdescription من 145 إلى 158 حرفًا، وH1 واحد، وcanonical ينتهي بشرطة مائلة. أضف عقدة WebPage خاصة بكل صفحة وBreadcrumbList، مرتبطتين بالرسم الأساسي عبر @id. في robots.txt اكتب Allow: / لكل من Googlebot وBingbot وOAI-SearchBot وChatGPT-User وGPTBot وClaude-SearchBot وClaude-User وClaudeBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وCCBot، واشرح القرار في تعليق ووضّح ما يجب تغييره إذا أردت حظر زواحف التدريب. يحتوي sitemap.xml على تواريخ lastmod حقيقية. يصف llms.txt النشاط بدقة في جملتين ويسرد NAP والصفحات المهمة مع روابطها.

الإعداد التقني (لا يُستخدم المسار الافتراضي للأداة في هذا الموقع للأسباب التالية):
1. صرّف Tailwind واستغنِ عن CDN. تحمّل الأداة Tailwind عبر Play CDN الذي يترجم في المتصفح ويطبع تحذيرًا في وحدة التحكم ويخفض الأداء على الجوال. اكتب _kaynak/package.json باستخدام site_write_file، وثبّت بـ site_run_command("cd _kaynak && npm i -D tailwindcss@3 html-validate", background=true) وانتظر باستخدام site_command_status. في _kaynak/tailwind.config.js اضبط content على "./*.html" و"./**/*.html" و"!./_kaynak/**" و"./_kaynak/chrome.mjs". انقل قواعد @font-face وأسطر @tailwind وحلقة التركيز ورابط التخطي وحارس overflow من app.css الخاص بالأداة إلى _kaynak/site.css. اجعل المخرجات في assets/app.css، لأن design-check.mjs يبحث عن الخطوط في هذا الملف، وأضف ?v=<hash المحتوى> إلى الرابط في كل صفحة حتى لا تقدّم ذاكرة التخزين المؤقت الطرفية الملف القديم أبدًا.
2. استضف الخطوط بنفسك. اقرأ رابط CSS لعائلات Fontshare التي اخترتها (api.fontshare.com/v2/css?f[]=...) باستخدام site_read_url، ونزّل ملفات woff2 الخاصة بها بـ site_fetch إلى assets/fonts/، وصرّح بها بـ @font-face وfont-display: swap. حمّل مسبقًا كل وزن مستخدم في الجزء العلوي من الصفحة بـ <link rel="preload" as="font" type="font/woff2" crossorigin>، بحد أقصى ثلاثة ملفات. إذا تجاوزت هذه الخطوة فإن تبديل الخط يزيح التخطيط؛ في العرض التجريبي كان CLS على سطح المكتب 0.078 لهذا السبب وانخفض إلى 0 مع التحميل المسبق.
3. اجعل القائمة والتذييل HTML ثابتًا. مكوّنا <site-nav> و<site-footer> في الأداة يعملان بـ JavaScript، ومعظم زواحف الذكاء الاصطناعي لا ترى القائمة ولا العنوان ولا رقم الهاتف أبدًا. أزل سكربتي chrome.js وmotion.js من كل الصفحات. في _kaynak/chrome.mjs اكتب دالتين تبنيان HTML الترويسة والتذييل من assets/site.config.js؛ وابنِ قائمة الجوال بدون JavaScript باستخدام <details> و<summary>، وعلّم الصفحة الحالية بـ aria-current="page". اكتب build.mjs في جذر الموقع بحيث ينفذ بالترتيب node seo-stamp.mjs، ويعيد ختم كل ما بين  و (والأمر نفسه للتذييل) في كل صفحة، ويصرّف Tailwind ويحدّث الـ hash في رابط CSS. بعد كل تغيير، نفّذ فقط site_run_command("node build.mjs").
4. بلا حركة. لا تحمّل GSAP ولا Lenis ولا Swiper ولا أي سكربت حركة في هذا الموقع؛ فالزوار يأتون عبر هواتفهم للاتصال أو المراسلة بسرعة.
5. صغّر الصور. نزّل كل صورة بـ site_fetch في ملفات منفصلة باستخدام resize="480x" و"800x" و"1200x" و"1600x" وimage_format="webp" وجودة بين 60 و68. أعطِ كل <img> قيم srcset وsizes وwidth وheight مطابقة للنسبة الحقيقية؛ وإذا قصصت الصورة فأضف فئة نسبة مثل aspect-[4/3] مع object-cover، وإلا يتحرك التخطيط عند تحميل الصورة. تحصل صورة الشاشة الأولى على fetchpriority="high" ولا تكون lazy؛ وتحصل كل الصور الأخرى على loading="lazy". نزّل صورة المشاركة بصيغة JPG بمقاس 1200x630 باستخدام site_fetch.
6. تفاصيل صغيرة تكلّف نقاطًا: أضف أيقونة favicon بصيغة SVG مع <link rel="icon"> (وإلا يطلب المتصفح /favicon.ico ويظهر الخطأ 404 في وحدة التحكم وتنخفض درجة أفضل الممارسات). اكتب DOCTYPE بأحرف كبيرة، ولا تستخدم سمات style ولا تترك مسافات زائدة في نهاية الأسطر. استخدم &nbsp; بدل المسافات في النص المرئي لروابط الهاتف (قاعدة tel-non-breaking في html-validate). يجب ألا يقل ارتفاع وعرض الروابط في القائمة والتذييل ومسار التنقل والعناوين عن 44 بكسل. لا تضمّن iframe من Google Maps؛ يجب ألا يجري الموقع أي طلبات خارجية، لذا اعرض العنوان ورابط "احصل على الاتجاهات".
7. يجب ألا يغادر أي طلب الموقع: الخطوط والسكربتات والأنماط والصور كلها على خادمك. لا يوجد معالج نماذج، لذا نموذج الاتصال هو نموذج method="get" يشير إلى https://wa.me/[رقم WhatsApp] مع textarea معبأة مسبقًا باسم "text"؛ ولا حاجة إلى JavaScript.

بوابات القبول (بهذا الترتيب؛ لا تعتبر العمل منتهيًا حتى تنجح كلها):
1. نفّذ node build.mjs باستخدام site_run_command ثم node seo-check.mjs: 0 أخطاء، 0 تحذيرات. تحذير المحتوى المكرر يعني أن صفحتين ليستا مختلفتين بما يكفي؛ أعد كتابتهما.
2. node design-check.mjs: 0 أخطاء. إذا اخترت أسلوبًا بلا حركة، فأبلغ عن تحذير "بلا حركة" كقرار متعمد مع ذكر السبب.
3. _kaynak/node_modules/.bin/html-validate على كل ملفات HTML: 0 أخطاء. ضع سطر _kaynak/ في ملف .htmlvalidateignore في جذر الموقع حتى لا تُفحص التبعيات.
4. فحص NAP: اعرض في جدول أن الاسم والعنوان والهاتف في الموقع تطابق مخرجات gbp_location_details حرفًا بحرف.
5. افحص كل صفحة بـ site_preview عند view="mobile" وview="desktop" وكذلك عند عرض 360 و768. أصلح التمرير الأفقي والعناوين الفائضة والأزرار المزدحمة والنص غير المقروء ثم افحص مرة أخرى.
6. قِس كل صفحة بـ core_web_vitals عند strategy="mobile" وstrategy="desktop"، واحصل على درجات إمكانية الوصول وأفضل الممارسات وSEO عبر seo_audit. الهدف على الجوال 100 في إمكانية الوصول وأفضل الممارسات وSEO و95 على الأقل في الأداء؛ وعلى سطح المكتب 95 على الأقل في الأربعة. في الصفحة التي لا تحقق الهدف، نفّذ core_web_vitals مع resources=true، وابحث عن عنصر LCP وأي صورة كبيرة جدًا، وأصلحها وكرر seo_audit مع runs=2، لأن تشغيلًا مخبريًا واحدًا قد يتذبذب.
7. يجب ألا تحتوي طلبات الشبكة على أي عنوان خارج نطاق الموقع نفسه.

اختم بهذا التقرير: قائمة الصفحات مع درجات الجوال وسطح المكتب لكل صفحة في جدول (الأداء، إمكانية الوصول، أفضل الممارسات، SEO، LCP، CLS)، ونتيجة كل بوابة، والإصلاحات التي أجريتها، والمعلومات التي ما زلت بحاجة إليها مني. وإذا لم يتحقق هدف ما فقل ذلك بوضوح بدل اعتبار العمل منتهيًا.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

قِس موقعي المستضاف صفحة بصفحة، واجتز كل بوابات الجودة، وقدّم تقريرًا بالوضع قبل وبعد

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

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

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

بيانات النشاط التجاري، وضع "لا شيء" حيث لا أعرف: [اسم النشاط التجاري]، [المجال]، [الخدمات]، [الهاتف]، [العنوان]، [منطقة الخدمة]، [ساعات العمل]، [البريد الإلكتروني]، [مكان الصور الحقيقية].

1. التحضير. اقرأ الأدلة باستخدام site_design_guide وsite_seo_guide. اعرض الملفات باستخدام site_list_files والنسخة الحالية باستخدام site_versions، ودوّنها كنقطة استعادة. اعرض الصفحات المنشورة مع استثناء صفحة 404. لا تستدعِ scaffold_site لأنه يستبدل index.html ومجلد assets الموجودين.
2. القياس قبل التعديل، دون تغيير أي شيء:
   1. لكل صفحة، احصل على درجة الأداء وLCP وCLS وTBT على الجوال وسطح المكتب باستخدام core_web_vitals.
   2. للصفحة الرئيسية و[أهم صفحة خدمة]، استخدم seo_audit لسرد إخفاقات إمكانية الوصول وSEO وأفضل الممارسات على الجوال عنصرًا عنصرًا. هذه الأداة تستهلك أرصدة، فأخبرني أولًا بعدد الاستدعاءات التي ستجريها.
   3. باستخدام site_run_command، شغّل `node seo-check.mjs` و`node design-check.mjs` و`npx --yes html-validate "**/*.html"` في جذر الموقع. إذا لم تكن أدوات الحزمة في الجذر، فاستخدم seo_technical_audit بدلًا من هذه الثلاثة وأشر إلى ذلك في التقرير.
   4. افتح كل صفحة باستخدام site_preview بعرض 360 و390 و768 و1440 بكسل. ابحث عن تمرير أفقي، وعناوين متجاوزة للحدود، وعناصر متراكبة، ومساحات لمس أصغر من 44 بكسل.
   5. اقرأ الصفحة الرئيسية باستخدام site_read_url مع text=true. وأخبرني هل يرى المتصفح الذي لا يشغّل JavaScript القائمة والروابط الداخلية ورقم الهاتف والعنوان. وبالأداة نفسها تحقق من أن robots.txt وsitemap.xml وllms.txt تعيد 200.
   6. أكمل هذه القائمة للبحث بالذكاء الاصطناعي: هل robots.txt مفتوح أمام GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot وCCBot؛ وهل يحمل sitemap.xml تواريخ lastmod حقيقية؛ وهل يقدم llms.txt ملخصًا قصيرًا ودقيقًا للموقع وصفحاته الرئيسية؛ وهل تحمل كل صفحة JSON-LD مرتبطًا في رسم @id واحد (Organization والنوع الفرعي الصحيح من LocalBusiness وWebSite وWebPage وBreadcrumbList في كل صفحة عدا الرئيسية، وFAQPage فقط حيث تُعرض أسئلة حقيقية)؛ وهل تجيب صفحة الخدمة عن السؤال مباشرة في فقرتها الأولى؛ وهل يوجد تاريخ ظاهر لآخر تحديث ومعلومات النشاط التجاري.
   ضع كل ذلك في جدول "قبل" لكل صفحة وجهاز.
3. خطة الإصلاح. رتّب النتائج هكذا، واعرض ملفًا ملفًا ما الذي سيتغير، وانتظر موافقتي:
   1. الوصول: الروابط الداخلية المعطلة، والعناوين التي تعيد 404، وcanonical الخاطئة، وحظر robots.txt، وnoindex غير المقصود.
   2. المحتوى: العناصر النائبة غير المعبأة، والعناوين والأوصاف المفقودة أو المكررة، ووجود أكثر أو أقل من h1 واحد، والمحتوى الذي يقل عن 150 كلمة. لا تخترع شيئًا أبدًا؛ لا تكتب ساعات عمل أو إحداثيات أو تقييمات أو أسعارًا أو مراجعات أو جوائز أو أعداد عملاء لم أزوّدك بها، بل اسألني.
   3. إمكانية الوصول: التباين، ومستويات العناوين المتخطاة، والصور بلا نص بديل، ومساحات اللمس الأقل من 44 بكسل. يستخدم تذييل الحزمة الافتراضي عناوين أعمدة بلون رمادي فاتح لا تجتاز التباين وهي عناصر h4 تخل بترتيب العناوين؛ أعد كتابتها كفقرات عادية بنص رمادي داكن.
   4. القائمة والتذييل: يُنتَج `<site-nav>` و`<site-footer>` بواسطة JavaScript، لذا لا ترى المتصفحات التي لا تشغّله القائمة ولا بيانات التواصل أبدًا، وتتحرك الصفحة عند تحميل القائمة. اكتب سكربتًا صغيرًا `chrome-stamp.mjs` يطبعهما كـ HTML ثابت في كل صفحة: يقرأ site.config.js كما يفعل seo-stamp.mjs، ويعيد كتابة المنطقة بين `` و`` (وchrome:footer للتذييل) عند كل تشغيل، ويبني قائمة الجوال بـ `<details>` ودون JavaScript، ويضبط aria-current على الصفحة الحالية، ويُبقي كل رابط بارتفاع 44 بكسل على الأقل، ويطبع الاسم والعنوان والهاتف في التذييل. استمر في إدارة القائمة من site.config.js فقط.
   5. صلاحية HTML: `<!DOCTYPE html>` بأحرف كبيرة، وبلا سمات style مضمنة، وtype في كل input، و`&nbsp;` بدل المسافات في رقم هاتف ظاهر (يبلغ html-validate عن ذلك باسم tel-non-breaking)، وwidth وheight في كل صورة.
   6. ملفات schema وAEO: املأ الثغرات من قائمة AEO أعلاه. ضع JSON-LD الخاص بكل صفحة في نهاية body. أعد ختم الرسم الأساسي باستخدام `node seo-stamp.mjs`. وإذا لزم تغيير عنوان، فأعد توجيه القديم بـ 301 باستخدام site_redirects؛ ولا تستخدم meta refresh أبدًا.
   7. الأداء: استبدل Tailwind Play CDN بـ CSS مجمّع ومصغّر، واستضف الخطوط بنفسك، وأعد توليد الصور بصيغتي WebP وAVIF مع srcset، واحذف السكربتات غير المستخدمة، وتحقق من ترويسات التخزين المؤقت باستخدام site_headers. يجب ألا يخرج أي طلب من أصل الموقع نفسه، بما في ذلك favicon.
4. التطبيق بعد موافقتي. بعد كل تغيير أعد تشغيل `node seo-stamp.mjs` ثم `node chrome-stamp.mjs` ثم بناء CSS بهذا الترتيب. إذا تعطل شيء، فارجع إلى النسخة المدوَّنة باستخدام site_restore.
5. القياس بعد التعديل: كرر كل قياسات الخطوة 2 على الصفحات والأجهزة نفسها. استخدم runs=2 مع seo_audit لأن نتائج المختبر تتغير من تشغيل لآخر. المعايير: في كل صفحة أداء على الجوال لا يقل عن 95 وإمكانية وصول وأفضل ممارسات وSEO بدرجة 100؛ وعلى سطح المكتب لا تقل الأربعة عن 95؛ وseo-check بـ 0 أخطاء و0 تحذيرات؛ وdesign-check بـ 0 أخطاء (اشرح كل تحذير)؛ وhtml-validate بـ 0 أخطاء؛ وبلا تجاوز أفقي عند أي من العروض الأربعة. أصلح أي صفحة لا تستوفي معيارًا وقِسها مجددًا.
6. بعد النشر: تأكد باستخدام site_read_url من أن الصفحة الرئيسية المنشورة تغيّرت، وأرسل sitemap.xml باستخدام gsc_submit_sitemap، وأظهر حالة فهرسة الصفحة الرئيسية باستخدام gsc_url_inspect. خاصية Search Console الخاصة بي هي [موقع Search Console، أو "لا يوجد"].

نسّق المخرجات هكذا: أولًا ملخص من جملتين. ثم جدول قبل وبعد: الصفحة، الجهاز، الأداء، إمكانية الوصول، أفضل الممارسات، SEO، LCP، CLS. ثم جدول البوابات: البوابة، قبل، بعد. ثم قائمة الملفات المعدلة وسبب كل تعديل. وأخيرًا، كل ما تعذر إصلاحه أو ينتظر معلومات مني.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

حزمة أداء لموقع مستضاف: Tailwind مُجمَّع، وخطوط مستضافة ذاتيًا، وWebP/AVIF، وبدون أي طلبات لأطراف ثالثة

يحوّل Tailwind الخاص بالحزمة، الذي يعمل داخل المتصفح، إلى ملف CSS واحد مصغَّر، وينقل الخطوط والصور إلى خادمك الخاص، ويزيل السكربتات غير المستخدمة وقائمة JavaScript، ويضبط ترويسات التخزين المؤقت. تُقاس السرعة قبل التنفيذ وبعده.

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

موقعي [عنوان الموقع] على خادم Opus Growth الخاص بي (الخادم [اسم الخادم]، ومفتاح الموقع [مفتاح الموقع] إذا كان موقعًا إضافيًا) أُنشئ بحزمة المواقع، وهو بطيء على الجوال. تحمّل الحزمة Tailwind عبر Play CDN الذي يُجمَّع داخل المتصفح، والخطوط من Fontshare، ومكتبات الحركة من jsDelivr، وتولّد القائمة بـ JavaScript. دون تغيير مظهر الموقع، حوّل كل ذلك إلى ملفات مُجمَّعة مستضافة على خادمي الخاص. الهدف: أثناء تحميل الصفحة، لا يرسل الموقع أي طلب واحد خارج نطاقه.

1. خط الأساس. دوّن الإصدار الحالي بـ site_versions. شغّل core_web_vitals للصفحة الرئيسية و[الصفحة الأثقل] على الجوال وسطح المكتب مع resources=true. ضع في جدول درجة الأداء وLCP وCLS وإجمالي عدد الطلبات والحجم الكلي والطلبات الخارجة من نطاقك. اعرض ملفات HTML بـ site_list_files واستخرج من كل صفحة جميع وسوم `<script>` و`<link>`.
2. اعرض عليّ الخطة وانتظر موافقتي. اذكر كل ملف سيتغير أو سيُضاف.
3. جمّع Tailwind. انقل إعداد `tailwind.config` المضمَّن في الصفحات إلى `_src/tailwind.config.js`؛ اجعل content هو `["./*.html", "./**/*.html"]`، وأضف أي ملف JavaScript ما زال يولّد فئات. أنشئ `_src/input.css` من السطور `@tailwind base; @tailwind components; @tailwind utilities;` متبوعة بمحتوى assets/app.css. شغّل `npx --yes tailwindcss@3 -c _src/tailwind.config.js -i _src/input.css -o assets/site.css --minify` عبر site_run_command. سمِّ الملف باسم مشتق من hash محتواه، مثل `assets/site.3f9a1c2b.css`، وحدّث الرابط في كل صفحة، واحذف سكربت Play CDN والإعداد المضمَّن. أعد البناء بعد كل تعديل HTML يغيّر الفئات، وإلا ستغيب الفئات الجديدة عن CSS.
4. استضف الخطوط بنفسك. اجلب CSS الخاص بـ Fontshare بطلب منفصل لكل عائلة وكل وزن، مثل `https://api.fontshare.com/v2/css?f[]=satoshi@400&display=swap`؛ لاحظنا عودة عائلات أخرى عند طلب عدة عائلات أو أوزان دفعة واحدة، لذا تحقق في كل مرة من اسم font-family المُرجَع. نزّل ملفات woff2 إلى `assets/fonts/`، واكتب قواعد `@font-face` مع `font-display: swap` في أعلى assets/app.css (يبحث design-check عن الخط المميز هناك)، وحمّل مسبقًا خط النص الأساسي والخط المستخدم في العنوان الكبير بالشاشة الأولى عبر `<link rel="preload" as="font" type="font/woff2" crossorigin>`. احذف روابط `preconnect` وstylesheet الخاصة بـ Fontshare. تأكد أن ترخيص الخط يسمح بالاستضافة الذاتية.
5. أعد توليد الصور. انقل ملفات JPG وPNG الأصلية إلى `_src/img/`. ثبّت sharp خارج مجلد الموقع: شغّل `mkdir -p /data/_build && cd /data/_build && npm init -y && npm i sharp` عبر site_run_command مع background=true، وتابعه بـ site_command_status؛ وإذا كان هذا المجلد غير قابل للكتابة فأخبرني بالسبب. بواسطة سكربت node، أنتج WebP (جودة 72) وAVIF (جودة 50) بعرض 480 و800 و1200 و1600 بكسل لكل صورة. في HTML، غلّف كل صورة بـ `<picture>`: عنصر `<source type="image/avif" srcset sizes>` لصيغة AVIF، وعنصر `<img>` بصيغة WebP كبديل مع srcset وsizes خاصين به، والعرض والارتفاع الحقيقيين للصورة الأصلية. تحصل الصورة الرئيسية في الشاشة الأولى على `fetchpriority="high"` ولا تُحمَّل كسولًا؛ وتحصل كل الصور الأخرى على `loading="lazy" decoding="async"`. اكتب sizes بما يطابق العرض الذي تشغله الصورة فعلًا.
6. نظّف السكربتات. إذا لم يكن في الموقع حركة، أو كانت مجرد روابط زخرفية مثل `data-reveal`، فأزل تمامًا GSAP وScrollTrigger وSplitText وLenis وSwiper وmotion.js والسكربت المضمَّن الذي يضيف الفئة `anim`، واحذف قواعد Lenis وanim من app.css. وإذا كانت الحركة ضرورية فعلًا، فانسخ المكتبة إلى `assets/vendor/`، وحمّلها بـ `defer` في الصفحات التي تستخدمها فقط، وتأكد أن المحتوى يبقى ظاهرًا مع `prefers-reduced-motion`. حوّل القائمة والتذييل إلى HTML ثابت بسكربت `chrome-stamp.mjs`: يقرأ site.config.js ويكتب بين العلامات `` و`` وchrome:footer، ويبني قائمة الجوال بـ `<details>`، ويُبقي ارتفاع الروابط 44 بكسل على الأقل، ويستخدم فقرات بدل h4 لعناوين أعمدة التذييل. ثم احذف chrome.js ووسم سكربت site.config.js من الصفحات؛ ويبقى site.config.js مجرد ملف بيانات تقرؤه السكربتات.
7. اجعل طلبات الأطراف الثالثة صفرًا. باستخدام site_run_command، ابحث في HTML وCSS عن قيم src وhref التي تبدأ بـ `https://`؛ وانقل كل مورد خارج نطاقك إلى الموقع أو احذفه، باستثناء روابط tel: وmailto: وwa.me. ضع الأيقونة favicon في `assets/img/` واربطها في كل صفحة، وإلا سيطلب المتصفح /favicon.ico ويسجل خطأ 404 في وحدة التحكم.
8. ترويسات التخزين المؤقت. شغّل site_headers مع mode="list". إذا لم يكن أي ملف تحت assets سيُستبدل بنفس الاسم (اسم CSS يحمل hash، وتأخذ الصور اسمًا جديدًا عند تغيّرها)، فاعرض معاينة السطر `/assets/* Cache-Control: public, max-age=31536000, immutable` مع confirm=false وطبّقه مع confirm=true بعد موافقتي. لا تطلب Cache-Control لملفات HTML؛ فالمنصة تقدّم HTML أصلًا بـ no-cache.
9. المعايير والقياس الجديد. شغّل `node seo-stamp.mjs` ثم `node chrome-stamp.mjs` ثم بناء CSS ثم `node seo-check.mjs` ثم `node design-check.mjs` ثم `npx --yes html-validate "**/*.html"` بهذا الترتيب، وأوصلها جميعًا إلى صفر أخطاء. افحص كل صفحة بـ site_preview عند عرض 360 و390 و768 و1440 بكسل. أعد قياس core_web_vitals من الخطوة 1 على الصفحات نفسها، وشغّل أيضًا seo_audit مع runs=2 للصفحة الرئيسية. إذا كان أداء الجوال أقل من 95، فاعثر على السبب في قوائم resources=true وأصلحه؛ والسبب الأكثر شيوعًا هو إزاحة التخطيط الناتجة عن خط عناوين لم يُحمَّل مسبقًا.

المخرجات: جدول قبل وبعد (الصفحة، الجهاز، الأداء، LCP، CLS، عدد الطلبات، الحجم الكلي بـ KB، عدد طلبات الأطراف الثالثة)، وقائمة الملفات المضافة والمحذوفة، وأسطر site_headers الفعّالة، وملاحظة قصيرة عن الأوامر التي تُعاد وبأي ترتيب بعد التعديل التالي. وإذا أفسدت أي خطوة الموقع، فارجع إلى الإصدار الذي دوّنته بـ site_restore وأخبرني.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

إنشاء مدونة ومركز معرفة مع صفحات للتصنيفات والمؤلف وschema كامل على موقعي المستضاف

ينشئ مدونة ثابتة من مقالات markdown باستخدام blog-build.mjs الخاص بالحزمة، ويسد ثغراتها بخطوة تشطيب: صفحات للتصنيفات والمؤلف، ومسارات تنقل (breadcrumbs) من أربعة مستويات، والمقال السابق/التالي والمقالات ذات الصلة، وschema من نوع BlogPosting وCollectionPage وProfilePage، وRSS وsitemap.

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

أريدك أن تنشئ مدونة ومركز معرفة على موقعي [عنوان الموقع] على خادم Opus Growth الخاص بي. الموضوع: [الموضوع]. التصنيفات: [من 2 إلى 6 أسماء فئات]. المؤلف: [الاسم الحقيقي للكاتب ونبذة قصيرة عنه؛ وإن لم يوجد، "النشر باسم النشاط التجاري"]. مواضيع أو مسودات المقالات الأولى: [المواضيع أو نصوص المسودات]. صور غلاف حقيقية: [الموقع، أو "لا يوجد"].

1. التحضير. اقرأ قسم المدونة في site_seo_guide. اعرض الملفات باستخدام site_list_files ودوّن نسخة الاستعادة باستخدام site_versions. إذا كان الموقع لا يزال يعمل بـ Tailwind Play CDN وخطوط من جهات خارجية، فانقله أولًا إلى CSS مُجمَّع وخطوط مستضافة ذاتيًا، لأن blog-build.mjs ينسخ `<head>` الخاص بـ index.html إلى كل صفحة مدونة. ولنفس السبب، لا تترك في `<head>` الخاص بـ index.html أي JSON-LD خاص بالصفحة الرئيسية أو preload لصورة؛ انقل schema الصفحة الرئيسية إلى نهاية body.
2. الإعداد. في كتلة `blog` داخل site.config.js، اكتب العنوان، ووصفًا من 110 إلى 165 حرفًا، ومقدمة من ثلاث جمل على الأقل لصفحة القائمة، ولكل تصنيف اسمًا ووصفًا من 110 إلى 165 حرفًا ومقدمة أصلية من فقرتين على الأقل، وللمؤلف اسمًا ومسمى وظيفيًا ونبذة ووصف meta من 110 إلى 165 حرفًا. أضف صفحة المقالات والتصنيفات إلى القائمة. إذا لم يُذكر اسم مؤلف حقيقي، فلا تخترع اسمًا؛ انشر باسم النشاط التجاري ولا تنشئ صفحة مؤلف.
3. المقالات. اكتب كل مقال في الملف `blog/_posts/YYYY-MM-DD-slug.md`. Front matter: title (أقل من 65 حرفًا شاملًا لاحقة العلامة التجارية)، description (من 110 إلى 165 حرفًا)، date، وupdated فقط إذا حدّثت المقال فعلًا، وimage، وauthor، وcategory (مفتاح التصنيف)، وtags. المتن: الفقرة الأولى تجيب عن السؤال، ثم عناوين فرعية، وخطوات مرقمة حيث يناسب ذلك، و3 إلى 6 روابط داخلية، وقسم أسئلة شائعة ختامي من سؤالين أو ثلاثة. مهم: يرفع blog-build.mjs مستويات عناوين markdown بمقدار واحد؛ فيصبح `#` هو H2 ويصبح `##` هو H3. إذا بدأت بـ `##` كما يوضح الدليل، فستقفز الصفحة من h1 إلى h3 وتنخفض درجة إمكانية الوصول. لا افتتاحيات مكررة ("في عصرنا الحالي...")، ولا إحصاءات أو مصادر مختلقة، ولا تعرض ما يعتمد على الحالة على أنه قاعدة ثابتة.
4. الصور. أنتج صور الغلاف بصيغتي WebP وAVIF بأحجام 480 و800 و1200 و1600 بكسل بطريقة حزمة الأداء، واكتب `/assets/img/<name>-1200.webp` في حقل image ضمن front matter.
5. الإنشاء. شغّل `node seo-stamp.mjs` ثم `node blog-build.mjs` باستخدام site_run_command. يترك blog-build الثغرات التالية، لذا اكتب سكربت `blog-extras.mjs` يعمل مباشرة بعده:
   1. في صفحات المقالات والقائمة: `<!DOCTYPE html>` بأحرف كبيرة، وcharset واحد فقط وviewport واحد فقط (يضيفهما blog-build مرة أخرى فوق ما ينسخه من index.html)، وclasses بدل الأنماط المضمنة، و`<main id="main">`.
   2. صورة الغلاف: يكتب blog-build قيمة `src` كعنوان مطلق يتضمن النطاق ولا يحدد الأبعاد؛ استبدلها بعنصر `<picture>` بمسار نسبي من الجذر مع srcset بصيغتي AVIF وWebP، وwidth، وheight، و`fetchpriority="high"`.
   3. أزل وسوم السكربت site.config.js وchrome.js وmotion.js التي يضيفها blog-build (بعد الانتقال إلى القائمة الثابتة لن تعود هذه الملفات موجودة وستعرض وحدة التحكم أخطاء 404).
   4. أضف إلى كل مقال مسار تنقل (breadcrumb) ظاهرًا بالشكل الرئيسية › المقالات › التصنيف › المقال، وتاريخي النشر والتحديث، ورابطًا إلى التصنيف، وصندوق مؤلف برابط إلى صفحة المؤلف، والمقال السابق والتالي، ومقالين ذوي صلة، مع تفضيل التصنيف نفسه. أضف articleSection وdateModified وعقدة مؤلف من نوع Person مع url إلى schema من نوع BlogPosting؛ ووسّع BreadcrumbList إلى أربعة مستويات.
   5. أضف og:image ونص المقدمة وروابط التصنيفات إلى صفحة القائمة.
   6. أنشئ صفحة `/blog/kategori/<slug>/` لكل تصنيف: CollectionPage، وItemList مع numberOfItems، وBreadcrumbList؛ واعرض في البطاقات التاريخ والعنوان فقط، لأن تكرار أوصاف المقالات من صفحة القائمة يؤدي إلى ظهور تحذير المحتوى المكرر في seo-check.
   7. أنشئ صفحة `/blog/yazar/<slug>/` للمؤلف: ProfilePage وPerson، مع النبذة وقائمة المقالات.
   8. أضف الصفحات الجديدة إلى sitemap.xml مع lastmod. ينتج blog-build خلاصة RSS؛ أضف رابطًا إليها في الصفحة الرئيسية.
6. القائمة وCSS. حوّل وسمي `<site-nav>` و`<site-footer>` الفارغين في صفحات المدونة إلى القائمة الثابتة باستخدام `node chrome-stamp.mjs` ثم أعد بناء Tailwind، لأن blog-extras يضيف classes جديدة. في كل مرة تضيف فيها مقالًا أو تعدّله، شغّل هذا التسلسل من البداية: seo-stamp، blog-build، blog-extras، chrome-stamp، بناء CSS.
7. البوابات. `node seo-check.mjs` مع 0 أخطاء و0 تحذيرات (150 كلمة على الأقل في كل صفحة ونسبة تكرار بين الصفحات أقل من 50 بالمئة)، و`node design-check.mjs` مع 0 أخطاء، و`npx --yes html-validate "**/*.html"` مع 0 أخطاء. أضف التصنيفات والمقالات وعنوان RSS إلى llms.txt. شغّل core_web_vitals على الجوال وسطح المكتب للصفحة الرئيسية وصفحة القائمة ومقال واحد وتصنيف واحد وصفحة المؤلف؛ وseo_audit لمقال واحد. افتح صفحة القائمة ومقالًا واحدًا باستخدام site_preview بعروض 360 و390 و768 و1440 بكسل. إذا كان أداء الجوال أقل من 95، فابحث عن السبب؛ وإذا كانت العناوين تستخدم خطًا مستقلًا، فنفّذ preload له أيضًا.
8. بعد النشر. أرسل sitemap.xml باستخدام gsc_submit_sitemap وافحص المقالات وصفحات التصنيفات باستخدام gsc_inspect_urls. خاصية Search Console الخاصة بي: [موقع Search Console، أو "لا يوجد"].

المخرجات: قائمة العناوين المنشأة (المقالات، القائمة، التصنيفات، المؤلف، RSS، sitemap)، وجدول schema لكل نوع صفحة، وخريطة الروابط الداخلية (أي صفحة تربط بأي صفحة)، وجدول درجات لكل صفحة وجهاز، وتسلسل الأوامر من خمس خطوات الذي يجب اتباعه عند إضافة مقال جديد.

الموقع الإلكترونييجري تغييرات بعد موافقتك

ارفع موقع WordPress المبني بـ Elementor إلى معيار الجوال وSEO والبحث بالذكاء الاصطناعي

يصحح تجاوز العناصر على الجوال وتسلسل العناوين وحقول meta والـ schema في الصفحات الرئيسية عبر تصميم Elementor نفسه، ويفعّل إعدادات السرعة الآمنة ويفحص robots.txt وllms.txt وصول زواحف الذكاء الاصطناعي، ثم يسدّ الثغرات بعد موافقتك.

متى تستخدمهعندما يحتوي موقع WordPress الخاص بك المبني بـ Elementor على أقسام تتجاوز حدود الشاشة على الجوال أو عناوين غير مرتبة أو meta وschema ناقصة، وتريد التأكد من أن مساعدات الذكاء الاصطناعي تستطيع قراءته.

موقعي على WordPress [عنوان الموقع] مبني بـ Elementor. أريد أن تعمل صفحاتي الرئيسية بشكل ممتاز على الهواتف وأن تكون مقروءة لمحركات البحث ومساعدات الذكاء الاصطناعي. الصفحات: [عناوين حتى 10 صفحات رئيسية؛ إذا تُركت فارغة فالصفحة الرئيسية وصفحات الخدمات وصفحة التواصل]. بيانات النشاط: [اسم النشاط]، [الهاتف]، [العنوان]، [منطقة الخدمة]؛ لا تخترع أي شيء لا تعرفه.

1. اقرأ الإعداد. احصل على القالب والإصدارات عبر wordpress_site_info، وعبر wordpress_list_plugins اعثر على إضافة SEO (Yoast وRank Math وغيرها) وإضافة الكاش وElementor وهل WPCode مثبّتة. اعرض الصفحات المنشورة ومعرّفاتها عبر wordpress_list_posts.
2. قِس دون تغيير أي شيء:
   1. لكل صفحة، أداء الجوال وLCP وCLS عبر core_web_vitals.
   2. للصفحة الرئيسية و[أهم صفحة خدمة]، أخطاء إمكانية الوصول وSEO عبر seo_audit، خصوصًا أخطاء منطقة النقر والتباين وviewport وترتيب العناوين. يستهلك هذا أرصدة؛ أخبرني كم عدد الاستدعاءات.
   3. لكل صفحة، استخدم site_read_url مع outline=true: عدد h1 وشجرة العناوين من h1 إلى h6. ومع text=true في الأداة نفسها: النص والهاتف والعنوان الظاهرة دون JavaScript.
   4. لكل صفحة، عنوان meta والوصف وcanonical وnoindex عبر wordpress_seo.
   5. اقرأ robots.txt وllms.txt عبر site_read_url؛ واقرأ الخيار `blog_public` عبر wordpress_option مع write=false (القيمة 0 تعني أن الموقع مخفي عن محركات البحث).
   6. لا يمكن قياس تجاوز العناصر على الجوال بالبكسل بهذه الأدوات. استخدم نتائج viewport ومنطقة النقر من seo_audit وأعطني قائمة قصيرة بالصفحات التي يجب فحصها على هاتف بعرض 360 بكسل.
   اعرض النتائج في جدول واحد لكل صفحة.
3. تجاوز العناصر على الجوال ومناطق النقر. في صفحة بها مشكلة، احصل على قائمة العناصر عبر wordpress_page_design، وافتح العنصر المشتبه به بالمعامل element وابحث عن عرض ثابت أو حجم خط كبير أو هامش سالب أو أعمدة تبقى جنبًا إلى جنب. نفّذ الإصلاح عبر wordpress_edit_page_design على إعداد الجوال فقط: لا تخمّن أسماء المفاتيح، واستخدم النسخة `_mobile` من المفتاح الذي تراه في إعدادات العنصر (مثل typography_font_size_mobile). غيّر عنصرًا واحدًا في كل مرة في كل صفحة؛ وإذا تعطل شيء فتراجع عنه بـ restore=true.
4. تسلسل العناوين. لكل صفحة h1 واحد بالضبط ولا يُتخطى أي مستوى من العناوين. في عنصر عنوان Elementor، غيّر المستوى عبر الحقل `header_size` باستخدام wordpress_edit_page_design. إذا كان العنوان قادمًا من ملف قالب في الثيم، فاستخدم أولًا wordpress_theme_file مع action="list" و"get"، وأجرِ المعاينة بـ mode="replace" وconfirm=false، ثم طبّق بـ confirm=true بعد موافقتي.
5. Meta وschema. اكتب العناوين والأوصاف المفقودة أو المكررة عبر wordpress_set_seo: عناوين من 50 إلى 60 حرفًا وأوصاف من 140 إلى 160، وفريدة في كل صفحة. اقرأ JSON-LD في HTML الخام للصفحة عبر site_read_url؛ وإذا كان نوع النشاط في رسم إضافة SEO خاطئًا أو مفقودًا، فحاول حله أولًا من إعدادات الإضافة. وبالنسبة إلى نوع فرعي من LocalBusiness لا تستطيع الإضافة إخراجه، أو FAQPage لأسئلة معروضة فعلًا في الصفحة، جهّز مقتطف PHP صغيرًا مرتبطًا بـ `wp_head` عبر wordpress_snippet؛ تُنشأ المقتطفات غير مفعّلة، لذا اعرض عليّ الكود وفعّله بـ toggle بعد موافقتي. لا تخترع أبدًا ساعات عمل أو إحداثيات أو تقييمات أو أسعارًا أو مراجعات.
6. السرعة. اقرأ الإعدادات الحالية والمفاتيح المصنفة محفوفة بالمخاطر عبر wordpress_performance. وعبر wordpress_set_performance، اقترح الآمنة فقط: page_cache وbrowser_cache وminify_css وminify_js وlazy_load. لا تفعّل combine أو defer أو css_async في موقع Elementor؛ وإذا لزم الأمر فافعل ذلك واحدًا في كل مرة، مع confirm_risky، وراجع الصفحة بعد كل واحد. بالنسبة إلى الصورة الرئيسية في الشاشة الأولى، احصل على أحجامها الفعلية وsrcset عبر wordpress_media مع media_id، وتحقق من أنها ليست lazy ومن أنها تُقدَّم بالحجم المناسب. استدعِ wordpress_purge_cache بعد كل تغيير.
7. زواحف الذكاء الاصطناعي وrobots.txt. يجب ألا يحجب robots.txt أيًا من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot وCCBot، ويجب أن يشير إلى خريطة الموقع. إذا لم يوجد ملف robots.txt فعلي، يولّده WordPress؛ فاقترح القواعد الناقصة كمقتطف PHP يُضاف إلى الفلتر `robots_txt` عبر wordpress_snippet. وإذا وُجد ملف فعلي، أو كانت إضافة SEO تدير robots.txt، فأخبرني بإجراء التغيير هناك. وإذا كانت إضافة أمان أو CDN تحجب هذه الزواحف، فأبلغني بذلك وقل بوضوح إنك لا تستطيع التحقق من هذا بالأدوات.
8. llms.txt. إذا لم يوجد، جهّز نص llms.txt يتضمن ملخصًا دقيقًا للموقع من جملتين أو ثلاث، وقائمة الصفحات الرئيسية وبيانات التواصل، واعرضه عليّ. بعد موافقتي، ثبّت مقتطف PHP عبر wordpress_snippet يردّ على `/llms.txt` بنوع `text/plain; charset=utf-8`، واستدعِ wordpress_purge_cache وتأكد عبر site_read_url من أنه يعيد 200.
9. القائمة. عبر wordpress_menus، تأكد من أن القائمة الرئيسية وقائمة التذييل تربطان بكل الصفحات الرئيسية. إذا كان هناك رابط ناقص، فاعرض اقتراحك لـ wordpress_edit_menu.
10. قِس مرة أخرى. كرّر قياسات الخطوة 2 على الصفحات نفسها، مع runs=2 لـ seo_audit. وإذا كان موقعي في Search Console هو [موقع Search Console]، ففحص الصفحات المعدّلة عبر gsc_inspect_urls.

القواعد: قبل كل كتابة، اعرض الحقل الذي سيتغير وقيمته الحالية وقيمته الجديدة، وانتظر موافقتي. في Elementor، غيّر عنصرًا واحدًا في كل مرة. المخرجات: جدول قبل وبعد لكل صفحة (أداء الجوال وLCP وCLS وعدد h1 وترتيب العناوين وطول عنوان meta والوصف وأنواع schema)، وحالة robots.txt وllms.txt، وقائمة التغييرات المنفذة، والصفحات التي يجب أن أفحصها يدويًا.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقع استوديو إبداعي بأسلوب Awwwards: خطوط ضخمة وشريط متحرك متواصل وأثر صور خلف المؤشر

ينشئ موقع استوديو أو وكالة بعناوين ضخمة تظهر سطرًا بسطر باستخدام SplitText، وشريط متحرك لا نهائي، وأزرار مغناطيسية، وأثر صور خلف المؤشر على سطح المكتب. يصل كل تأثير بعد أول عرض للصفحة، ويتوقف على أجهزة اللمس وعند تفعيل تقليل الحركة، ويُقاس Lighthouse على الجوال ويُحافَظ عليه فوق 95.

متى تستخدمهعندما تريد موقعًا لافتًا وغنيًا بالمؤثرات لاستوديو التصميم أو الوكالة الخاصة بك، دون التضحية بالسرعة أو إمكانية الوصول أو الظهور في نتائج البحث.

على خادم الاستضافة الخاص بي في Opus Growth [اسم الخادم]، ابنِ موقعًا سريعًا متعدد الصفحات لـ [اسم الاستوديو] بطابع مواقع الاستوديوهات الإبداعية المعروضة على Awwwards. الاستوديو: [ما الذي يصممه ولمن]، المدينة والحي: [المدينة، الحي]، الفريق: [العدد، الأسماء والأدوار]. الخدمات: [3 خدمات]. الأعمال: [لكل عمل: اسم العميل، نوع العمل، السنة، جملة عن المشكلة، جملة عن الحل، الأجزاء المسلّمة، رابط الصورة]. التواصل: [البريد الإلكتروني]، [الهاتف]، [رقم WhatsApp]، [العنوان]. النطاق: [النطاق]. تفضيل اللون: [اللون أو "اختر أنت"].

الصفحات: الرئيسية (/: قسم hero بعنوان ضخم، شريط marquee متحرك للخدمات، أعمال مختارة، ما نقوم به، العملية، الأسئلة الشائعة، دعوة ختامية لاتخاذ إجراء)، الأعمال (/isler/: المشكلة وما فعلناه وما سلّمناه لكل مشروع)، الاستوديو (/studyo/: الفريق وقواعد العمل)، التواصل (/iletisim/)، الخصوصية وKVKK (/gizlilik/) و404.html. لا نموذج في صفحة التواصل؛ اعرض البريد الإلكتروني والهاتف ورابط WhatsApp برسالة معبأة مسبقًا، مع قائمة بما يجب تضمينه في الرسالة الأولى. في غياب أرقام يعتمدها العميل، صف النتائج وصفًا نوعيًا ولا تكتب نسبًا مئوية ولا أرقام نمو.

الأسلوب: استوديو إبداعي بطابع Awwwards. خلفية بيضاء مائلة للرمادي، نص أسود ولون إشارة واحد يُستخدم كخلفية فقط (مع نص أسود فوقه، بتباين لا يقل عن 4.5:1). خط عرض من Fontshare يصمد في الأحجام الكبيرة جدًا (مثل Clash Display 600) وخط نص هادئ (مثل Ranade). عنوان قسم hero يملأ الشاشة باستخدام clamp بين 3.2rem و12.5rem مع تباعد أحرف ضيق، دون أن يفيض عند 360 px. قائمة الأعمال مجموعة صفوف بصور كبيرة وعناوين كبيرة في شبكة غير متماثلة تتبادل الأعمدة 7/5 و5/7.

قواعد الحركة (الجزء الأصعب، اتبعها حرفيًا):
1. المكتبات: GSAP 3.13 core وScrollTrigger وSplitText وLenis، في صفحتي الرئيسية والأعمال فقط. لا نصوص برمجية إطلاقًا في صفحات الاستوديو والتواصل والخصوصية. لا تحمّل Swiper ولا WebGL ولا فيديو.
2. SplitText: عنصر h1 أعلى الصفحة هو عنصر LCP، لذا لا تبدأه مخفيًا أو منزلقًا للأعلى أبدًا. يبدأ h1 ظاهرًا بلون باهت يجتاز تباين AA، ويحوّل SplitText أسطره إلى اللون الكامل سطرًا بعد سطر (type "lines"، mask "lines"، aria "auto"). احتفظ بدخول الأسطر المقنّعة بانزلاق للأعلى لعناوين h2 أسفل الصفحة وشغّله بـ ScrollTrigger once:true. قسّم النص بعد document.fonts.ready لتكون فواصل الأسطر صحيحة.
3. شريط marquee لا نهائي: اكتب أسماء الخدمات مرة واحدة في HTML. بدون JS ومع تقليل الحركة، تظهر القائمة كمجموعة ثابتة تلتف على أسطر؛ صغّر هذه الحالة الثابتة على الهواتف، لأنها في العرض التجريبي ملأت الشاشة كجدار من ستة أسطر. يكرر JS المجموعة مرة واحدة، ويضع aria-hidden على النسخة، ويحرك x في حلقة لا تنتهي؛ يتسارع لوهلة مع سرعة التمرير ويتوقف عندما يكون الشريط خارج الشاشة. الحركة التي تتجاوز خمس ثوانٍ تحتاج زر "إيقاف مؤقت" ظاهرًا بموجب WCAG 2.2.2 (type="button"، aria-pressed)، يظهر فقط عندما يتحرك الشريط فعلًا. التركيز داخل الشريط يوقفه مؤقتًا أيضًا.
4. أزرار مغناطيسية: فقط على الأجهزة المطابقة لـ `(hover: hover) and (pointer: fine)`، استخدم gsap.quickTo لتحريك تحويل x وy بنسبة 30 إلى 40 بالمئة من مسافة المؤشر عن مركز الزر، مع عودة مرنة عند مغادرة المؤشر. يجب ألا تتغير المنطقة القابلة للنقر في الزر.
5. أثر صور المؤشر: على سطح المكتب فقط، بنفس شرط المؤشر الدقيق، في منطقة hero. يضيف JS طبقة إلى hero تحمل aria-hidden وpointer-events:none وتقع تحت العنوان (z-index). يجب ألا تُحمَّل صور الأثر عند تحميل الصفحة؛ تُحمَّل الصور المصغرة WebP بحجم 280 px عند أول حركة للمؤشر. مع كل 90 px من حركة المؤشر تظهر الصورة التالية من المجموعة عند المؤشر وتكبر من حجم صغير، ثم تنزلق للأسفل وتتلاشى؛ حركها بـ transform وليس left/top.
6. فعّل Lenis فقط على أجهزة `(pointer: fine)` وشغّله من gsap.ticker؛ تحتفظ أجهزة اللمس بالتمرير الأصلي. في الروابط الداخلية للصفحة، انقل التركيز إلى الهدف بعد التمرير.

الإعداد والمزالق المعروفة (كل واحدة كلّفت نقاطًا أو كسرت شيئًا في قياس العرض التجريبي، لا تتجاوز أيًّا منها):
1. إذا كان هناك موقع يعمل على الخادم أصلًا، أخبرني أولًا، لأن الإعداد يستبدل index.html ومجلد assets. اعرض معاينة scaffold_site مع confirm=false واستدعِ confirm=true بعد موافقتي. ثم اقرأ site_design_guide وsite_seo_guide. قبل كتابة الكود، ضع اتجاه التصميم (الطباعة، اللون، الشبكة، العنصر المميز، لغة الحركة والمكتبات التي لن تُحمَّل) في ملف ART.md قصير خارج assets واعرضه علي.
2. اجعل Tailwind مترجمًا، ولا تحمّله من CDN. ثبّت `npm i -D tailwindcss@3` عبر site_run_command مع background=true وتابعه بـ site_command_status. يجب أن تغطي مسارات content في `tailwind.config.js` كل ملفات HTML وكل القوالب وكل ملفات JS التي تكتب أصنافًا. يحتوي `_src/tw.css` على سطر `@import "../assets/app.css";` وأسطر `@tailwind` الثلاثة؛ ترجمه إلى ملف واحد بالأمر `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. أزل سكربت cdn.tailwindcss.com وإعداد tailwind.config المضمّن من الصفحات واربط `/assets/site.css` فقط. أعد الترجمة بعد كل تغيير في HTML.
3. استضف الخطوط ذاتيًا. تحقق أولًا من أن عائلة Fontshare التي تختارها تحتوي على الأحرف التركية (ş، ğ، ı، İ، ç، ö، ü): في العرض التجريبي لم يكن في Tanker حرف ı بلا نقطة ولم يكن في Outfit حروف ş وğ وİ، فكانت هذه الأحرف ستنتقل إلى خط آخر في العناوين. حمّل ملف woff2 لكل وزن على حدة بـ site_fetch إلى `assets/fonts/`، واكتب قواعد @font-face مع `font-display: swap` في `assets/app.css` (يبحث design-check عن الخط المخصص هناك) وتحقق من اسم font-family في ملف CSS الذي حمّلته. نفّذ preload لخطي العنوان والنص المستخدمين أعلى الصفحة في كل الصفحات بـ `<link rel="preload" as="font" type="font/woff2" crossorigin>` قبل ورقة الأنماط؛ لا تجعل preload لأكثر من ملفين، لأن preload لوزن ثالث في العرض التجريبي أطال LCP على الهاتف 0.2 ثانية. معظم خطوط Fontshare تفتقر إلى رمز ₺، لذا اكتب "TL" للأسعار.
4. اجعل القائمة والتذييل HTML ثابتًا. لا تحمّل chrome.js ولا site.config.js في الصفحات. اكتب `chrome-stamp.mjs` صغيرًا يقرأ قائمة التنقل من site.config.js ويختم `_src/header.tpl` و`_src/footer.tpl` بين العلامتين `` و`` في كل صفحة، مضيفًا aria-current="page" إلى الرابط النشط. يجب ألا تنتهي القوالب بـ .html وأن تستخدم عناصر نائبة مثل `[[NAV]]` بدل `{{...}}`. ابنِ قائمة الجوال بدون JS باستخدام `<details>`. أبقِ اسم المنظمة والعنوان والهاتف نصًا عاديًا في التذييل، واجعل كل هدف لمس بحجم 44x44 px على الأقل، بما في ذلك روابط التذييل وفتات التنقل.
5. حوّل الصور أثناء تنزيلها بـ site_fetch: اكتب الصورة نفسها بـ resize="480x" و"800x" و"1200x" وimage_format="webp" وquality=65 في ملفات منفصلة. لا يقص site_fetch الصور أبدًا؛ عندما تحتاج صورة Unsplash إلى نسبة أخرى، نزّل النسخة المقصوصة بإضافة معاملات مثل `?w=1600&h=1200&fit=crop` إلى رابطها. أعطِ كل `<img>` قيم srcset وsizes وwidth وheight مطابقة للنسبة الحقيقية. الصورة الرئيسية أعلى الصفحة تحصل على fetchpriority="high" وليست lazy؛ والبقية تحصل على loading="lazy" decoding="async". إذا ملأت الصورة الرئيسية الشاشة على الجوال، فقدّم اقتطاعًا أصغر عبر `<picture>`.
6. اكتب نسخة SVG من الشعار باسم favicon.svg بـ site_write_file وأضف `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` إلى كل الصفحات. بدون favicon يسجل المتصفح خطأ 404 وتنخفض Best Practices إلى 96.
7. قواعد مدقق HTML: ابدأ بـ `<!DOCTYPE html>` بأحرف كبيرة، استخدم `&nbsp;` للمسافات في النص الظاهر لروابط tel:، لا تستخدم سمة style="" أبدًا، أعطِ كل زر type="button"، ولا تضع `<details>` داخل `<figure>` بعد figcaption.
8. نزّل مكتبات الحركة (GSAP وScrollTrigger وSplitText وLenis) من jsdelivr إلى `assets/vendor/` بـ site_fetch، ثبّت الإصدار وحمّلها في صفحتي الرئيسية والأعمال فقط. لا تستخدم `<script defer>`؛ ضع محمّلًا صغيرًا في نهاية الصفحة ينتظر حدث load، ثم استدعاءين لـ requestAnimationFrame، ثم requestIdleCallback، ويضيف السكربتات بالترتيب مع async=false. سكربت من سطر واحد في `<head>` يضيف الصنف `js` إلى `<html>` والصنف `anim` ما لم تكن prefers-reduced-motion تساوي "reduce"؛ وبدون `anim` لا ينزّل المحمّل شيئًا. عرّف حالات البداية المخفية تحت `.anim` فقط، وأضف حركة CSS كشبكة أمان تُظهر كل عنصر مخفي بعد 2.5 ثانية في حال لم تصل المكتبة أبدًا. في عروض تجريبية سابقة دفعت المكتبات المؤجلة LCP على الجوال إلى 3.2 ثانية؛ ومع هذا المحمّل سجلت الصفحات من 99 إلى 100. سمِّ السمة الخاصة بالعناصر المكشوفة عند التمرير data-reveal؛ فـ design-check لا يتعرف على الحركة إلا بهذا الاسم.

SEO وAEO وGEO:
1. استخدم روابط بنمط المجلدات مع شرطة مائلة أخيرة (/isler/ و/studyo/ و/iletisim/ و/gizlilik/). املأ كتلة seo في site.config.js ونفّذ `node seo-stamp.mjs`. اكتب المخطط الخاص بكل صفحة (الرئيسية WebPage وFAQPage؛ الأعمال CollectionPage مع CreativeWork لكل مشروع في hasPart؛ الاستوديو AboutPage مع عناصر Person للفريق؛ التواصل ContactPage؛ BreadcrumbList في الصفحات الداخلية. لاستوديو له مكتب، businessType ProfessionalService في site.config.js) في كتل `<script type="application/ld+json">` منفصلة واربطها بالرسم الأساسي عبر @id. لا تضع BreadcrumbList داخل @graph؛ أبقِه في كتلته الخاصة، لأن هذه هي الطريقة الوحيدة التي يراه بها seo-check.
2. أبقِ العناوين عند 60 حرفًا أو أقل (يعدّ seo-check كل ما يتجاوز 65 خطأ)، والأوصاف بين 120 و158 حرفًا، وh1 واحدًا في كل صفحة ودون تخطي مستويات العناوين (وجود h3 مباشرة بعد h1 خفّض إمكانية الوصول إلى 98). تحتاج كل صفحة إلى 150 كلمة على الأقل من المحتوى الرئيسي؛ وصفحتا التواصل والخصوصية تميلان إلى النقص.
3. الفقرة الأولى في كل صفحة تجيب مباشرة عن سؤال الصفحة. اكتب أسئلة شائعة خاصة بكل صفحة بـ `<details>` ووسمها بـ FAQPage. اعرض المنظمة الناشرة وتاريخ "آخر تحديث" داخل `<time>`.
4. في robots.txt، دوّن قرارك وبرّره لكل من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot وCCBot، وأشر إلى خريطة الموقع. أعطِ sitemap.xml تواريخ lastmod حقيقية. يحتوي llms.txt على ملخص دقيق للموقع من جملتين، والحقائق الأساسية، وقائمة بالصفحات المهمة.
5. لا اختلاق: لا تكتب مراجعات ولا تقييمات ولا جوائز ولا أعداد عملاء ولا شهادات ولا ساعات عمل ولا إحداثيات ولا أسعارًا دون أن تسألني. اترك أي حقل لا تعرفه خارج المخطط تمامًا.

بوابات التحقق (بالترتيب؛ لا تقل "تم" قبل أن تنجح كلها):
1. باستخدام site_run_command نفّذ `node chrome-stamp.mjs` وبناء Tailwind و`node seo-stamp.mjs` و`node seo-check.mjs` (0 أخطاء، 0 تحذيرات) و`node design-check.mjs` (0 أخطاء؛ برّر أي تحذير متبقٍ) و`npx html-validate "**/*.html"` (0 أخطاء).
2. اعرض كل صفحة بـ site_preview مع view="mobile" وview="desktop". يلتقط site_preview الصفحة مع إيقاف الحركة (reduced-motion)؛ إذا نقص محتوى في هذه اللقطة فالحالة بلا حركة معطّلة. قد تظهر الصور الكسولة في الأسفل فارغة في لقطة الصفحة الكاملة؛ لا تعدّ ذلك خطأ، لكن تحقق من مساراتها.
3. نفّذ core_web_vitals مع strategy="mobile" وstrategy="desktop" لكل صفحة. معيار القبول: على الجوال Performance لا يقل عن 95 وAccessibility وBest Practices وSEO بقيمة 100؛ وعلى سطح المكتب الأربعة لا تقل عن 95. للصفحة التي لا تبلغ ذلك، اعثر على الملف البطيء بـ resources=true وأصلحه وقِس مجددًا. ثم نفّذ seo_audit على الصفحة الرئيسية مع strategy="mobile" وruns=2. يجب ألا يبقى أي عنوان خارج نطاقك في قائمة طلبات الشبكة.
4. لا تمرير أفقي عند 360 و390 و768 و1440 px، وأهداف لمس لا تقل عن 44 px ولا أخطاء في وحدة التحكم. ويجب أن يبدو الموقع سليمًا تمامًا داخل إطار 390x790 وإطار 1440x898، كما في صفحات الـ prompts.

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

بعد النشر: عاين قاعدة `/assets/* Cache-Control: public, max-age=31536000, immutable` بـ site_headers وطبّقها بعد موافقتي؛ ومن ذلك الحين غيّر اسم الملف بإضافة رقم إصدار كلما تغيّر CSS أو JS (site-v2.css وهكذا). أرسل sitemap.xml بـ gsc_submit_sitemap وافحص الصفحة الرئيسية بـ gsc_url_inspect. وأخيرًا قدّم لي: جدول نتائج لكل صفحة (الصفحة، أربع نتائج للجوال، أربع نتائج لسطح المكتب، LCP، CLS)، ونتائج البوابات، ونتيجة التفاعلات التي جرّبتها في المتصفح، وقائمة الإصلاحات التي طبقتها.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقع معرض أعمال بتمرير أفقي وصفحات للمشاريع لمهندس معماري أو مصور

ينشئ معرض مشاريع مثبّتًا يتحرك أفقيًا أثناء التمرير للأسفل على سطح المكتب، مع صور تظهر بتأثير clip-path وصفحة تفاصيل لكل مشروع. على الهواتف، وبدون JavaScript، ومع تقليل الحركة، يتحول المعرض إلى تكديس عمودي؛ ويعمل بلوحة المفاتيح، ويتم قياس Lighthouse على الجوال والحفاظ عليه فوق 95.

متى تستخدمهعندما تريد عرض أعمال مكتبك المعماري أو تصويرك الفوتوغرافي بصور كبيرة، كأنك تتجول في معرض، دون التضحية بزوار الهاتف أو بالظهور في نتائج البحث.

على خادم الاستضافة الخاص بي في Opus Growth [اسم الخادم]، ابنِ موقع معرض أعمال بتمرير أفقي لـ [اسم المكتب أو المصور]. ما أقدمه: [العمارة أو التصميم الداخلي أو التصوير؛ أي نوع من الأعمال]، المدينة: [المدينة، الحي]، سنة التأسيس والفريق: [السنة، عدد الأفراد، اسم المؤسس]. المشاريع: [لكل مشروع: الاسم، المكان، السنة، الحالة، المساحة المبنية أو نوع الجلسة، ملخص بجملة واحدة، السؤال، المقاربة، العملية، المواد أو التقنية، رابطا صورتين على الأقل]. الأعمال الجارية: [الاسم، المكان، السنة، جملة واحدة]. التسجيل المهني: [إن وجد]. التواصل: [البريد الإلكتروني]، [الهاتف]، [رقم WhatsApp]، [العنوان]. النطاق: [النطاق].

الصفحات: الرئيسية (/: قسم hero، معرض أفقي للمشاريع، المقاربة، الأسئلة الشائعة)، وصفحة لكل مشروع (/projeler/[اسم-المشروع]/: صورة بعرض كامل، بطاقة معلومات، السؤال، المقاربة، العملية، المواد، صورة ثانية، رابط إلى المشروع التالي)، والمكتب والتواصل (/ofis/، مع قسم التواصل عند المرساة #iletisim)، والخصوصية وKVKK (/gizlilik/) وصفحة 404.html. بدون نموذج؛ يكفي البريد الإلكتروني والهاتف ورابط WhatsApp برسالة معبأة مسبقًا. إذا لم تكن لمشروع جارٍ صفحة تفاصيل، فلا تجعل بطاقته رابطًا.

الأسلوب: معرض أعمال هادئ بطابع المعارض الفنية. خلفية بلون حجر الكلس، ونص داكن، وزوايا حادة وخطوط رفيعة؛ ولا يظهر لون التمييز إلا عند التمرير بالمؤشر (hover) والتركيز. خط عناوين بخطوط سيريف من Fontshare (مثل Erode) وخط نص غروتسك بسيط (مثل Archivo). على سطح المكتب يملأ قسم hero الشاشة، فيبدأ المعرض أسفل المشهد الأول.

قواعد الحركة (الجزء الأصعب، التزم بها حرفيًا):
1. المكتبات: GSAP 3.13 core وScrollTrigger وLenis، في الصفحة الرئيسية وصفحات المشاريع. لا يتم تحميل SplitText وSwiper؛ ولا نصوص برمجية إطلاقًا في صفحتي المكتب والخصوصية.
2. الـ HTML والـ CSS الافتراضيان عبارة عن تكديس عمودي: عمود واحد على الهواتف وشبكة من عمودين على سطح المكتب. بدون JS ومع تقليل الحركة وعلى الهواتف يبقى المعرض هكذا.
3. اترك لـ CSS، لا لـ JS، بناء التخطيط الأفقي: عند عرض 768 px فأكثر وعند وجود الصنف `.anim`، يكون المسار `display:flex` و`width:max-content` و`height:calc(100vh - ارتفاع الترويسة)` منذ أول رسم، ويتمرر الغلاف من تلقاء نفسه عبر `overflow-x:auto`. بهذا لا يتغير التخطيط عند وصول JS (CLS 0)، وإذا لم تصل المكتبة أبدًا يمكن تمرير المعرض جانبيًا.
4. باستخدام gsap.matchMedia، وفقط لـ `(min-width: 768px)`، ثبّت الغلاف بـ ScrollTrigger مع scrub 0.8 وقيمة end تساوي فائض المسار ("+=" + (track.scrollWidth - innerWidth)) وتفعيل invalidateOnRefresh؛ وأضف صنفًا يعطي الغلاف `overflow:hidden`. يتقدم خط تقدم رفيع بواسطة scaleX.
5. كشف الصور: تنفتح صور المعرض من اليسار إلى اليمين باستخدام containerAnimation، من clip-path `inset(0 100% 0 0)` إلى `inset(0)`. لا تُخفِ أبدًا اللوحة الظاهرة في المشهد الأول ولا صورة hero. على الهواتف وفي صفحات المشاريع، تنفتح إلى الأعلى بـ clip-path فقط الصور الموجودة أسفل الشاشة عند التحميل.
6. لوحة المفاتيح: عندما يصل Tab إلى بطاقة خارج الشاشة في المسار، يمرر المتصفح الغلاف داخليًا فتختفي البطاقة. عند focusin، أعد scrollLeft الخاص بالغلاف إلى 0 ومرر الصفحة إلى الموضع العمودي الذي تظهر فيه البطاقة (scrollTrigger.start + (end - start) * الإزاحة اليسرى للبطاقة / الفائض الكلي). بدون هذه الخطوة بقيت البطاقة الثالثة التي وصلنا إليها بـ Tab خارج الشاشة في العرض التجريبي.
7. فعّل Lenis فقط على أجهزة `(pointer: fine)` واربطه بـ ScrollTrigger.update؛ وعند الروابط الداخلية مثل #projeler، انقل التركيز إلى الهدف بعد التمرير.

الإعداد والمطبات المعروفة (كل واحدة منها كلّفت نقاطًا أو كسرت شيئًا في قياس العرض التجريبي، فلا تتخطَّ أيًّا منها):
1. إذا كان هناك موقع يعمل بالفعل على الخادم، فأخبرني أولًا، لأن الإعداد يستبدل index.html ومجلد assets. اعرض معاينة لـ scaffold_site مع confirm=false واستدعِها مع confirm=true بعد موافقتي. ثم اقرأ site_design_guide وsite_seo_guide. قبل كتابة الكود، ضع اتجاه التصميم (الخطوط واللون والشبكة والعنصر المميز ولغة الحركة والمكتبات التي لن يتم تحميلها) في ملف ART.md قصير خارج assets واعرضه عليّ.
2. اضبط Tailwind بالتجميع، ولا تحمّله من CDN. ثبّت `npm i -D tailwindcss@3` باستخدام site_run_command مع background=true، وتابعه عبر site_command_status. يجب أن تغطي مسارات content في `tailwind.config.js` كل ملفات HTML وكل القوالب وكل ملفات JS التي تكتب أصنافًا. يحتوي `_src/tw.css` على سطر `@import "../assets/app.css";` وأسطر `@tailwind` الثلاثة؛ جمّعه في ملف واحد بالأمر `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. أزل سكربت cdn.tailwindcss.com وtailwind.config المضمن من الصفحات واربط `/assets/site.css` فقط. أعد التجميع بعد كل تغيير في HTML.
3. استضف الخطوط ذاتيًا. تحقق أولًا من أن عائلة Fontshare التي تختارها تحتوي على الحروف التركية (ş وğ وı وİ وç وö وü): في العرض التجريبي لم يكن في Tanker حرف ı بلا نقطة ولم يكن في Outfit الحروف ş وğ وİ، فكانت هذه الحروف ستنتقل إلى خط آخر في العناوين. نزّل ملف woff2 لكل وزن على حدة باستخدام site_fetch إلى `assets/fonts/`، واكتب قواعد @font-face مع `font-display: swap` في `assets/app.css` (يبحث design-check عن الخط المخصص هناك) وتحقق من اسم font-family في ملف CSS الذي نزّلته. نفّذ preload لخطي العناوين والنص المستخدمين فوق خط الطي في كل صفحة عبر `<link rel="preload" as="font" type="font/woff2" crossorigin>`، قبل ملف الأنماط؛ ولا تنفذ preload لأكثر من ملفين، لأن preload لوزن ثالث في العرض التجريبي زاد LCP على الهاتف بمقدار 0.2 ثانية. تفتقر معظم خطوط Fontshare إلى رمز ₺، لذا اكتب "TL" في الأسعار.
4. اجعل القائمة والتذييل HTML ثابتًا. لا تحمّل chrome.js ولا site.config.js في الصفحات. اكتب `chrome-stamp.mjs` صغيرًا يقرأ قائمة التنقل من site.config.js ويختم `_src/header.tpl` و`_src/footer.tpl` بين العلامتين `` و`` في كل صفحة، مع إضافة aria-current="page" إلى الرابط النشط. يجب ألا تنتهي القوالب بـ .html وأن تستخدم عناصر نائبة مثل `[[NAV]]` بدل `{{...}}`. ابنِ قائمة الهاتف بدون JS باستخدام `<details>`. أبقِ اسم المؤسسة والعنوان والهاتف نصًا عاديًا في التذييل، واجعل كل هدف لمس بحجم 44x44 px على الأقل، بما في ذلك روابط التذييل ومسار التنقل (breadcrumb).
5. حوّل الصور أثناء تنزيلها بـ site_fetch: احفظ الصورة نفسها مع resize="480x" و"800x" و"1200x" وimage_format="webp" وquality=65 في ملفات منفصلة. لا يقص site_fetch الصور أبدًا؛ وعندما تحتاج صورة من Unsplash إلى نسبة أخرى، نزّل النسخة المقصوصة بإضافة معاملات مثل `?w=1600&h=1200&fit=crop` إلى عنوانها. أعطِ كل `<img>` سمات srcset وsizes وwidth وheight تطابق النسبة الحقيقية. تحصل الصورة الرئيسية فوق خط الطي على fetchpriority="high" ولا تكون lazy؛ وتحصل البقية على loading="lazy" decoding="async". إذا كانت الصورة الرئيسية تملأ الشاشة على الهاتف، فقدّم قصًا أصغر عبر `<picture>`.
6. اكتب نسخة SVG من الشعار باسم favicon.svg باستخدام site_write_file وأضف `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` إلى كل صفحة. بدون أيقونة موقع يسجل المتصفح خطأ 404 وينخفض Best Practices إلى 96.
7. قواعد مدقق HTML: ابدأ بـ `<!DOCTYPE html>` بأحرف كبيرة، واستخدم `&nbsp;` للمسافات في النص المرئي لروابط tel:، ولا تستخدم السمة style="" أبدًا، وأعطِ كل زر type="button"، ولا تضع `<details>` داخل `<figure>` بعد figcaption.
8. نزّل مكتبات الحركة (GSAP وScrollTrigger وLenis) من jsdelivr إلى `assets/vendor/` باستخدام site_fetch، وثبّت الإصدار وحمّلها فقط في الصفحة الرئيسية وصفحات المشاريع. لا تستخدم `<script defer>`؛ ضع محمّلًا صغيرًا في نهاية الصفحة ينتظر حدث load ثم استدعاءين لـ requestAnimationFrame ثم requestIdleCallback، ويُلحق السكربتات بالترتيب مع async=false. يضيف سكربت من سطر واحد في `<head>` الصنف `js` إلى `<html>` والصنف `anim` ما لم تكن قيمة prefers-reduced-motion هي "reduce"؛ وبدون `anim` لا ينزّل المحمّل شيئًا. عرّف حالات البداية المخفية تحت `.anim` فقط، وأضف حركة CSS كشبكة أمان تكشف كل العناصر المخفية بعد 2.5 ثانية في حال لم تصل المكتبة أبدًا. في عروض تجريبية سابقة دفعت المكتبات المؤجلة LCP على الهاتف إلى 3.2 ثانية؛ ومع هذا المحمّل سجّلت الصفحات من 99 إلى 100. سمِّ سمة العناصر التي تظهر عند التمرير data-reveal؛ فلا يتعرف design-check على الحركة إلا بهذا الاسم.

SEO وAEO وGEO:
1. استخدم عناوين URL بنمط المجلدات مع شرطة مائلة في النهاية (/projeler/[اسم-المشروع]/ و/ofis/ و/gizlilik/). املأ كتلة seo في site.config.js ونفّذ `node seo-stamp.mjs`. اكتب schema الخاص بكل صفحة (الرئيسية: WebPage وFAQPage؛ وكل صفحة مشروع: WebPage مع CreativeWork كـ mainEntity، تتضمن dateCreated وlocationCreated وimage؛ والمكتب: AboutPage مع Person للمؤسس؛ وBreadcrumbList في الصفحات الداخلية. لاستوديو عمارة أو تصوير له مكتب، businessType هو ProfessionalService) في كتل `<script type="application/ld+json">` منفصلة واربطها بالرسم الأساسي عبر @id. لا تضع BreadcrumbList داخل @graph؛ أبقِه في كتلة مستقلة، لأن هذه هي الطريقة الوحيدة التي يراه بها seo-check.
2. أبقِ العناوين عند 60 حرفًا أو أقل (يعدّ seo-check كل ما يزيد على 65 خطأ)، والأوصاف بين 120 و158 حرفًا، وعنوان h1 واحدًا لكل صفحة، وبدون تخطي أي مستوى من مستويات العناوين (وضع h3 مباشرة بعد h1 خفّض إمكانية الوصول إلى 98). تحتاج كل صفحة إلى 150 كلمة على الأقل من المحتوى الرئيسي؛ وغالبًا ما تقصر صفحتا التواصل والخصوصية عن ذلك.
3. تجيب الفقرة الأولى من كل صفحة مباشرة عن سؤال الصفحة. اكتب أسئلة شائعة خاصة بكل صفحة باستخدام `<details>` ووسمها بـ FAQPage. أظهر المؤسسة الناشرة وتاريخ "آخر تحديث" داخل `<time>`.
4. في robots.txt، اكتب قرارك وبرّره لكل من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot وCCBot، وأشِر إلى خريطة الموقع. أعطِ sitemap.xml تواريخ lastmod حقيقية. يحتوي llms.txt على ملخص دقيق للموقع من جملتين والحقائق الأساسية وقائمة بالصفحات المهمة.
5. لا اختلاق: لا تكتب مراجعات أو تقييمات أو جوائز أو أعداد عملاء أو شهادات أو ساعات عمل أو إحداثيات أو أسعارًا دون أن تسألني. اترك أي حقل لا تعرفه خارج schema تمامًا.

بوابات الجودة (بالترتيب؛ لا تقل "تم" حتى تنجح جميعها):
1. باستخدام site_run_command نفّذ `node chrome-stamp.mjs` ثم تجميع Tailwind ثم `node seo-stamp.mjs` ثم `node seo-check.mjs` (0 أخطاء، 0 تحذيرات) ثم `node design-check.mjs` (0 أخطاء؛ برّر أي تحذير متبقٍّ) ثم `npx html-validate "**/*.html"` (0 أخطاء).
2. اعرض كل صفحة بـ site_preview مع view="mobile" وview="desktop". يلتقط site_preview الصفحة مع إيقاف الحركة (reduced-motion)؛ وإذا نقص محتوى في هذه اللقطة فهذا يعني أن حالة عدم وجود الحركة معطلة. قد تظهر الصور الكسولة في الأسفل فارغة في لقطة الصفحة الكاملة؛ لا تعدّ ذلك خطأ، لكن تحقق من مساراتها.
3. نفّذ core_web_vitals مع strategy="mobile" وstrategy="desktop" لكل صفحة. معيار القبول: على الهاتف Performance لا يقل عن 95 وAccessibility وBest Practices وSEO بقيمة 100؛ وعلى سطح المكتب تكون الأربعة جميعها 95 على الأقل. للصفحة التي لا تحقق ذلك، اعثر على الملف البطيء باستخدام resources=true وأصلحه وأعد القياس. ثم نفّذ seo_audit على الصفحة الرئيسية مع strategy="mobile" وruns=2. يجب ألا يبقى أي عنوان خارج نطاقك الخاص في قائمة طلبات الشبكة.
4. لا تمرير أفقي عند 360 و390 و768 و1440 px، وأهداف لمس لا تقل عن 44 px ولا أخطاء في وحدة التحكم (console). ويجب أن يبدو الموقع سليمًا تمامًا داخل إطار 390x790 وإطار 1440x898 أيضًا، كما في صفحات الـ prompts.

فحص الحركة: لا يستطيع site_preview عرض الحركة، لذا أخبرني بما يجب أن أراقبه في متصفحي. على سطح المكتب، يجب أن يثبت المعرض في الأعلى عند الوصول إلى قسم المشاريع، وأن تنساب البطاقات إلى اليسار أثناء التمرير للأسفل، وأن تنفتح الصور من اليسار إلى اليمين، وأن يمتلئ خط التقدم؛ وبعد البطاقة الأخيرة تعود الصفحة إلى التدفق العادي. عند التنقل بين البطاقات بـ Tab، يجب أن تكون البطاقة المركَّز عليها دائمًا على الشاشة. على الهاتف ومع تفعيل تقليل الحركة، يكون المعرض عبارة عن تكديس من البطاقات ولا يثبت أي شيء.

بعد النشر: اعرض معاينة للقاعدة `/assets/* Cache-Control: public, max-age=31536000, immutable` باستخدام site_headers وطبّقها بعد موافقتي؛ ومن ذلك الحين، غيّر رقم إصدار اسم الملف كلما تغير CSS أو JS (site-v2.css وهكذا). أرسل sitemap.xml باستخدام gsc_submit_sitemap وافحص الصفحة الرئيسية بـ gsc_url_inspect. وأخيرًا قدّم لي: جدول نتائج لكل صفحة (الصفحة، النتائج الأربع على الهاتف، النتائج الأربع على سطح المكتب، LCP، CLS)، ونتائج البوابات، ونتيجة التفاعلات التي جرّبتها في المتصفح، وقائمة الإصلاحات التي طبّقتها.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقع تعريف لتطبيق جوال مع نموذج هاتف تتغير شاشته أثناء التمرير

ينشئ موقعًا لتطبيقك مع إطار هاتف يبقى ثابتًا على سطح المكتب ويعرض شاشة الميزة التي تقرأ عنها، إضافة إلى قائمة الميزات وجدول الأسعار والأسئلة الشائعة وأزرار المتاجر وصفحتي الدعم والخصوصية. تُرسم الشاشات بـ HTML، وعلى الهواتف تظهر كل ميزة مع شاشتها الخاصة، ويُقاس Lighthouse للجوال ويُحافظ عليه فوق 95.

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

على خادم الاستضافة الخاص بي في Opus Growth باسم [اسم الخادم]، ابنِ موقع هبوط لتطبيق الجوال [اسم التطبيق]. التطبيق: [ما يفعله ولمن هو موجّه]، المنصات والحد الأدنى للإصدارات: [إصدارات iOS وAndroid]. الميزات الرئيسية الأربع وما تعرضه كل شاشة: [الميزة، وصف بجملة واحدة، العناصر على الشاشة]. الباقات والأسعار: [اسم الباقة، السعر، المدة، الميزات المتضمنة، مدة التجربة؛ شامل ضريبة القيمة المضافة أو غير شامل]. روابط المتاجر: [رابط App Store]، [رابط Google Play]. أسئلة الدعم: [إجابات حقيقية عن حذف الحساب والإلغاء وتصدير البيانات وغيرها]. الشركة وبيانات التواصل: [اسم الشركة]، [العنوان]، [بريد الدعم الإلكتروني]، [الهاتف]. النطاق: [النطاق]. لقطات شاشة حقيقية: [روابط أو "لا يوجد، ارسمها بـ HTML"].

الصفحات: الرئيسية (/: قسم البطل، قصة الميزات بقيادة الهاتف #ozellikler، من يستخدمه، الأسعار #fiyatlar، الأسئلة الشائعة، دعوة لاتخاذ إجراء للتحميل #indir)، الدعم (/destek/: الأسئلة الشائعة وبيانات التواصل مع الدعم)، الخصوصية وKVKK (/gizlilik/: تغطي التطبيق والموقع معًا؛ فالمتاجر تطلب رابط سياسة الخصوصية) وصفحة 404.html. يتضمن قسم الأسعار بطاقات الباقات وتحتها مقارنة في `<table>` حقيقي؛ لا تعطِ الجدول min-width، لأن عرضًا أدنى ثابتًا في النسخة التجريبية دفع الأعمدة خارج الشاشة على الهواتف.

الأسلوب: صفحة هبوط دافئة وموثوقة للتطبيق. خلفية بلون كريمي، ولون أساسي داكن للعلامة، ولون تمييز ساطع واحد يُستخدم كخلفية فقط. خط عرض مستدير وودود من Fontshare (مثل Chillax) وخط نصوص مقروء (مثل Manrope). ارسم إطار الهاتف بـ CSS (aspect-ratio 9/19، زوايا مستديرة، نتوء علوي) وابنِ الشاشات بـ HTML وCSS بدلًا من ملفات الصور؛ بطاقات الشاشات زخرفة بخاصية aria-hidden والنص المجاور لها يصف الميزة. لتطبيق حقيقي، نزّل شارات Apple وGoogle الرسمية إلى خادمك الخاص لأزرار المتاجر والتزم بإرشاداتهما؛ وأضف ملاحظة العلامات التجارية في تذييل الصفحة.

قواعد الحركة (الجزء الأصعب، اتبعها حرفيًا):
1. المكتبات: نواة GSAP 3.13 وScrollTrigger فقط، وفي الصفحة الرئيسية فقط. مكتبات Lenis وSplitText وSwiper وLottie والفيديو لا تُحمَّل؛ ولا سكربتات إطلاقًا في صفحتي الدعم والخصوصية.
2. يحمل كل قسم ميزة هاتفه الصغير وشاشته الخاصين في HTML. على الهواتف، وبدون JS ومع تقليل الحركة، تظهر كل ميزة مع شاشتها الخاصة، مرتبة فوق بعضها (جنبًا إلى جنب على الشاشات الأوسع)؛ ويجب أن تكون هذه الحالة مكتملة بذاتها.
3. عند عرض 1024 بكسل فأكثر، وعندما تكون الحركة مسموحة، ينسخ JS الشاشات من الأقسام إلى الهاتف الوحيد في العمود الأيمن، ويضيف الفئة `has-phone` إلى القسم، ويخفي الهواتف الصغيرة. لا تكتب الشاشات مرتين في HTML. وبما أن قسم الميزات يقع أسفل الشاشة الأولى، فإن تغيير الفئة هذا لا يُحتسب ضمن تحوّل التخطيط؛ وقد قاست النسخة التجريبية CLS بقيمة 0.
4. ثبّت الهاتف في مكانه بـ `position: sticky` في CSS (top: calc(50vh - نصف ارتفاع الهاتف)) بدلًا من تثبيت ScrollTrigger. لا يُضاف pin-spacer، ويعمل بدون JS ولا تقفز الصفحة.
5. تبديل الشاشة: لكل قسم ميزة استخدم ScrollTrigger.create مع start "top 55%" وend "bottom 55%" وonToggle؛ أظهر الشاشة النشطة بـ autoAlpha من gsap وأخفِ السابقة بـ autoAlpha 0. لا تستخدم opacity وحدها؛ يجب أن تكون الشاشات المخفية visibility:hidden حتى لا يقرأها تدقيق إمكانية الوصول. يتغير لون عنوان القسم النشط (دون تلاشٍ بـ opacity)، وتبيّن نقاط بجانب الهاتف أي ميزة نشطة.
6. تظهر البطاقات وصناديق الأسعار بـ data-reveal، وتنزلق للأعلى بمقدار 20 بكسل عند التمرير؛ امسح الشاشات المنسوخة في دالة التراجع الخاصة بـ matchMedia حتى لا يتعطل التخطيط عند تضييق النافذة.

الإعداد والمطبّات المعروفة (كلٌّ منها كلّف نقاطًا أو عطّل شيئًا في قياس النسخة التجريبية، فلا تتجاوز أيًّا منها):
1. إذا كان هناك موقع يعمل بالفعل على الخادم، فأخبرني أولًا، لأن الإعداد يستبدل index.html ومجلد assets. اعرض معاينة scaffold_site مع confirm=false ثم استدعِ confirm=true بعد موافقتي. بعد ذلك اقرأ site_design_guide وsite_seo_guide. قبل كتابة الشيفرة، ضع اتجاه التصميم (الطباعة، اللون، الشبكة، العنصر المميز، لغة الحركة والمكتبات التي لن تُحمَّل) في ملف ART.md قصير خارج assets واعرضه عليّ.
2. قم بتجميع Tailwind ولا تحمّله من CDN. ثبّت `npm i -D tailwindcss@3` عبر site_run_command مع background=true، وتابعه عبر site_command_status. يجب أن تغطي مسارات content في `tailwind.config.js` كل ملفات HTML وكل القوالب وكل ملفات JS التي تكتب فئات. يحتوي `_src/tw.css` على سطر `@import "../assets/app.css";` وسطور `@tailwind` الثلاثة؛ جمّعه في ملف واحد بالأمر `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. أزل سكربت cdn.tailwindcss.com وإعداد tailwind.config المضمّن من الصفحات واربط `/assets/site.css` فقط. أعد التجميع بعد كل تغيير في HTML.
3. استضف الخطوط بنفسك. تحقق أولًا من أن عائلة Fontshare التي تختارها تحتوي الحروف التركية (ş، ğ، ı، İ، ç، ö، ü): في النسخة التجريبية لم يكن في Tanker حرف ı بلا نقطة، ولم يكن في Outfit الحروف ş وğ وİ، فكانت هذه الحروف ستنتقل إلى خط آخر في العناوين. نزّل ملف woff2 لكل وزن على حدة عبر site_fetch إلى `assets/fonts/`، واكتب قواعد @font-face مع `font-display: swap` في `assets/app.css` (يبحث design-check عن الخط المخصص هناك) وتحقق من اسم font-family في ملف CSS الذي نزّلته. حمّل مسبقًا (preload) خطي العناوين والنصوص المستخدمين أعلى الصفحة في كل صفحة بـ `<link rel="preload" as="font" type="font/woff2" crossorigin>`، قبل ورقة الأنماط؛ ولا تحمّل مسبقًا أكثر من ملفين، لأن التحميل المسبق لوزن ثالث في النسخة التجريبية زاد LCP على الجوال بمقدار 0.2 ثانية. معظم خطوط Fontshare تفتقر إلى رمز ₺، لذا اكتب "TL" في الأسعار.
4. اجعل القائمة والتذييل HTML ثابتًا. لا تحمّل chrome.js ولا site.config.js في الصفحات. اكتب ملف `chrome-stamp.mjs` صغيرًا يقرأ قائمة التنقل من site.config.js ويختم `_src/header.tpl` و`_src/footer.tpl` بين العلامتين `` و`` في كل صفحة، مع إضافة aria-current="page" إلى الرابط النشط. يجب ألا تنتهي القوالب بـ .html وأن تستخدم عناصر نائبة مثل `[[NAV]]` بدلًا من `{{...}}`. ابنِ قائمة الجوال بدون JS باستخدام `<details>`. أبقِ اسم المؤسسة والعنوان والهاتف نصًا عاديًا في التذييل، واجعل كل هدف لمس بحجم 44x44 بكسل على الأقل، بما في ذلك روابط التذييل ومسار التنقل (breadcrumb).
5. حوّل الصور أثناء تنزيلها عبر site_fetch: احفظ الصورة نفسها مع resize="480x" و"800x" و"1200x" وimage_format="webp" وquality=65 في ملفات منفصلة. لا يقص site_fetch الصور أبدًا؛ وعندما تحتاج صورة Unsplash إلى نسبة أبعاد أخرى، نزّل النسخة المقصوصة بإضافة معاملات مثل `?w=1600&h=1200&fit=crop` إلى رابطها. أعطِ كل `<img>` السمات srcset وsizes وwidth وheight بما يطابق النسبة الفعلية. تحصل الصورة الرئيسية أعلى الصفحة على fetchpriority="high" ولا تكون lazy؛ وتحصل الصور الأخرى على loading="lazy" decoding="async". إذا ملأت الصورة الرئيسية الشاشة على الجوال، فقدّم نسخة مقصوصة أصغر عبر `<picture>`.
6. اكتب نسخة SVG من الشعار باسم favicon.svg عبر site_write_file وأضف `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` إلى كل صفحة. بدون أيقونة موقع يسجّل المتصفح خطأ 404 وينخفض تقييم أفضل الممارسات إلى 96.
7. قواعد مدقق HTML: ابدأ بـ `<!DOCTYPE html>` بأحرف كبيرة، واستخدم `&nbsp;` للمسافات في النص المرئي لروابط tel:، ولا تستخدم سمة style="" أبدًا، وأعطِ كل زر type="button"، ولا تضع `<details>` داخل `<figure>` بعد figcaption.
8. نزّل مكتبات الحركة (GSAP وScrollTrigger) من jsdelivr إلى `assets/vendor/` عبر site_fetch، وثبّت الإصدار، وحمّلها في الصفحة الرئيسية فقط. لا تستخدم `<script defer>`؛ ضع محمّلًا صغيرًا في نهاية الصفحة ينتظر حدث load ثم استدعاءين لـ requestAnimationFrame ثم requestIdleCallback، ويُلحق السكربتات بالترتيب مع async=false. سكربت من سطر واحد في `<head>` يضيف الفئة `js` إلى `<html>` والفئة `anim` ما لم تكن قيمة prefers-reduced-motion هي "reduce"؛ وبدون `anim` لا ينزّل المحمّل شيئًا. عرّف حالات البداية المخفية تحت `.anim` فقط، وأضف حركة CSS كشبكة أمان تُظهر كل العناصر المخفية بعد 2.5 ثانية في حال لم تصل المكتبة أبدًا. في نسخ تجريبية سابقة، دفعت المكتبات المؤجلة LCP على الجوال إلى 3.2 ثانية؛ ومع هذا المحمّل سجّلت الصفحات من 99 إلى 100. سمِّ السمة الخاصة بالعناصر التي تظهر عند التمرير data-reveal؛ فـ design-check لا يتعرف على الحركة إلا بهذا الاسم.

SEO وAEO وGEO:
1. استخدم عناوين URL بنمط المجلدات مع شرطة مائلة أخيرة (/destek/، /gizlilik/). املأ كتلة seo في site.config.js ونفّذ `node seo-stamp.mjs`. اكتب المخطط الخاص بكل صفحة (الرئيسية: WebPage وMobileApplication (operatingSystem وapplicationCategory ورابطا المتجرين كـ downloadUrl والباقات التي أعطيتك إياها كـ offers بأسعار TRY؛ ولا تضف aggregateRating، لأن تقييم المتجر ليس مراجعة جُمعت على موقعك) وFAQPage؛ الدعم: WebPage وFAQPage؛ الخصوصية: WebPage؛ وBreadcrumbList في الصفحات الداخلية. لشركة برمجيات بلا متجر فعلي، اجعل localBusiness:false في site.config.js) في كتل `<script type="application/ld+json">` منفصلة واربطها بالرسم البياني الأساسي عبر @id. لا تضع BreadcrumbList داخل @graph؛ أبقه في كتلته الخاصة، لأن هذه هي الطريقة الوحيدة التي يراه بها seo-check.
2. أبقِ العناوين عند 60 حرفًا أو أقل (يعدّ seo-check أي عنوان فوق 65 خطأ)، والأوصاف بين 120 و158 حرفًا، وh1 واحدًا لكل صفحة ودون تخطي مستويات العناوين (وجود h3 مباشرة بعد h1 خفّض إمكانية الوصول إلى 98). تحتاج كل صفحة إلى 150 كلمة على الأقل من المحتوى الرئيسي؛ وتميل صفحتا التواصل والخصوصية إلى النقص في ذلك.
3. تجيب الفقرة الأولى في كل صفحة مباشرة عن سؤال الصفحة. اكتب أسئلة شائعة خاصة بكل صفحة بـ `<details>` ووسمها كـ FAQPage. أظهر المؤسسة الناشرة وتاريخ "آخر تحديث" داخل `<time>`.
4. في robots.txt، دوّن وبرّر قرارك بشأن GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot وCCBot، وأشر إلى خريطة الموقع. أعطِ sitemap.xml تواريخ lastmod حقيقية. يحتوي llms.txt على ملخص دقيق للموقع في جملتين، والحقائق الأساسية، وقائمة بالصفحات المهمة.
5. ممنوع الاختلاق: لا تكتب مراجعات أو تقييمات أو جوائز أو أعداد عملاء أو شهادات أو ساعات عمل أو إحداثيات أو أسعارًا دون أن تسألني. اترك أي حقل لا تعرفه خارج المخطط تمامًا.

بوابات الفحص (بالترتيب؛ لا تقل "تم" حتى تنجح كلها):
1. باستخدام site_run_command نفّذ `node chrome-stamp.mjs` وتجميع Tailwind و`node seo-stamp.mjs` و`node seo-check.mjs` (0 أخطاء، 0 تحذيرات) و`node design-check.mjs` (0 أخطاء؛ برّر أي تحذير متبقٍ) و`npx html-validate "**/*.html"` (0 أخطاء).
2. اعرض كل صفحة بـ site_preview مع view="mobile" وview="desktop". يلتقط site_preview الصفحة مع إيقاف الحركة (reduced-motion)؛ فإذا نقص محتوى في تلك اللقطة، فحالة عدم الحركة معطلة. قد تظهر الصور lazy الأبعد في الصفحة فارغة في لقطة الصفحة الكاملة؛ لا تعدّ ذلك خطأ، لكن تحقق من مساراتها.
3. نفّذ core_web_vitals مع strategy="mobile" وstrategy="desktop" لكل صفحة. معيار القبول: على الجوال Performance لا يقل عن 95 وAccessibility وBest Practices وSEO بقيمة 100؛ وعلى سطح المكتب كل الأربعة لا تقل عن 95. للصفحة التي لا تحقق ذلك، اعثر على الملف البطيء بـ resources=true وأصلحه وقِس من جديد. بعد ذلك نفّذ seo_audit على الصفحة الرئيسية مع strategy="mobile" وruns=2. يجب ألا يبقى أي عنوان خارج نطاقك الخاص في قائمة طلبات الشبكة.
4. لا تمرير أفقي عند 360 و390 و768 و1440 بكسل، وأهداف لمس لا تقل عن 44 بكسل، ولا أخطاء في وحدة التحكم (console). ويجب أن يبدو الموقع سليمًا تمامًا أيضًا داخل إطار 390x790 وإطار 1440x898، كما في صفحات الـ prompts.

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

بعد النشر: اعرض معاينة قاعدة `/assets/* Cache-Control: public, max-age=31536000, immutable` عبر site_headers وطبّقها بعد موافقتي؛ ومنذ ذلك الحين أضف رقم إصدار إلى اسم الملف كلما تغيّر CSS أو JS (site-v2.css وهكذا). أرسل sitemap.xml عبر gsc_submit_sitemap وافحص الصفحة الرئيسية عبر gsc_url_inspect. وأخيرًا، سلّمني: جدول نتائج لكل صفحة (الصفحة، أربع نتائج للجوال، أربع نتائج لسطح المكتب، LCP، CLS)، ونتائج بوابات الفحص، ونتيجة التفاعلات التي جرّبتها في المتصفح، وقائمة الإصلاحات التي طبّقتها.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقع تقرير سنوي أو تقرير أثر بأسلوب scrollytelling مع رسوم بيانية تُرسم أثناء التمرير

يحوّل تقريرك السنوي أو تقرير الأثر إلى موقع للقراءة الطويلة: رسوم بيانية خطية بصيغة SVG تُرسم أثناء التمرير، وأرقام تعد تصاعديًا، وتنقل بين الفصول، وملاحظة منهجية، وschema من نوع Report. تظهر الأرقام والرسوم بالكامل دون JavaScript، ولكل رسم بياني جدول بيانات، ويُقاس Lighthouse على الجوال ويُحافظ عليه فوق 95.

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

على خادم استضافة Opus Growth الخاص بي [اسم الخادم]، أنشئ تقرير الأثر لعام [السنة] الخاص بـ [اسم المنظمة] كموقع يروي قصته أثناء التمرير. المنظمة: [ما تفعله، ومكانها، وسنة التأسيس]. الرسالة الرئيسية للتقرير: [جملة واحدة]. الأرقام الرئيسية الأربعة: [الرقم، الوحدة، شرح في جملة واحدة]. بيانات الرسوم البيانية: [لكل رسم بياني: العنوان والفترات والقيم]. الميزانية: [مصادر الدخل وبنود المصروفات، والمبالغ والنسب]. الفصول: [أسماء الفصول والنص أو الملاحظات الخاصة بكل فصل]. خطة العام القادم: [البنود]. مصدر الأرقام وحدودها: [أي السجلات استُخدمت، وكيف عولجت البيانات الناقصة]. إعداد ونشر: [اسم المحرر، التاريخ]. للتواصل: [البريد الإلكتروني]، [الهاتف]، [العنوان]. النطاق: [النطاق]. الصور: [الروابط؛ دون وجوه الأطفال أو المستفيدين].

الصفحات: التقرير (/: عنوان الغلاف، فقرة ملخص تبدأ بالإجابة، المؤلف والتاريخ، صورة الغلاف، تنقل ثابت بين الفصول، ثم بالترتيب: ملخص العام، الفصول، الميزانية، خطة العام القادم، والأسئلة حول التقرير)، المنهجية (/yontem/: مصدر كل رقم وحدوده)، المنظمة والتواصل (/dernek/ أو اسم يناسب منظمتك)، الخصوصية وKVKK (/gizlilik/) و404.html. اكتب الرسوم البيانية كـ SVG ثابت يُولَّد من القيم التي قدمتها، دون Chart.js أو D3؛ لا تقرّب القيم وتحقق من أن المجاميع صحيحة. اعرض الميزانية كـ `<table>` دون أي حد أدنى للعرض، لا كرسم بياني.

الأسلوب: قراءة طويلة تشبه قصة بيانات في صحيفة. خلفية بلون الورق، وخط سيريف من Fontshare للعناوين (مثل Bespoke Serif)، وخط نصوص مقروء يدعم tabular-nums (مثل Epilogue)، مع لونين على الأكثر للرسوم البيانية. على سطح المكتب قائمة فصول ثابتة بعرض 220 px على اليسار؛ وعلى الهاتف شريط فصول قابل للتمرير أفقيًا يثبت في الأعلى، وتحته خط رفيع لتقدم القراءة.

قواعد الحركة (أصعب جزء، التزم بها حرفيًا):
1. المكتبات: نواة GSAP 3.13 وScrollTrigger فقط، وفي صفحة التقرير فقط. لا يُحمَّل Lenis، لأن التمرير الأصلي أكثر راحة للقراءة الطويلة؛ ولا تُحمَّل SplitText ولا مكتبات الرسوم البيانية. لا أي سكربتات في صفحات المنهجية والمنظمة والخصوصية.
2. الرسوم الخطية: كل خط هو `<path pathLength="1">` ويكون مرسومًا بالكامل في HTML. يضبط JS القيمتين strokeDasharray 1 وstrokeDashoffset 1 فقط على الرسوم الواقعة أسفل الشاشة عند التحميل، ويُنزل الإزاحة إلى 0 عبر ScrollTrigger scrub (start "top 75%" وend "bottom 65%")؛ وتظهر نقاط البيانات تباعًا مع مرور الخط بها. اجعل نص SVG بحجم 22 وحدة على الأقل في viewBox بعرض 600 وحدة ليبقى فوق 12 px على الهواتف، واترك 40 وحدة على الأقل إلى اليمين كي لا تُقتطع آخر تسمية للمحور.
3. كل رسم بياني هو `<svg role="img" aria-labelledby>` مع title وdesc يذكر جميع القيم في جملة؛ ويعرض figcaption المصدر ويرتبط بملاحظة المنهجية، وبعد الـ figure مباشرة يحتوي عنصر `<details>` بتسمية "عرض البيانات كجدول" على `<table>` حقيقي. هذا الجدول هو النسخة النصية من البيانات لإمكانية الوصول وللبحث بالذكاء الاصطناعي معًا.
4. العدّادات: تُكتب القيمة النهائية في HTML بالصيغة التركية (مثل 31.540). يوضع الرقم المرئي في span بسمة aria-hidden، وتوضع القيمة نفسها في span بصنف sr-only لقارئات الشاشة. يعيد JS إلى الصفر فقط العدّادات الواقعة أسفل الشاشة عند التحميل، ويعدّها تصاعديًا باستخدام Intl.NumberFormat("tr-TR") عند دخولها الشاشة؛ ولا تُرجع أبدًا رقمًا ظاهرًا بالفعل إلى الصفر. طبّق tabular-nums على الرقم وحدًا أدنى للعرض يساوي عدد أحرف القيمة النهائية (بصنف Tailwind، لا بسمة style) كي لا يتحرك السطر أثناء العد.
5. التنقل بين الفصول: الروابط عبارة عن مراسي تعمل دون JS. يستخدم JS ‏ScrollTrigger لكل فصل لتحديد الفصل النشط، ويضبط aria-current="true" على رابطه، ويمرر شريط الهاتف أفقيًا ليظهر الرابط النشط (الشريط لا الصفحة). ضع خاصية الثبات على الشريط الجانبي (aside) الذي هو ابن مباشر للشبكة الممتدة على كامل التقرير، لا على nav الداخلي؛ ففي النسخة التجريبية لم يثبت sticky على nav الداخلي في الهواتف قط.
6. لا حركة أخرى سوى خط تقدم القراءة والصور التي تظهر بسمة data-reveal.

الإعداد والفخاخ المعروفة (كل واحد منها كلّف نقاطًا أو كسر شيئًا في قياس النسخة التجريبية، فلا تتجاوز أيًّا منها):
1. إذا كان هناك موقع يعمل بالفعل على الخادم فأخبرني أولًا، لأن الإعداد يستبدل index.html ومجلد assets. اعرض معاينة scaffold_site مع confirm=false، ثم استدعِ confirm=true بعد موافقتي. بعد ذلك اقرأ site_design_guide وsite_seo_guide. قبل كتابة الكود، ضع اتجاه التصميم (الطباعة، اللون، الشبكة، العنصر المميز، لغة الحركة، والمكتبات التي لن تُحمَّل) في ملف ART.md قصير خارج assets واعرضه عليّ.
2. قم بتجميع Tailwind ولا تحمّله من CDN. ثبّت `npm i -D tailwindcss@3` عبر site_run_command مع background=true وراقبه بـ site_command_status. يجب أن تغطي مسارات content في `tailwind.config.js` كل ملفات HTML وكل القوالب وكل ملفات JS التي تكتب أصنافًا. يحتوي `_src/tw.css` على سطر `@import "../assets/app.css";` وأسطر `@tailwind` الثلاثة؛ جمّعه في ملف واحد بالأمر `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. أزل سكربت cdn.tailwindcss.com وإعداد tailwind.config المضمّن من الصفحات واربط `/assets/site.css` فقط. أعد التجميع بعد كل تعديل على HTML.
3. استضف الخطوط بنفسك. تحقق أولًا من أن عائلة Fontshare التي تختارها تحتوي على الحروف التركية (ş, ğ, ı, İ, ç, ö, ü): في النسخة التجريبية لم يكن في Tanker حرف ı دون نقطة ولم يكن في Outfit حروف ş وğ وİ، فكانت هذه الحروف ستنتقل إلى خط آخر في العناوين. نزّل ملف woff2 لكل وزن على حدة عبر site_fetch إلى `assets/fonts/`، واكتب قواعد @font-face مع `font-display: swap` في `assets/app.css` (يبحث design-check عن الخط المخصص هناك) وتحقق من اسم font-family في ملف CSS الذي نزّلته. نفّذ preload لخطي العناوين والنصوص المستخدمين أعلى الصفحة في كل الصفحات بالوسم `<link rel="preload" as="font" type="font/woff2" crossorigin>` قبل ورقة الأنماط؛ ولا تُجرِ preload لأكثر من ملفين، لأن preload لوزن ثالث في النسخة التجريبية زاد LCP على الهاتف بمقدار 0.2 ثانية. معظم خطوط Fontshare تفتقر إلى رمز ₺، لذا اكتب "TL" في الأسعار.
4. اجعل القائمة والتذييل HTML ثابتًا. لا تحمّل chrome.js ولا site.config.js في الصفحات. اكتب `chrome-stamp.mjs` صغيرًا يقرأ قائمة التنقل من site.config.js ويختم `_src/header.tpl` و`_src/footer.tpl` بين العلامتين `` و`` في كل صفحة، مضيفًا aria-current="page" إلى الرابط النشط. يجب ألا تنتهي القوالب بـ .html، وأن تستخدم عناصر نائبة مثل `[[NAV]]` بدل `{{...}}`. ابنِ قائمة الهاتف دون JS باستخدام `<details>`. أبقِ اسم المنظمة والعنوان والهاتف كنص عادي في التذييل، واجعل كل هدف لمس بحجم 44x44 px على الأقل، بما في ذلك روابط التذييل وفتات التنقل.
5. حوّل الصور أثناء تنزيلها بـ site_fetch: احفظ الصورة نفسها بـ resize="480x" و"800x" و"1200x" مع image_format="webp" وquality=65 في ملفات منفصلة. لا يقتطع site_fetch الصور أبدًا؛ فإذا احتاجت صورة Unsplash إلى نسبة أبعاد أخرى، فنزّل النسخة المقتطعة بإضافة معلمات مثل `?w=1600&h=1200&fit=crop` إلى عنوانها. أعطِ كل `<img>` قيم srcset وsizes وwidth وheight تطابق النسبة الحقيقية. تحصل الصورة الرئيسية أعلى الصفحة على fetchpriority="high" ولا تكون lazy؛ وتحصل البقية على loading="lazy" decoding="async". إذا كانت الصورة الرئيسية تملأ الشاشة على الهاتف، فقدّم اقتطاعًا أصغر عبر `<picture>`.
6. اكتب نسخة SVG من الشعار باسم favicon.svg عبر site_write_file وأضف `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` إلى كل صفحة. دون أيقونة favicon يسجّل المتصفح خطأ 404 وينخفض تقييم Best Practices إلى 96.
7. قواعد مدقق HTML: ابدأ بـ `<!DOCTYPE html>` بأحرف كبيرة، واستخدم `&nbsp;` للمسافات في النص المرئي لروابط tel:، ولا تستخدم سمة style="" أبدًا، وأعطِ كل زر type="button"، ولا تضع `<details>` داخل `<figure>` بعد figcaption.
8. نزّل مكتبات الحركة (GSAP وScrollTrigger) من jsdelivr إلى `assets/vendor/` عبر site_fetch، وثبّت الإصدار، وحمّلها في صفحة التقرير فقط. لا تستخدم `<script defer>`؛ بل ضع محمّلًا صغيرًا في نهاية الصفحة ينتظر حدث load ثم استدعاءين لـ requestAnimationFrame ثم requestIdleCallback، ويُلحق السكربتات بالترتيب مع async=false. يضيف سكربت من سطر واحد في `<head>` الصنف `js` إلى `<html>` والصنف `anim` ما لم تكن قيمة prefers-reduced-motion هي "reduce"؛ ودون `anim` لا ينزّل المحمّل شيئًا. عرّف حالات البداية المخفية تحت `.anim` فقط، وأضف حركة CSS كشبكة أمان تُظهر كل العناصر المخفية بعد 2.5 ثانية في حال لم تصل المكتبة أبدًا. في نسخ تجريبية سابقة دفعت المكتبات المؤجلة LCP على الهاتف إلى 3.2 ثانية؛ ومع هذا المحمّل سجلت الصفحات من 99 إلى 100. سمِّ السمة الخاصة بالعناصر التي تظهر عند التمرير data-reveal؛ فـ design-check لا يتعرف على الحركة إلا بهذا الاسم.

SEO وAEO وGEO:
1. استخدم عناوين URL بنمط المجلدات مع شرطة مائلة أخيرة (/yontem/ و/dernek/ و/gizlilik/). املأ كتلة seo في site.config.js ونفّذ `node seo-stamp.mjs`. اكتب مخطط schema الخاص بكل صفحة (صفحة التقرير: WebPage مع Report كـ mainEntity، تتضمن headline وdatePublished وdateModified وimage وauthor (Person، أي المحرر) وpublisher، إضافة إلى FAQPage؛ المنهجية: Article؛ صفحة المنظمة: AboutPage مع نوع فرعي يناسب المنظمة (مثل NGO)؛ وBreadcrumbList في الصفحات الداخلية. إذا لم يكن هناك مكتب يزوره الناس فاضبط localBusiness:false في site.config.js) في كتل `<script type="application/ld+json">` منفصلة واربطها بالرسم البياني الأساسي عبر @id. لا تضع BreadcrumbList داخل @graph؛ أبقه في كتلته الخاصة، لأن هذه هي الطريقة الوحيدة التي يراه بها seo-check.
2. أبقِ العناوين عند 60 حرفًا أو أقل (يعدّ seo-check أي عنوان فوق 65 خطأ)، والأوصاف بين 120 و158 حرفًا، وh1 واحدًا في كل صفحة، ودون تخطي أي مستوى من العناوين (h3 مباشرة بعد h1 خفّض إمكانية الوصول إلى 98). تحتاج كل صفحة إلى 150 كلمة على الأقل من المحتوى الرئيسي؛ وتميل صفحتا التواصل والخصوصية إلى النقص في ذلك.
3. الفقرة الأولى في كل صفحة تجيب مباشرة عن سؤال الصفحة. اكتب أسئلة شائعة خاصة بكل صفحة باستخدام `<details>` ووسّمها كـ FAQPage. اعرض المنظمة الناشرة وتاريخ "آخر تحديث" داخل `<time>`.
4. في robots.txt، دوّن قرارك وبرّره لكل من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot وCCBot، وأشر إلى خريطة الموقع. ضع في sitemap.xml تواريخ lastmod حقيقية. يحتوي llms.txt على ملخص دقيق للموقع في جملتين، والحقائق الأساسية، وقائمة بالصفحات المهمة.
5. لا اختلاق: لا تكتب مراجعات أو تقييمات أو جوائز أو أعداد عملاء أو شهادات أو ساعات عمل أو إحداثيات أو أسعارًا دون أن تسألني. اترك أي حقل لا تعرفه خارج schema تمامًا.

بوابات الفحص (بالترتيب؛ لا تقل "تم" حتى تنجح جميعها):
1. عبر site_run_command نفّذ `node chrome-stamp.mjs` وبناء Tailwind و`node seo-stamp.mjs` و`node seo-check.mjs` (0 أخطاء، 0 تحذيرات) و`node design-check.mjs` (0 أخطاء؛ وبرّر أي تحذير متبقٍ) و`npx html-validate "**/*.html"` (0 أخطاء).
2. اعرض كل صفحة بـ site_preview مع view="mobile" وview="desktop". يلتقط site_preview الصفحة مع إيقاف الحركة (reduced-motion)؛ فإذا نقص محتوى في هذه اللقطة فحالة عدم الحركة معطوبة. قد تظهر الصور lazy الواقعة في الأسفل فارغة في لقطة الصفحة الكاملة؛ لا تعدّ ذلك خطأ، لكن تحقق من مساراتها.
3. نفّذ core_web_vitals مع strategy="mobile" وstrategy="desktop" لكل صفحة. معيار القبول: على الهاتف يكون Performance عند 95 على الأقل وتكون Accessibility وBest Practices وSEO عند 100؛ وعلى سطح المكتب تكون النتائج الأربع كلها 95 على الأقل. وللصفحة التي لا تحقق ذلك، حدد الملف البطيء عبر resources=true وأصلحه وأعد القياس. ثم نفّذ seo_audit على الصفحة الرئيسية مع strategy="mobile" وruns=2. يجب ألا يبقى أي عنوان خارج نطاقك الخاص في قائمة طلبات الشبكة.
4. لا تمرير أفقي عند 360 و390 و768 و1440 px، وأهداف لمس بحجم 44 px على الأقل، ولا أخطاء في وحدة التحكم. ويجب أن يبدو الموقع سليمًا تمامًا داخل إطار 390x790 وإطار 1440x898 كما في صفحات المطالبات.

فحص الحركة: لا يستطيع site_preview عرض الحركة، لذا أخبرني بما يجب أن أراقبه في متصفحي. على سطح المكتب يجب أن تعدّ العدّادات من الصفر إلى القيمة النهائية عند ظهورها، وأن تُرسم خطوط الرسوم من اليسار إلى اليمين أثناء التمرير مع ظهور النقاط تباعًا، وأن تُظهر قائمة الفصول على اليسار الفصل الذي تقرؤه. وعلى الهاتف يجب أن يبقى شريط الفصول ثابتًا في الأعلى وأن يمرر الفصل النشط إلى المجال المرئي. ومع تفعيل تقليل الحركة ومع إيقاف JavaScript، يعرض كل رقم قيمته النهائية ويظهر كل رسم بياني مرسومًا بالكامل، ويمكن فتح جداول البيانات.

بعد النشر: عاين قاعدة `/assets/* Cache-Control: public, max-age=31536000, immutable` عبر site_headers وطبّقها بعد موافقتي؛ ومن ثم غيّر رقم إصدار اسم الملف كلما تغيّر CSS أو JS (site-v2.css وهكذا). أرسل sitemap.xml عبر gsc_submit_sitemap وافحص الصفحة الرئيسية بـ gsc_url_inspect. وفي النهاية زوّدني بـ: جدول نتائج لكل صفحة (الصفحة، النتائج الأربع على الهاتف، النتائج الأربع على سطح المكتب، LCP، CLS)، ونتائج بوابات الفحص، ونتيجة التفاعلات التي جرّبتها في متصفح، وقائمة الإصلاحات التي طبّقتها.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقع مؤتمر بجدول زمني بتبويبات الأيام ونوافذ منبثقة للمتحدثين وعدّ تنازلي يبقى صحيحًا بدون JavaScript

ينشئ موقعًا بأسلوب الملصق لمؤتمرك أو فعاليتك على خادم الاستضافة: جدول زمني بتبويبات الأيام، وشبكة متحدثين تُفتح سيرهم الذاتية في نافذة منبثقة، وعدّ تنازلي يعرض التاريخ الصحيح حتى مع تعطيل JavaScript، وشريط تذاكر ثابت على الجوال، وschema من نوع Event مع العروض والموقع. لا تُحمَّل أي مكتبة، ويُوفَّر ملف تقويم، وتُقاس كل صفحة.

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

على موقع [اسم الخادم] في خادم استضافة Opus Growth الخاص بي، أنشئ موقعًا ثابتًا وسريعًا للفعالية [اسم الحدث]. الفعالية: [ما هو، ولمن هو، وأي إصدار، في جملتين]. التاريخ والوقت: [البدء والانتهاء، المنطقة الزمنية]. المكان: [اسم المكان، العنوان الكامل، المواصلات، مواقف السيارات، تسهيلات ذوي الاحتياجات الخاصة]. الجدول: [لكل يوم، الوقت وعنوان الجلسة والمتحدث والقاعة]. المتحدثون: [الاسم، المسمى الوظيفي، المؤسسة، عنوان الجلسة، نبذة تعريفية، رابط الصورة والإذن بنشرها]. التذاكر: [ticket types, prices, whether VAT is included, valid dates, the link on the ticketing platform, refund and transfer terms]. المنظّم: [اسم المؤسسة]، [البريد الإلكتروني]، [الهاتف]. سياسة التسجيل والتصوير: [هل تُسجَّل المحاضرات وهل تُلتقط الصور]. النطاق: [النطاق].

الصفحات: الرئيسية (سطر للتاريخ والمكان، عدّاد تنازلي، مقدمة قصيرة، ما الذي سيحدث، أربعة من المتحدثين، ملخص عن المكان، الأسئلة الشائعة)، الجدول (/program/: تبويبات الأيام وملف تقويم .ics)، المتحدثون (/konusmacilar/)، التذاكر (/bilet/: أنواع التذاكر، ما الذي تشمله، الاسترداد، أسئلة شائعة عن الفاتورة)، المكان (/mekan/: العنوان، المواصلات، تسهيلات الوصول، الإقامة)، الخصوصية (/gizlilik/، بما في ذلك خيار التصوير والتسجيل) و404.html.

الأسلوب: ملصق مؤتمر. إذا لم يُحدَّد [تفضيل اللون]، فاستخدم شريط hero بالأصفر الفسفوري، وخلفية كريمية، ونصًا أسود، وحدودًا سوداء بسماكة 2 بكسل. خط عريض وغليظ من Fontshare بأحرف كبيرة للعناوين (مثل Panchang 700) وخط sans مدوَّر للنص الأساسي (مثل Chillax 400 و500)؛ نفّذ preload لملفات الخطوط الثلاثة الخاصة بالشاشة الأولى. تحتاج الأحرف الكبيرة إلى `<html lang="tr">`، وإلا يتحول "i" إلى "I". إذا لم تكن لدى متحدث صورة أو لم يوافق على نشرها، فاستخدم شعارًا بالأحرف الأولى من اسمه؛ ولا تستخدم أبدًا صورة شخص آخر.

قواعد التفاعل (دون أي مكتبة، وملف `ix.js` واحد مع defer، في صفحات الرئيسية والجدول والمتحدثين فقط):
1. يكون العدّاد التنازلي صحيحًا حتى مع تعطيل JS: يحتوي HTML على النص "Starts: <time datetime="2027-05-13T09:00:00+03:00">Thursday 13 May 2027, 09.00</time> (Turkey time)" داخل صندوق ثابت الارتفاع. يقرأ JS التواريخ بصيغة ISO مع فرق المنطقة الزمنية من data-start وdata-end باستخدام Date.parse ويكتب صناديق اليوم والساعة والدقيقة داخل الصندوق نفسه. يجب أن يكون للصندوق الارتفاع نفسه في الحالتين (min-height في CSS وارتفاع ثابت للوحدة)، وإلا تتحرك الشاشة الأولى. لا تعرض الثواني؛ حدّث كل دقيقة وتوقف أثناء إخفاء التبويب. تكون صناديق الأرقام بخاصية aria-hidden مع جملة واحدة مخفية بصريًا لقارئات الشاشة بجانبها، ودون منطقة حيّة (aria-live) لأنها ستُقرأ كل دقيقة. عند بدء الفعالية اكتب "happening now"، وبعد انتهائها اكتب "has ended"؛ ولا تعرض أبدًا أرقامًا سالبة لتاريخ مضى.
2. تبويبات الأيام: في HTML يكون كل يوم قسمًا منفصلًا بعنوانه الخاص (id="gun-1" و"gun-2") مع روابط إلى هذه الأقسام فوقها؛ ومع تعطيل JS تُعرض كل الأيام الواحد تلو الآخر. تحمل الحاوية المحيطة بالروابط role="group" وaria-label. يحوّلها JS إلى تبويبات ARIA (tablist وtab وtabpanel وaria-selected وtabindex ومفاتيح الأسهم وHome وEnd)، ويحدد اليوم الثاني عند فتح الصفحة بالرابط #gun-2، ويحدّث عنوان URL باستخدام history.replaceState عند تغيّر التبويب ليمكن مشاركة يوم معيّن كرابط. كل جلسة صف في قائمة مع `<time datetime>`: الوقت، والعنوان، ورابط إلى مرساة المتحدث في صفحة المتحدثين، والقاعة؛ وتكون للاستراحات خلفية منفصلة.
3. السيرة الذاتية للمتحدث: في HTML توجد داخل `<details>` في كل بطاقة، فتكون مقروءة مع تعطيل JS ولمحركات البحث. يعترض JS النقر على summary، وينشئ `<dialog>` واحدًا، وينسخ إليه الاسم والمسمى الوظيفي وعنوان المحاضرة والسيرة الذاتية باستخدام textContent، ويفتحه بـ showModal وينقل التركيز إلى زر "Close"؛ ويغلقه Esc والنقر على الخلفية، ويعود التركيز إلى summary. أضف aria-haspopup="dialog" إلى summary. معرّف كل بطاقة هو slug المتحدث، وإليه تشير روابط الجدول.
4. زر ثابت لدعوة شراء التذاكر: زر "Get tickets" في الترويسة على الحاسوب، وعلى الجوال شريط مثبّت أسفل الشاشة (التاريخ وأقل سعر و"Get tickets"). الشريط HTML ثابت في قالب التذييل ويكون position: fixed منذ أول رسم؛ فإضافته لاحقًا بـ JS تسبب إزاحة في التخطيط. على الجوال، أعطِ body حشوة سفلية تساوي ارتفاع الشريط حتى لا تختفي آخر الروابط تحته، وأضف `env(safe-area-inset-bottom)`، وأخفِ الشريط في صفحة التذاكر عبر class على body.
5. ملف التقويم: `/assets/[الحدث].ics` يُنزَّل من صفحة الجدول (VCALENDAR مع VEVENT واحد، وDTSTART وDTEND بتوقيت UTC، وSUMMARY وLOCATION وURL، ونهايات أسطر CRLF). أضف إلى الرابط الخاصية download.

المخطط (Schema): الحدث Event نفسه (@id /#event) في صفحات الرئيسية والجدول والتذاكر: name وdescription وstartDate وendDate مع فرق المنطقة الزمنية، وeventStatus بالقيمة EventScheduled، وeventAttendanceMode بالقيمة OfflineEventAttendanceMode، وlocation على شكل Place مع PostalAddress كامل، وثلاث صور بنسب 1x1 و4x3 و16x9، وorganizer، والمتحدثين بصفة performer، ومصفوفة offers (لكل نوع تذكرة: name وprice وpriceCurrency "TRY" وavailability وvalidFrom وvalidThrough للحجز المبكر، وصفحة البيع بصفتها url). تشترط نتيجة Google المنسّقة للأحداث وجود location وstartDate ولا تدمج @id بين الصفحات، لذا اكتب Event كاملًا في كل صفحة تستخدمه؛ وفي صفحة الجدول أضف كل جلسة أيضًا بصفتها subEvent. إذا تأجلت الفعالية أو أُلغيت، فاضبط eventStatus على EventPostponed أو EventCancelled بدلًا من حذف الصفحة. Place في صفحة المكان وBreadcrumbList في كل صفحة داخلية. لا تكتب الرعاة أو أعداد الحضور أو "نفدت التذاكر" إلا إذا كانت صحيحة.

الإعداد والمزالق المعروفة (كلٌّ منها كلّف نقاطًا في قياسات العرض التجريبي، فلا تتجاوز أيًّا منها):
1. إذا كان هناك موقع يعمل بالفعل على الخادم، فأخبرني أولًا، لأن الإعداد يستبدل index.html ومجلد assets. اعرض معاينة scaffold_site مع confirm=false، ولا تستدعه مع confirm=true إلا بعد موافقتي. ثم اقرأ site_design_guide وsite_seo_guide. قبل كتابة الشيفرة، ضع اتجاه التصميم (الخطوط والألوان والشبكة والعنصر المميز ولغة الحركة والمكتبات التي لن تُحمَّل) في ملف ART.md قصير خارج assets واعرضه عليّ.
2. اجعل Tailwind مُصرَّفًا ولا تحمّله من CDN. ثبّته باستخدام site_run_command مع background=true (`npm i -D tailwindcss@3`) وتابعه بـ site_command_status. يجب أن تغطي مسارات content في `tailwind.config.js` كل ملفات HTML وقوالب `_src` وأي ملف JS يكتب classes. يحتوي `_src/tw.css` على السطر `@import "../assets/app.css";` مع أسطر `@tailwind` الثلاثة؛ صرِّفه في ملف واحد بالأمر `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. احذف سكربت cdn.tailwindcss.com وإعداد tailwind.config المضمَّن من كل صفحة واربط `/assets/site.css` فقط. أعد التصريف بعد كل تغيير في HTML.
3. استضف الخطوط بنفسك. اقرأ CSS لعائلة Fontshare التي اخترتها، ونزّل woff2 لكل وزن على حدة باستخدام site_fetch إلى `assets/fonts/`، واكتب قواعد @font-face مع `font-display: swap` في `assets/app.css`، وهو المكان الذي يبحث فيه design-check عن الخط المخصص. تحقق من اسم font-family في CSS المنزَّل وتأكد من أن العائلة تتضمن الأحرف التركية ı وİ وş وğ (خط Tanker لا يحتوي ı). نفّذ preload لكل الأوزان المستخدمة في الشاشة الأولى بـ `<link rel="preload" as="font" type="font/woff2" crossorigin>`، ويوضع قبل سطر ورقة الأنماط؛ وإذا زادت عن ثلاثة ملفات فاستخدم أوزانًا أقل. في العرض التجريبي، أدى وزن واحد للنص الأساسي دون preload إلى رفع LCP على الجوال إلى 2.6 ثانية وخفض Performance إلى 97. تفتقر معظم خطوط Fontshare إلى رمز ₺، لذا اكتب الأسعار بـ "TL".
4. اجعل القائمة والتذييل HTML ثابتًا. لا تحمّل chrome.js أو motion.js أو site.config.js في الصفحات. اكتب `chrome-stamp.mjs` صغيرًا يقرأ قائمة التنقل من site.config.js ويطبعها في `_src/header.tpl` و`_src/footer.tpl` بين العلامتين `` و`` في كل صفحة، مع إضافة aria-current="page" إلى الرابط النشط. استخدم عناصر نائبة مثل `[[NAV]]` بدلًا من `{{...}}` ولا تمنح القوالب امتداد .html، وإلا عاملها design-check وseo-check كصفحات غير مكتملة. ابنِ قائمة الجوال بـ `<details>` دون JS. أبقِ اسم النشاط والعنوان والهاتف نصًا عاديًا في التذييل، واجعل روابط التذييل وفتات التنقل بارتفاع 44 بكسل على الأقل.
5. حوّل الصور أثناء جلبها بـ site_fetch: اكتب الصورة نفسها في ملفات منفصلة مع resize="480x" و"800x" و"1200x" وimage_format="webp" وquality=60 (لا يقتصّ site_fetch الصور، فاطلب المصدر بالنسبة التي تحتاجها). أعطِ كل `<img>` الخصائص srcset وsizes وwidth وheight بما يتطابق مع النسبة الحقيقية. الصورة التي تمثل عنصر LCP في الصفحة تحصل على fetchpriority="high" ولا تكون lazy؛ وكل صورة أخرى تحصل على loading="lazy" decoding="async". إذا ملأت صورة شاشة الجوال الأولى، فقدّم للجوال اقتصاصًا أصغر باستخدام `<picture>`.
6. أضف `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` إلى كل صفحة وأنشئ apple-touch-icon بحجم 180 بكسل من الشعار باستخدام site_fetch مع resize="180x180". من دون رابط favicon يطلب المتصفح /favicon.ico ويسجّل خطأ 404 وينخفض Best Practices إلى 96.
7. قواعد مدقّق HTML: ابدأ كل مستند بـ `<!DOCTYPE html>` بأحرف كبيرة؛ كل مسافة في النص المرئي لرابط tel: يجب أن تكون `&nbsp;`، بما فيها المسافة بعد بادئة مثل "Call:&nbsp;0212..."؛ لا تستخدم style=""؛ أعطِ كل زر type؛ ضع aria-label على المعالم (landmarks) أو النماذج أو العناصر التفاعلية فقط (على ul أو div بلا role كان خطأ)؛ لا تمنح معلمين الاسم نفسه أبدًا؛ ولا تترك مسافات زائدة في نهايات الأسطر.
8. لا تتخطَّ مستويات العناوين: في صفحة قائمة، أدت عناوين البطاقات بصيغة h3 مباشرة بعد h1 إلى خفض Accessibility إلى 98. عند إعادة استخدام بطاقة، اضبط مستوى عنوانها لكل صفحة (h2 في صفحة قائمة، وh3 داخل قسم h2).
9. سمِّ خاصية الحركة data-reveal (لا يتعرف design-check على الحركة إلا بهذا الاسم). يمنح JS الحالة الابتدائية المخفية فقط للكتل الموجودة أسفل الشاشة عند فتح الصفحة، ولا يخفي أبدًا محتوى الشاشة الأولى؛ استخدم transform لأن التلاشي بـ opacity يخفض تدقيق التباين. ضع الخاصية على الكتلة التي تحيط بالعنوان ووصفه، لا على العنوان وحده؛ ففي العرض التجريبي انزلق عنوان في وضع الانتظار فوق الفقرة التي تحته. مع prefers-reduced-motion: reduce لا يُخفى شيء وتُعطَّل الحركات.

SEO وAEO وGEO:
1. استخدم عناوين URL بنمط المجلدات مع شرطة مائلة في النهاية. املأ كتلة seo في site.config.js ونفّذ `node seo-stamp.mjs`. اكتب مخطط (schema) كل صفحة في كتل `<script type="application/ld+json">` منفصلة مرتبطة بالرسم الأساسي عبر @id. لا تضع BreadcrumbList داخل @graph؛ أبقِه في كتلته الخاصة، فهذه هي الطريقة الوحيدة التي يراه بها seo-check.
2. العناوين 60 حرفًا كحد أقصى (يعدّ seo-check أي عنوان أقل من 25 أو أكثر من 65 خطأ)، والأوصاف من 130 إلى 158 حرفًا، وh1 واحد لكل صفحة، و150 كلمة على الأقل من المحتوى الرئيسي في كل صفحة. تميل صفحات الاتصال والخصوصية والقوائم إلى القصر؛ أضف معلومات خاصة بالصفحة لا حشوًا.
3. تجيب الفقرة الأولى في كل صفحة مباشرة عن سؤال الصفحة. اكتب أسئلة شائعة خاصة بكل صفحة باستخدام `<details>` ووسمها بـ FAQPage. أظهر الناشر (publisher) وتاريخ "Last updated" داخل عنصر `<time>`.
4. في robots.txt، اكتب قرارك مع السبب لكل من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot وCCBot، وأشِر إلى خريطة الموقع. يحمل sitemap.xml تواريخ lastmod حقيقية. يحتوي llms.txt على ملخص دقيق للموقع في جملتين وقائمة بالصفحات المهمة.
5. لا اختلاق: لا تكتب مراجعات أو تقييمات أو جوائز أو أعداد عملاء أو شهادات أو ساعات عمل أو إحداثيات أو أسعارًا دون أن تسألني. اترك أي حقل لا تعرفه خارج المخطط (schema) تمامًا.

البوابات (بالترتيب؛ لا تقل "تم" حتى تنجح جميعها):
1. باستخدام site_run_command نفّذ `node chrome-stamp.mjs` وبناء Tailwind و`node seo-stamp.mjs` و`node seo-check.mjs` (0 أخطاء، 0 تحذيرات) و`node design-check.mjs` (0 أخطاء؛ وبرّر أي تحذير متبقٍّ) و`npx html-validate "**/*.html"` (0 أخطاء).
2. اعرض كل صفحة باستخدام site_preview مع view="mobile" وview="desktop". يلتقط site_preview الصفحة مع تعطيل الحركة (reduced-motion)؛ فإذا غاب محتوى في تلك اللقطة، فالحالة الثابتة معطوبة. في لقطات الصفحة الكاملة قد تظهر العناصر الثابتة مثل الشريط المثبّت في منتصف الصفحة وقد تكون الصور الكسولة في الأسفل فارغة؛ لا تحتسب ذلك أخطاء، لكن تحقق من مساراتها.
3. نفّذ core_web_vitals لكل صفحة مع strategy="mobile" وstrategy="desktop". معيار القبول: على الجوال Performance لا يقل عن 95 (الهدف من 99 إلى 100) وAccessibility وBest Practices وSEO بقيمة 100؛ وعلى الحاسوب كل الأربعة بقيمة 100. للصفحة التي لا تحقق ذلك، استخدم resources=true لإيجاد الملف الذي يعطّلها، وأصلحه ثم قِس مجددًا. ثم نفّذ seo_audit على الصفحة الرئيسية مع strategy="mobile" وruns=2. يجب ألا يبقى أي عنوان خارج نطاقك الخاص في قائمة طلبات الشبكة.
4. لا تمرير أفقي عند عرض 360 و390 و768 و1440 بكسل، وأهداف اللمس 44 بكسل على الأقل، ولا أخطاء في وحدة التحكم (console).

فحص التفاعل: لا يستطيع site_preview عرض الوقت أو التبويبات أو الحوارات. أخبرني كيف أتحقق من أن العدّاد التنازلي يعرض التاريخ الصحيح مع تعطيل JavaScript ويتحول إلى صناديق بالارتفاع نفسه مع تفعيل JS، وأن /program/#gun-2 يفتح اليوم الثاني وأن التبويبات تتبدل بمفاتيح الأسهم، وأن السيرة الذاتية للمتحدث تُفتح في نافذة منبثقة ويعود التركيز بعد Esc، وأن شريط التذاكر على الهاتف لا يغطي آخر روابط الصفحة، وأن ملف التقويم يصل إلى تقويم الهاتف في الوقت الصحيح، وأن اختبار Rich Results Test من Google يعرض Event دون أخطاء.

بعد النشر: عاين القاعدة `/assets/* Cache-Control: public, max-age=31536000, immutable` باستخدام site_headers وطبّقها بعد موافقتي؛ ومن ثم فقم بتحديث إصدار اسم الملف كلما تغيّر CSS أو JS (site-v2.css وهكذا). أرسل sitemap.xml باستخدام gsc_submit_sitemap وافحص الصفحة الرئيسية بـ gsc_url_inspect. في النهاية أعطني: جدول نتائج لكل صفحة (الصفحة، أربع نتائج للجوال، أربع للحاسوب، LCP، CLS)، ونتيجة كل بوابة، وقائمة الإصلاحات التي طبّقتها.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ معرض أعمال داكنًا للمطورين بأسلوب Linear وVercel مع بطاقات بتأثير الإضاءة وقائمة أوامر Ctrl K

ينشئ موقع معرض أعمال داكنًا وهادئًا باسمك كمطور أو مصمم: بطاقات مشاريع بإضاءة تتبع المؤشر، وقائمة أوامر Ctrl K تبحث في ملف JSON محلي، وصفحات دراسات حالة، وقائمة مقالات. لا تُستخدم أي مكتبة، ويُحمَّل ملف البحث عند أول فتح، ويتم قياس كل صفحة.

متى تستخدمهعندما تريد معرضَ أعمال باسمك الشخصي يشرح عملك من خلال دراسات الحالة، ويتميز بمظهر داكن وسهل الاستخدام بلوحة المفاتيح مثل موقعي Linear أو Vercel.

على موقع [اسم الخادم] في خادم الاستضافة الخاص بي على Opus Growth، أنشئ معرض أعمال شخصيًا ثابتًا لـ [اسمي الكامل] بطابع داكن وهادئ مثل موقعي Linear وVercel. نبذة عني: [مسمّاي الوظيفي، مدينتي، ما أعمله ومنذ كم سنة، جملتان]. المشاريع: [for each one the name, year, my role, whether I may publish the client's name, the technologies, context, constraints, approach and outcome notes, and a screenshot link]. المقالات: [العنوان أو التاريخ أو النص أو المسودة]. الخبرة: [الفترات الزمنية بالسنوات والأدوار الوظيفية]. التواصل: [البريد الإلكتروني]؛ الملفات التي أريد نشرها: [GitHub أو LinkedIn وغيرها، أو "لا شيء"]. متاح لأعمال جديدة: [نعم ومنذ متى، أو لا]. النطاق: [النطاق].

الصفحات: الرئيسية (مقدمة قصيرة، أعمال مختارة، آخر المقالات، ما أعمل عليه الآن، أسئلة شائعة)، المشاريع (/projeler/)، صفحة لكل دراسة حالة (/projeler/[slug]/: السياق، القيود، المنهج، النتيجة، معلومات المشروع)، الكتابات (/yazilar/)، صفحة لكل مقال (/yazilar/[slug]/)، نبذة عني (/hakkimda/) و404.html. إذا لم يوافق العميل على الأرقام، فلا تكتب نسبًا مئوية أو مدد زمنية في دراسة الحالة؛ صف النتيجة وصفًا نوعيًا.

الأسلوب: داكن وبسيط. خلفية بحدود #09090B، وبطاقات أفتح بدرجة واحدة، وحد رمادي داكن بسماكة 1 بكسل، ونص أبيض تقريبًا، ونص ثانوي بلون رمادي بتباين لا يقل عن 7:1 مع الخلفية، ولون تمييز واحد يُستخدم فقط لنقطة الحالة وحلقة التركيز والروابط. وزنان من خط Grotesk من Fontshare (مثل Bespoke Sans بوزني 400 و500)؛ وللتواريخ والتسميات استخدم مجموعة الخطوط أحادية المسافة في النظام دون تنزيل خط (ui-monospace, SFMono-Regular, Menlo, Consolas). إذا بدت الأرقام بنمط old-style فاضبط `font-variant-numeric: lining-nums`. لا توجد صورة في الواجهة الرئيسية؛ وتُرسم خلفها بـ CSS خطوط شبكة رفيعة تتلاشى تحت قناع.

قواعد التفاعل:
1. لا يتم تحميل GSAP وLenis وSwiper ومكتبات البحث الجاهزة (Fuse.js وما شابهها). تحصل كل صفحة على ملف `ix.js` صغير واحد مع defer (الإضاءة، زر قائمة الأوامر، data-reveal)، وتكون قائمة الأوامر نفسها في ملف `ara.js` منفصل. لا يُنزَّل ara.js مع الصفحة؛ بل يُحمَّل عندما يدخل المؤشر إلى الزر أو يصل إليه التركيز، أو عند فتح القائمة لأول مرة. في العرض التجريبي لم تكن صفحات المقالات تحتوي على ix.js ولم يكن Ctrl K يعمل فيها؛ يجب أن تتصرف القائمة بالطريقة نفسها في كل صفحة.
2. بطاقات الإضاءة: ضوء ناعم على ::before الخاص بالبطاقة بـ `radial-gradient(420px circle at var(--mx) var(--my), ...)` وتوهج بلون التمييز على الحد بسماكة 1 بكسل في ::after باستخدام mask-composite. يضيف JS مستمع pointermove واحدًا فقط إلى الحاوية المحيطة بالبطاقات، ويقيّد وتيرته بـ requestAnimationFrame، ويكتب --mx و--my نسبةً إلى صندوق كل بطاقة ويمسحهما عند مغادرة المؤشر. يعمل هذا فقط على الأجهزة التي تطابق `(hover: hover) and (pointer: fine)` ولا تطلب تقليل الحركة؛ وعلى اللمس تبقى البطاقة عادية. رابط عنوان البطاقة يغطي البطاقة كلها عبر ::after.
3. قائمة الأوامر: عنصر "بحث" في الترويسة هو رابط حقيقي إلى /projeler/ في HTML (مفيد عند تعطيل JS) ويحمل aria-keyshortcuts="Control+K Meta+K". يعترض JS النقرة؛ وتفتح القائمة بالمفاتيح Ctrl K وCmd K و/ (خارج حقول النص). القائمة عبارة عن `<dialog>` يبنيها JS عند أول فتح ويفتحها بـ showModal: مربع بحث بـ role="combobox" وaria-expanded وaria-controls وaria-autocomplete="list" وaria-activedescendant، وقائمة نتائج بـ role="listbox"، ومنطقة role="status" تقرأ عدد النتائج. تحرك مفاتيح الأسهم التحديد، ويذهب Enter إلى الصفحة المحددة، ويغلق Esc القائمة عبر السلوك الأصلي للـ dialog، والنقر على الخلفية يغلقها، ويعود التركيز إلى الزر عند الإغلاق.
4. فهرس البحث `/assets/ara.json`: العنوان، والنوع (Project، Post، Page)، وURL، وملخص من جملة واحدة، وكلمات مفتاحية لكل مشروع ومقال وصفحة رئيسية. لا تكتب هذا الملف يدويًا؛ ولّده من البيانات نفسها التي تستخدمها لصفحات المشاريع والمقالات حتى لا يختلف الاثنان أبدًا. اجعل البحث غير حساس للأحرف التركية (toLocaleLowerCase("tr")، ثم توحيد ı وş وğ وü وö وç)، واشترط تطابق كل الكلمات، ورتّب تطابقات العنوان أعلى.
5. تبدأ صفحة دراسة الحالة بجدول معلومات (السنة، الدور، العميل، التقنية) ولقطة الشاشة التي تمثل عنصر LCP فيها (fetchpriority="high"، دون lazy)؛ وتكون عناوين البطاقات h2 في صفحات القوائم وh3 داخل قسم h2 في الصفحة الرئيسية.

Schema: ProfilePage في الرئيسية وصفحة النبذة (mainEntity Person)، وPerson (@id /#person: name وjobTitle وurl وemail وعنوان بالمدينة والبلد فقط وknowsAbout وsameAs للملفات التي أعطيتك إياها فقط). كتلة Organization التي يكتبها seo-stamp تمثل نشاطك التجاري كفرد؛ اربط Person بها عبر worksFor. تحصل المشاريع على CollectionPage مع hasPart؛ وكل دراسة حالة هي CreativeWork (creator وهو Person، وdateCreated وimage وkeywords)؛ وتحصل الكتابات على Blog وكل مقال على BlogPosting (headline وimage وdatePublished وdateModified وauthor وهو Person؛ يعرض seo-check خطأ إذا غاب image أو datePublished). تحتوي المحاضرات والجوائز وقوائم العملاء على حقائق قابلة للتحقق فقط.

الإعداد والمزالق المعروفة (كل واحدة منها كلفت نقاطًا في قياسات العرض التجريبي، فلا تتجاوز أيًّا منها):
1. إذا كان هناك موقع يعمل بالفعل على الخادم، فأخبرني أولًا لأن الإعداد يستبدل index.html ومجلد assets. اعرض معاينة scaffold_site مع confirm=false، ولا تستدعه مع confirm=true إلا بعد موافقتي. ثم اقرأ site_design_guide وsite_seo_guide. قبل كتابة الكود، ضع اتجاه التصميم (الخطوط، الألوان، الشبكة، العنصر المميز، لغة الحركة، والمكتبات التي لن تُحمَّل) في ملف ART.md قصير خارج assets واعرضه علي.
2. قم بتجميع Tailwind ولا تحمّله من CDN. ثبّته بـ site_run_command مع background=true (`npm i -D tailwindcss@3`) وتابعه بـ site_command_status. يجب أن تغطي مسارات content في `tailwind.config.js` كل ملفات HTML وقوالب `_src` وأي ملف JS يكتب فئات. يحتوي `_src/tw.css` على السطر `@import "../assets/app.css";` مع أسطر `@tailwind` الثلاثة؛ جمّعه في ملف واحد بالأمر `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. أزل سكربت cdn.tailwindcss.com وtailwind.config المضمّن من كل صفحة واربط `/assets/site.css` فقط. أعد التجميع بعد كل تعديل على HTML.
3. استضف الخطوط بنفسك. اقرأ CSS عائلة Fontshare التي اخترتها، ونزّل woff2 لكل وزن على حدة بـ site_fetch إلى `assets/fonts/`، واكتب قواعد @font-face مع `font-display: swap` في `assets/app.css`، وهو المكان الذي يبحث فيه design-check عن الخط المخصص. تحقق من اسم font-family في CSS المنزَّل وتأكد من أن العائلة تحتوي على الأحرف التركية ı وİ وş وğ (خط Tanker لا يحتوي على ı). نفّذ preload لكل الأوزان المستخدمة في الشاشة الأولى بـ `<link rel="preload" as="font" type="font/woff2" crossorigin>` وضعه قبل سطر ورقة الأنماط؛ وإذا زادت الملفات عن ثلاثة فاستخدم أوزانًا أقل. في العرض التجريبي، وزن واحد للنص لم يُحمَّل مسبقًا رفع LCP على الجوال إلى 2.6 ثانية وخفّض Performance إلى 97. معظم خطوط Fontshare لا تحتوي على رمز ₺، لذلك اكتب الأسعار بـ "TL".
4. اجعل القائمة والتذييل HTML ثابتًا. لا تحمّل chrome.js أو motion.js أو site.config.js في الصفحات. اكتب `chrome-stamp.mjs` صغيرًا يقرأ قائمة التنقل من site.config.js ويختم `_src/header.tpl` و`_src/footer.tpl` بين العلامتين `` و`` في كل صفحة، ويضيف aria-current="page" إلى الرابط النشط. استخدم عناصر نائبة مثل `[[NAV]]` بدل `{{...}}` ولا تعطِ القوالب امتداد .html، وإلا عامل design-check وseo-check القوالب كصفحات غير مكتملة. ابنِ قائمة الجوال بعنصر `<details>` دون JS. أبقِ اسم النشاط والعنوان والهاتف نصًا عاديًا في التذييل، واجعل ارتفاع روابط التذييل ومسار التنقل 44 بكسل على الأقل.
5. حوّل الصور أثناء جلبها بـ site_fetch: اكتب الصورة نفسها في ملفات منفصلة مع resize="480x" و"800x" و"1200x" وimage_format="webp" وquality=60 (لا يقص site_fetch الصور، لذا اطلب المصدر بالنسبة التي تحتاجها). أعطِ كل `<img>` قيم srcset وsizes وwidth وheight مطابقة للنسبة الفعلية. الصورة التي تمثل عنصر LCP في الصفحة تحصل على fetchpriority="high" ولا تكون lazy؛ وكل صورة أخرى تحصل على loading="lazy" decoding="async". إذا ملأت صورة الشاشة الأولى على الجوال، فقدّم للجوال قصة أصغر عبر `<picture>`.
6. أضف `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` إلى كل صفحة وأنشئ apple-touch-icon بحجم 180 بكسل من الشعار بـ site_fetch مع resize="180x180". بدون رابط favicon يطلب المتصفح /favicon.ico ويسجل خطأ 404 وينخفض Best Practices إلى 96.
7. قواعد مدقق HTML: ابدأ كل مستند بـ `<!DOCTYPE html>` بأحرف كبيرة؛ يجب أن يكون كل فراغ في النص المرئي لرابط tel: هو `&nbsp;`، بما في ذلك الفراغ بعد بادئة مثل "اتصل:&nbsp;0212..."؛ لا تستخدم style=""؛ أعطِ كل button قيمة type؛ ضع aria-label فقط على المعالم (landmarks) أو النماذج أو العناصر التفاعلية (على ul أو div دون role كان ذلك خطأ)؛ لا تعطِ معلمين الاسم نفسه أبدًا؛ لا تترك مسافات بيضاء في نهاية الأسطر.
8. لا تتخطَّ مستويات العناوين: في صفحة قائمة، أدّت عناوين البطاقات بوسم h3 مباشرة بعد h1 إلى خفض Accessibility إلى 98. عند إعادة استخدام بطاقة، اضبط مستوى عنوانها لكل صفحة (h2 في صفحة القائمة، وh3 داخل قسم h2).
9. سمِّ سمة الحركة data-reveal (لا يتعرف design-check على الحركة إلا بهذا الاسم). يعطي JS الحالة الأولية المخفية فقط للكتل الواقعة أسفل الشاشة عند فتح الصفحة، ولا يخفي أبدًا محتوى الشاشة الأولى؛ استخدم transform لأن التلاشي بـ opacity يخفض تدقيق التباين. ضع السمة على الكتلة التي تحيط بالعنوان ووصفه، لا على العنوان وحده؛ ففي العرض التجريبي انزلق عنوان منتظر فوق الفقرة التي تحته. مع prefers-reduced-motion: reduce لا يُخفى أي شيء وتُعطَّل الحركات.

SEO وAEO وGEO:
1. استخدم روابط بنمط الدلائل مع شرطة مائلة في النهاية. املأ كتلة seo في site.config.js ونفّذ `node seo-stamp.mjs`. اكتب schema الخاص بكل صفحة في كتل `<script type="application/ld+json">` منفصلة مرتبطة بالرسم الأساسي عبر @id. لا تضع BreadcrumbList داخل @graph؛ أبقه في كتلته الخاصة، فهذه هي الطريقة الوحيدة التي يراه بها seo-check.
2. العناوين 60 حرفًا كحد أقصى (يعتبر seo-check أي عنوان أقل من 25 أو أكثر من 65 خطأ)، والأوصاف من 130 إلى 158 حرفًا، وh1 واحد لكل صفحة، و150 كلمة على الأقل من المحتوى الرئيسي في كل صفحة. تميل صفحات التواصل والخصوصية والقوائم إلى القصر؛ أضف معلومات خاصة بالصفحة، لا حشوًا.
3. تجيب الفقرة الأولى في كل صفحة مباشرة عن سؤال الصفحة. اكتب أسئلة شائعة خاصة بكل صفحة باستخدام `<details>` وضع عليها ترميز FAQPage. أظهر الناشر وتاريخ "آخر تحديث" داخل عنصر `<time>`.
4. في robots.txt، اكتب قرارك مع السبب لكل من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot وCCBot، وأشر إلى خريطة الموقع. يحمل sitemap.xml تواريخ lastmod حقيقية. يحتوي llms.txt على ملخص دقيق للموقع في جملتين وقائمة بالصفحات المهمة.
5. لا اختلاق: لا تكتب تقييمات أو درجات أو جوائز أو أعداد عملاء أو شهادات أو ساعات عمل أو إحداثيات أو أسعارًا دون أن تسألني. اترك أي حقل لا تعرفه خارج schema تمامًا.

البوابات (بالترتيب؛ لا تقل "تم" قبل أن تنجح كلها):
1. بـ site_run_command نفّذ `node chrome-stamp.mjs` وبناء Tailwind و`node seo-stamp.mjs` و`node seo-check.mjs` (0 أخطاء، 0 تحذيرات) و`node design-check.mjs` (0 أخطاء؛ برّر أي تحذير متبقٍّ) و`npx html-validate "**/*.html"` (0 أخطاء).
2. اعرض كل صفحة بـ site_preview مع view="mobile" وview="desktop". يلتقط site_preview الصفحة مع تعطيل الحركة (reduced-motion)؛ وإذا كان هناك محتوى مفقود في هذه اللقطة فالحالة الثابتة معطوبة. في لقطات الصفحة الكاملة قد تظهر العناصر الثابتة مثل الشريط اللاصق في منتصف الصفحة وقد تظهر الصور lazy الأبعد فارغة؛ لا تعدّ ذلك أخطاء، لكن تحقق من مساراتها.
3. نفّذ core_web_vitals لكل صفحة مع strategy="mobile" وstrategy="desktop". معيار القبول: على الجوال Performance لا يقل عن 95 (الهدف من 99 إلى 100) وAccessibility وBest Practices وSEO بقيمة 100؛ وعلى سطح المكتب الأربعة بقيمة 100. للصفحة التي تفشل، استخدم resources=true لإيجاد الملف الذي يؤخرها، وأصلحه وقِس مرة أخرى. ثم نفّذ seo_audit على الصفحة الرئيسية مع strategy="mobile" وruns=2. يجب ألا يبقى أي عنوان خارج نطاقك الخاص في قائمة طلبات الشبكة.
4. لا تمرير أفقي عند عرض 360 و390 و768 و1440 بكسل، ومناطق اللمس 44 بكسل على الأقل، ولا أخطاء في وحدة التحكم (console).

فحص التفاعل: لا يستطيع site_preview عرض التمرير بالمؤشر (hover) ولا اختصارات لوحة المفاتيح ولا مربعات الحوار. أخبرني كيف أتحقق على سطح المكتب من أن الضوء يتبع المؤشر فوق البطاقات؛ وأن Ctrl K وCmd K و/ تفتح القائمة؛ وأن الكتابة دون أحرف تركية لا تزال تعثر على نتائج ("erisilebilir" وما شابهها)؛ وأن مفاتيح الأسهم وEnter تنقلني إلى مقال؛ وأن التركيز يعود إلى زر البحث بعد Esc؛ وأنه مع تعطيل JavaScript يفتح رابط البحث صفحة المشاريع.

بعد النشر: اعرض معاينة القاعدة `/assets/* Cache-Control: public, max-age=31536000, immutable` بـ site_headers وطبّقها بعد موافقتي؛ ومن ذلك الحين، أضف رقم إصدار إلى اسم الملف كلما تغير CSS أو JS (site-v2.css وهكذا). أرسل sitemap.xml بـ gsc_submit_sitemap وافحص الصفحة الرئيسية بـ gsc_url_inspect. وفي النهاية سلّمني: جدول نتائج لكل صفحة (الصفحة، أربع نتائج للجوال، أربع نتائج لسطح المكتب، LCP، CLS)، ونتيجة كل بوابة، وقائمة الإصلاحات التي طبقتها.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقعًا عقاريًا بشبكة عقارات قابلة للتصفية وصفحات إعلانات يتم توليدها من ملف JSON واحد

ينشئ موقعًا لوكالتك العقارية على خادم استضافتك يولّد كل إعلان عقاري من ملف JSON واحد: تُكتب مرشحات الحي والغرف والسعر في URL ويمكن مشاركتها، وتحصل كل وحدة عقارية على صفحة ثابتة تضم معرضًا للصور وخريطة وschema من نوع RealEstateListing. لا يتم تحميل أي مكتبة للخرائط أو المعارض، وتظهر جميع العقارات مع إيقاف JavaScript.

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

على موقع [اسم الخادم] في خادم استضافة Opus Growth الخاص بي، ابنِ موقع عقارات ثابتًا وسريعًا لوكالتي العقارية [اسم الوكالة] يُنشئ كل إعلان عقاري من ملف JSON واحد. الوكالة: [المدينة، الأحياء التي أعمل فيها، بيع أو إيجار]. رقم رخصتي لمزاولة التجارة العقارية (Taşınmaz Ticareti Yetki Belgesi): [رقم الترخيص]. الإعلانات: [for each listing the listing no, title, district, neighbourhood, rooms, gross and net square metres, floor, year built, heating, service charge, title deed status, price, listing date, a two-paragraph description, four key features, photo links and the location detail the owner has agreed to show]. للتواصل: [الهاتف]، [رقم WhatsApp]، [البريد الإلكتروني]، [عنوان المكتب]. النطاق: [النطاق].

الصفحات: الرئيسية (نموذج بحث حسب الحي والغرف والحد الأقصى للسعر، إعلانات مميزة، دليل الأحياء، أسئلة شائعة)، الإعلانات (/ilanlar/: عوامل التصفية، عدد النتائج، شبكة الإعلانات، أسئلة شائعة عن الإعلانات)، صفحة لكل إعلان (/ilanlar/[الحي-المنطقة-للبيع-الغرف-النوع]/)، من نحن (/hakkimizda/: خطوات الشراء والرخصة)، اتصل بنا (/iletisim/، بلا نموذج)، الخصوصية (/gizlilik/) و404.html.

الأسلوب: عقارات تحريرية دافئة. خلفية رملية فاتحة، ونص بلون الحبر، ولون تمييز داكن واحد مثل الأخضر الصنوبري (نص أبيض على الأزرار)، وخط Serif من Fontshare للعناوين والأسعار (مثل Sentient 500) وخط Sans للنص الأساسي (مثل Ranade 400). بطاقات إعلانات بصورة بنسبة 4:3 وسعر كبير بخط Serif وعلامات صغيرة للغرف والمساحة بالمتر المربع والطابق. تتكبّر صورة البطاقة قليلًا عند تمرير المؤشر عليها. لا تُحمَّل أي مكتبة خرائط ولا إطار iframe من Google Maps ولا أي مكتبة معرض صور أو سلايدر.

مصدر واحد وتوليد تلقائي:
1. تُحفظ كل بيانات الإعلانات في `assets/ilanlar.json`. اكتب ملف `ilan-build.mjs` صغيرًا ونفّذه عبر site_run_command بالأمر `node ilan-build.mjs`: (أ) يُنشئ `ilanlar/[slug]/index.html` لكل إعلان من القالب `_src/ilan.tpl`، (ب) يُدرج كل البطاقات بين `` في `ilanlar/index.html` والمميزة بين `` في الصفحة الرئيسية، (ج) يكتب مخطط ItemList الخاص بصفحة الإعلانات بين ``. استخدم عناصر نائبة مثل `[[السعر]]` في القالب، وليس `{{...}}`. الترتيب: ilan-build، ثم chrome-stamp، ثم بناء Tailwind، ثم seo-stamp. يجب أن تعني إضافة إعلان أو إزالة إعلان تم بيعه تعديل ملف JSON ثم تنفيذ هذا الترتيب مجددًا؛ وعند حذف صفحة إعلان مُباع، أعد توجيه عنوان URL الخاص به إلى /ilanlar/ عبر site_redirects.
2. البطاقات HTML ثابت يُولَّد على الخادم، فيظهر كل إعلان مع تعطيل JS ولمحركات البحث. تحمل كل بطاقة السمات data-ilce وdata-oda وdata-fiyat وdata-m2 وdata-tarih لأغراض التصفية؛ ويجب ألا تتعارض أسماء فئات المكونات مع أدوات Tailwind (استخدم بادئة مثل lcard).

قواعد التصفية:
1. التصفية نموذج حقيقي بالسمتين action="/ilanlar/" وmethod="get": قوائم select بعناوين للحي والغرف والحد الأدنى للسعر والحد الأقصى للسعر وترتيب العرض، مع زر "تصفية". عند تعطيل JS يملأ النموذج عنوان URL لكن القائمة لا تتغير؛ اذكر ذلك في جملة واحدة داخل `<noscript>`.
2. يُحمَّل `ilan-filtre.js` بالسمة defer في /ilanlar/ فقط: عند التحميل يقرأ ?ilce=&oda=&min=&max=&sira= باستخدام URLSearchParams (ويقبل القيم الموجودة في قوائم select فقط)، ويُخفي البطاقات ويُظهرها بالسمة hidden، ويعيد ترتيب DOM للفرز، ويحدّث عنوان URL بـ history.replaceState عند كل تغيير. يمكن مشاركة القائمة المصفّاة كرابط، ولا يمتلئ سجل زر الرجوع.
3. أعلن عدد النتائج في جملة بالسمة role="status" ("6 إعلانات، 2 منها تطابق عوامل التصفية"). وعند عدم وجود نتائج اعرض رسالة حالة فارغة ورابط "مسح عوامل التصفية". يقع مربع التصفية في الشاشة الأولى، لذا يجب ألا يضيف JS أو يخفي أي شيء هناك؛ تتغير البطاقات فقط، وإلا حدث انزياح في التخطيط (CLS).
4. في صفحة الإعلانات، لا تكون صورة البطاقة الأولى lazy وتكون البقية كذلك؛ وعناوين البطاقات h2 في هذه الصفحة وh3 تحت العنوان h2 "إعلانات مميزة" في الصفحة الرئيسية.

صفحة الإعلان:
1. تلخّص الفقرة الأولى الإعلان في جملة واحدة: الحي والمنطقة وعدد الغرف والمساحة بالمتر المربع وسنة البناء والسعر. ثم شريط الصور: عناصر figure تُمرَّر أفقيًا بـ CSS scroll-snap دون JS، وتحتها صور مصغّرة هي روابط داخل الصفحة إلى كل صورة. يعترض `galeri.js` (في صفحات الإعلانات فقط) النقرات على الصور المصغّرة، ويمرّر الشريط فقط دون أن تقفز الصفحة، ويضع aria-current="true" على الصورة المصغّرة للصورة الظاهرة عبر IntersectionObserver. الصورة الأولى هي عنصر LCP في الصفحة: fetchpriority="high" وليست lazy.
2. مربع سعر ثابت (sticky) في العمود الأيمن: السعر، وقائمة حقائق (dl: السعر، رقم الإعلان، الغرف، المساحة الإجمالية والصافية بالمتر المربع، الطابق، سنة البناء، التدفئة، رسوم الخدمة، سند الملكية، تاريخ الإعلان)، ورابط WhatsApp برسالة مُعبّأة مسبقًا تتضمن رقم الإعلان، والهاتف ورقم الرخصة. تتوقع القواعد التركية وجود رقم الرخصة في إعلانات العقارات؛ ضعه في التذييل أيضًا.
3. الموقع: لا تنشر العنوان الكامل. استخدم صورة خريطة ثابتة محلية تُظهر الموقع التقريبي بالمستوى الذي وافق عليه المالك (غالبًا الحي) واذكر تحتها أن العنوان الكامل يُعطى عند المعاينة. إذا بنيت الخريطة من مربعات OpenStreetMap فاتبع سياسة استخدام المربعات (مرة واحدة لكل إعلان، وعدد قليل من المربعات، دون تنزيلات جماعية): اجلب المربعات بـ site_fetch إلى `_src/harita/`، وثبّت sharp عبر site_run_command مع background=true (`npm i -D sharp`)، ثم استخدم سكربتًا صغيرًا لدمج المربعات وقص الصورة حول المركز ووضع علامة على المنطقة التقريبية بدائرة نصف شفافة وحفظ ملفات WebP بعرض 480 و768 بكسل. إذا تجاوز القص منطقة المربعات ظهر شريط أسود عند الحافة؛ فاجلب 5x3 مربعات على الأقل حول المركز. اكتب إشارة "© OpenStreetMap contributors" داخل الصورة وكرابط تحتها أيضًا. تُحمَّل الخريطة بـ lazy ولا يدخل أي سكربت خريطة خارجي إلى الصفحة.

المخطط: في صفحة الإعلان استخدم RealEstateListing (url وname وdescription وdatePosted ومصفوفة صور وoffers مع Offer: price وpriceCurrency بالقيمة "TRY" وavailability و@id للنشاط التجاري كـ seller) مع Apartment أو SingleFamilyResidence كـ mainEntity (numberOfRooms وnumberOfBedrooms وnumberOfBathroomsTotal وfloorSize كـ QuantitativeValue مع unitCode "MTK" وyearBuilt، وaddress يتضمن المنطقة والمحافظة والبلد فقط). لا تعرض Google نتيجة مميزة مخصصة لهذه الأنواع؛ والهدف أن تقرأ محركات البحث والذكاء الاصطناعي السعر وعدد الغرف والموقع قراءة صحيحة. استخدم CollectionPage وItemList في صفحة الإعلانات، وbusinessType "RealEstateAgent" في seo-stamp للوكالة، وBreadcrumbList في كل صفحة داخلية. خذ السعر والمساحة ورسوم الخدمة وتفاصيل السند من إفادة المالك الخطية فقط؛ واترك أي معلومة لا تعرفها خارج ملف JSON وخارج المخطط على السواء.

الإعداد والمشكلات المعروفة (كلٌّ منها كلّف نقاطًا في قياسات العرض التجريبي، فلا تتجاوز أيًّا منها):
1. إذا كان هناك موقع يعمل بالفعل على الخادم فأخبرني أولًا، لأن الإعداد يستبدل index.html ومجلد assets. اعرض معاينة scaffold_site مع confirm=false، ولا تستدعه مع confirm=true إلا بعد موافقتي. ثم اقرأ site_design_guide وsite_seo_guide. قبل كتابة الشيفرة، ضع اتجاه التصميم (الخطوط والألوان والشبكة والعنصر المميز ولغة الحركة والمكتبات التي لن تُحمَّل) في ملف ART.md قصير خارج assets وأرِني إياه.
2. قم بتجميع Tailwind ولا تحمّله من CDN. ثبّته عبر site_run_command مع background=true (`npm i -D tailwindcss@3`) وتابع بـ site_command_status. يجب أن تغطي مسارات content في `tailwind.config.js` كل ملفات HTML وقوالب `_src` وأي ملف JS يكتب فئات. يحتوي `_src/tw.css` على السطر `@import "../assets/app.css";` مع أسطر `@tailwind` الثلاثة؛ جمّعه في ملف واحد بالأمر `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. أزل سكربت cdn.tailwindcss.com وإعداد tailwind.config المضمّن من كل صفحة واربط `/assets/site.css` فقط. أعد التجميع بعد كل تغيير في HTML.
3. استضف الخطوط بنفسك. اقرأ CSS لعائلة Fontshare التي اخترتها، ونزّل ملف woff2 لكل وزن على حدة بـ site_fetch إلى `assets/fonts/`، واكتب قواعد @font-face مع `font-display: swap` في `assets/app.css`، وهو المكان الذي يبحث فيه design-check عن خط مخصص. تحقق من اسم font-family في ملف CSS الذي نزّلته وتأكد من أن العائلة تحتوي على الحروف التركية ı وİ وş وğ (خط Tanker لا يحتوي على ı). نفّذ preload لـ كل وزن مستخدم في الشاشة الأولى بالوسم `<link rel="preload" as="font" type="font/woff2" crossorigin>` ويوضع قبل سطر ورقة الأنماط؛ وإذا زاد العدد على ثلاثة ملفات فاستخدم أوزانًا أقل. في العرض التجريبي دفع وزن واحد للنص الأساسي لم يُحمَّل مسبقًا بـ LCP على الجوال إلى 2.6 ثانية وبالأداء إلى 97. تفتقر معظم خطوط Fontshare إلى رمز ₺، لذا اكتب الأسعار بـ "TL".
4. اجعل القائمة والتذييل HTML ثابتًا. لا تحمّل chrome.js ولا motion.js ولا site.config.js في الصفحات. اكتب ملف `chrome-stamp.mjs` صغيرًا يقرأ قائمة التنقل من site.config.js ويُدرج `_src/header.tpl` و`_src/footer.tpl` بين العلامتين `` و`` في كل صفحة، مع إضافة aria-current="page" إلى الرابط النشط. استخدم عناصر نائبة مثل `[[NAV]]` بدل `{{...}}` ولا تعطِ القوالب الامتداد .html، وإلا عامل design-check وseo-check القوالب كصفحات غير مكتملة. ابنِ قائمة الجوال بوسم `<details>` دون JS. أبقِ اسم النشاط والعنوان والهاتف نصًا عاديًا في التذييل، واجعل ارتفاع روابط التذييل ومسار التنقل (breadcrumb) 44 بكسل على الأقل.
5. حوّل الصور أثناء جلبها بـ site_fetch: اكتب الصورة نفسها في ملفات منفصلة مع resize="480x" و"800x" و"1200x" وimage_format="webp" وquality=60 (لا يقصّ site_fetch الصور، لذا اطلب المصدر بالنسبة التي تحتاجها). أعطِ كل `<img>` السمات srcset وsizes وwidth وheight المطابقة للنسبة الفعلية. تحصل الصورة التي هي عنصر LCP في الصفحة على fetchpriority="high" وليست lazy؛ وكل صورة أخرى تحصل على loading="lazy" decoding="async". إذا ملأت صورة الشاشة الأولى على الجوال فقدّم للجوال قصًّا أصغر عبر `<picture>`.
6. أضف `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` إلى كل صفحة وأنشئ apple-touch-icon بحجم 180 بكسل من الشعار بـ site_fetch مع resize="180x180". بدون رابط favicon يطلب المتصفح /favicon.ico ويسجّل خطأ 404 وتنخفض الممارسات الفضلى (Best Practices) إلى 96.
7. قواعد مدقّق HTML: ابدأ كل مستند بـ `<!DOCTYPE html>` بأحرف كبيرة؛ يجب أن تكون كل مسافة في النص المرئي لرابط tel: هي `&nbsp;`، بما فيها المسافة بعد بادئة مثل "اتصل:&nbsp;0212..."؛ لا تستخدم style=""؛ أعطِ كل زر type؛ ضع aria-label على المعالم (landmarks) أو النماذج أو العناصر التفاعلية فقط (على ul أو div بلا role كان خطأ)؛ لا تعطِ معلمين الاسم نفسه؛ ولا تترك مسافات زائدة في نهاية الأسطر.
8. لا تتخطَّ مستويات العناوين: في صفحة قائمة، أدّت عناوين البطاقات بصيغة h3 مباشرةً بعد h1 إلى خفض إمكانية الوصول إلى 98. عند إعادة استخدام بطاقة اضبط مستوى العنوان لكل صفحة (h2 في صفحة قائمة، وh3 داخل قسم h2).
9. سمِّ سمة الحركة data-reveal (لا يتعرف design-check على الحركة إلا بهذا الاسم). يعطي JS الحالة المخفية الابتدائية فقط للكتل الواقعة أسفل الشاشة عند فتح الصفحة، ولا يُخفي أبدًا محتوى الشاشة الأولى؛ واستخدم transform، لأن التلاشي بـ opacity يخفض فحص التباين. ضع السمة على الكتلة التي تغلّف العنوان ووصفه، وليس على العنوان وحده؛ ففي العرض التجريبي انزلق عنوان في وضع الانتظار فوق الفقرة التي تحته. مع prefers-reduced-motion: reduce لا يُخفى شيء وتتعطل الرسوم المتحركة.

السيو وAEO وGEO:
1. استخدم عناوين URL بنمط المجلدات مع شرطة مائلة في النهاية. املأ كتلة seo في site.config.js ونفّذ `node seo-stamp.mjs`. اكتب المخطط الخاص بكل صفحة في كتل `<script type="application/ld+json">` منفصلة مرتبطة بالمخطط الأساسي عبر @id. لا تُدخل BreadcrumbList داخل @graph؛ أبقِه في كتلته الخاصة، وهي الطريقة الوحيدة التي يراه بها seo-check.
2. العناوين بحد أقصى 60 حرفًا (يعدّ seo-check أي عنوان أقل من 25 أو أكثر من 65 خطأً)، والأوصاف من 130 إلى 158 حرفًا، وh1 واحد في كل صفحة، و150 كلمة على الأقل من المحتوى الرئيسي في كل صفحة. تميل صفحات الاتصال والخصوصية والقوائم إلى القصر؛ أضف معلومات خاصة بالصفحة، لا حشوًا.
3. تجيب الفقرة الأولى في كل صفحة مباشرةً عن سؤال الصفحة. اكتب أسئلة شائعة خاصة بكل صفحة بوسم `<details>` ووسمها بـ FAQPage. أظهر الناشر وتاريخ "آخر تحديث" في عنصر `<time>`.
4. في robots.txt، اكتب قرارك مع السبب لكل من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot وCCBot، وأشِر إلى خريطة الموقع. يحمل sitemap.xml تواريخ lastmod حقيقية. يتضمن llms.txt ملخصًا دقيقًا من جملتين عن الموقع وقائمة بالصفحات المهمة.
5. لا اختلاق: لا تكتب مراجعات أو تقييمات أو جوائز أو أعداد عملاء أو شهادات أو ساعات عمل أو إحداثيات أو أسعارًا دون أن تسألني. اترك أي حقل لا تعرفه خارج المخطط تمامًا.

بوابات الجودة (بالترتيب؛ لا تقل "تم" حتى تنجح جميعها):
1. عبر site_run_command نفّذ `node chrome-stamp.mjs` وبناء Tailwind و`node seo-stamp.mjs` و`node seo-check.mjs` (0 أخطاء، 0 تحذيرات) و`node design-check.mjs` (0 أخطاء؛ برّر أي تحذير متبقٍّ) و`npx html-validate "**/*.html"` (0 أخطاء).
2. اعرض كل صفحة بـ site_preview مع view="mobile" وview="desktop". يلتقط site_preview الصفحة مع تعطيل الحركة (reduced-motion)؛ فإذا غاب محتوى في هذه اللقطة فالحالة الثابتة معطوبة. في لقطات الصفحة الكاملة قد تظهر عناصر ثابتة مثل شريط sticky في منتصف الصفحة وقد تبدو الصور lazy الأبعد فارغة؛ لا تحسب ذلك أخطاء، لكن تحقق من مساراتها.
3. نفّذ core_web_vitals لكل صفحة مع strategy="mobile" وstrategy="desktop". معيار القبول: على الجوال أداء 95 على الأقل (والهدف من 99 إلى 100) وإمكانية الوصول والممارسات الفضلى والسيو 100؛ وعلى سطح المكتب جميعها 100. للصفحة التي لا تحقق ذلك استخدم resources=true لإيجاد الملف الذي يؤخرها، وأصلحه ثم قِس مجددًا. بعد ذلك نفّذ seo_audit على الصفحة الرئيسية مع strategy="mobile" وruns=2. يجب ألا يبقى أي عنوان خارج نطاقك في قائمة طلبات الشبكة.
4. لا تمرير أفقي عند عرض 360 و390 و768 و1440 بكسل، وأهداف اللمس 44 بكسل على الأقل، ولا أخطاء في وحدة التحكم (console).

فحص التفاعل: لا يستطيع site_preview تشغيل التصفية. أخبرني كيف أتحقق من أن فتح /ilanlar/?ilce=[الحي]&oda=3%2B1 يعرض الإعلانات المطابقة فقط ويملأ النموذج، وأن تغيير أي select يحدّث شريط العنوان، وأن رسالة الحالة الفارغة تظهر عند عدم وجود تطابق، وأن كل الإعلانات تظهر مع تعطيل JavaScript، وأن النقر على صورة مصغّرة في صفحة إعلان يمرّر شريط الصور فقط دون أن تقفز الصفحة.

بعد النشر: اعرض معاينة للقاعدة `/assets/* Cache-Control: public, max-age=31536000, immutable` بـ site_headers وطبّقها بعد موافقتي؛ ومن ثَمّ غيّر رقم إصدار اسم الملف كلما تغيّر CSS أو JS (site-v2.css وهكذا). أرسل sitemap.xml بـ gsc_submit_sitemap وافحص الصفحة الرئيسية بـ gsc_url_inspect. في النهاية سلّمني: جدول نقاط لكل صفحة (الصفحة، النقاط الأربع على الجوال، النقاط الأربع على سطح المكتب، LCP، CLS)، ونتيجة كل بوابة، وقائمة الإصلاحات التي طبّقتها.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقعًا لمنتج SaaS بشبكة bento على طراز Webflow ومفتاح تبديل للأسعار بين الشهري والسنوي

ينشئ موقعًا تسويقيًا لمنتجك البرمجي على خادم الاستضافة الخاص بك بأسلوب قوالب Webflow لمنتجات SaaS: شبكة bento للميزات، وشريط شعارات يمكن إيقافه مؤقتًا، وعرض للمنتج بعلامات تبويب، ومفتاح تبديل للأسعار بين الشهري والسنوي يعمل بدون JavaScript. التفاعلات مبنية على 3 KB من JS الخام، ولا تُضاف أي شهادات عملاء مختلقة، ويُقاس أداء كل الصفحات.

متى تستخدمهعندما تريد مظهرًا بأسلوب قوالب Webflow لمنتجك البرمجي، مع بلاطات bento ومبدّل للأسعار، ولكن دون رسوم شهرية للمنصة أو سكربتات ثقيلة أو شهادات عملاء مزيفة.

على موقع [اسم الخادم] في خادم استضافة Opus Growth الخاص بي، ابنِ موقعًا تسويقيًا ثابتًا وسريعًا لمنتج البرمجيات الخاص بي [اسم المنتج] يشبه قوالب SaaS الحديثة على Webflow، دون استخدام Webflow. المنتج: [ما يقدمه ولمن، في جملة واحدة]. الميزات الرئيسية: [ست ميزات، جملة واحدة لكل ميزة]. لقطات شاشة التطبيق: [روابط ثلاث لقطات شاشة وما تعرضه كل واحدة منها]. الخطط: [أسماء الخطط، الأسعار الشهرية والسنوية، هل الضريبة مشمولة، ما تشمله كل خطة]. شعارات العملاء التي لدي إذن كتابي بعرضها: [ملفات الشعار أو "لا يوجد"]. آراء العملاء: [اقتباس معتمد، الاسم، المسمى الوظيفي، الشركة أو "لا يوجد"]. الشركة: [الاسم القانوني]، [العنوان]، [الهاتف]، [البريد الإلكتروني]، [رقم WhatsApp]. مسار التسجيل أو العرض التجريبي: [URL صفحة التسجيل أو "طلبات العرض التجريبي عبر WhatsApp والبريد الإلكتروني"]. النطاق: [النطاق].

الصفحات: الصفحة الرئيسية (قسم رئيسي مع لقطة شاشة للمنتج، شريط الشعارات، شبكة بنتو للميزات، عرض المنتج بتبويبات، آراء العملاء، الأسئلة الشائعة، دعوة ختامية لاتخاذ إجراء)، الميزات (/ozellikler/، لكل ميزة عنوانها ومرساها الخاص)، الأسعار (/fiyatlar/: مفتاح تبديل، بطاقات الخطط، جدول مقارنة، أسئلة شائعة عن الفوترة)، التواصل (/iletisim/، بلا نموذج؛ بريد إلكتروني، وWhatsApp برسالة معبأة مسبقًا، وهاتف)، الخصوصية (/gizlilik/) وصفحة 404.html.

الأسلوب: SaaS حديث بخلفية فاتحة. إذا لم تُحدَّد [تفضيل اللون]، فاستخدم خلفية بيضاء مائلة إلى الدفء، ونصًا بلون الحبر الأسود، ولونًا مميزًا ساطعًا واحدًا (يُستخدم كخلفية فقط، مع نص داكن فوقه). وزنان من عائلة خطوط Fontshare واحدة (مثل Satoshi 400 و700). بلاطات بنتو كبيرة بزوايا مستديرة، وأزرار على شكل حبوب، ولقطة شاشة المنتج داخل إطار نافذة داكن. بلا تدرجات من البنفسجي إلى الأزرق وبلا تأثير زجاجي في كل مكان.

قواعد التفاعل (تفاعلات Webflow دون مكتبة):
1. لا يتم تحميل GSAP وLenis وSwiper. اكتب التفاعلات بـ CSS إضافة إلى ملف JS واحد بلا مكتبات لا يتجاوز 3 KB، يُحمَّل بالسمة defer في الصفحة الرئيسية فقط. لا يحتاج مفتاح تبديل الأسعار إلى أي سكربت.
2. شبكة بنتو: شبكة CSS من 4 أعمدة على سطح المكتب، مع بلاطة واحدة بحجم 2x2 وبلاطتين بعرض عمودين، مرتبة بحيث لا تبقى أي خلية فارغة؛ وعمود واحد على الجوال. تحمل كل بلاطة رابطًا حقيقيًا إلى العنوان المطابق في صفحة الميزات، وتكون البلاطة بأكملها قابلة للنقر: أعطِ الرابط ::after مع inset:0 (رابط ممتد) ولا تضع رابطًا ثانيًا داخل البلاطة. عند تمرير المؤشر وعند :focus-within يصبح الإطار أغمق، وترتفع البلاطة 4 بكسل باستخدام transform، ويتحرك الجزء الصغير من الواجهة داخلها (قائمة خطوات تنزلق جانبيًا، وأعمدة تنمو باستخدام scaleY).
3. يستخدم شريط الشعارات فقط شعارات العملاء الذين أعطوا إذنًا كتابيًا؛ وإذا لم يوجد أي منهم، فاترك القسم خارج الصفحة ولا تستبدله بشعارات وهمية أو بقائمة "تكاملات" مختلقة. يتكون الشريط من نسختين من القائمة نفسها (الثانية بالسمة aria-hidden="true") تتحركان بـ @keyframes translate3d(-50%, 0, 0) في CSS؛ ويتوقف عند تمرير المؤشر وعند التركيز. ولأن الحركة تستمر أكثر من خمس ثوانٍ، تشترط WCAG 2.2.2 زر "إيقاف الشريط مؤقتًا": يكون الزر مخفيًا في HTML، ويُظهره JS ويحدّث aria-pressed وتسميته. أعطِ الصف الذي يحتوي الزر min-height يساوي ارتفاع الزر؛ ففي العرض التجريبي كان الصف يكبر عند ظهور الزر، وقيس انزياح صغير (CLS 0.002) على سطح المكتب. مع prefers-reduced-motion تتوقف الحركة، وتُخفى النسخة الثانية، وتتحول الشعارات إلى شبكة ثابتة تلتف على عدة أسطر.
4. عرض المنتج بتبويبات: في HTML تكون التبويبات روابط داخل الصفحة إلى اللوحات (href="#ekran-x") وتكون اللوحات الثلاث ظاهرة جميعها واحدة تحت الأخرى، فيكتمل المحتوى مع تعطيل JS وللزواحف. أعطِ حاوية التبويبات role="group" وaria-label. يحوّلها JS إلى role="tablist" و"tab" و"tabpanel"، ويدير aria-selected وaria-controls وtabindex وhidden، ويدعم السهمين الأيسر والأيمن وHome وEnd، ويحدد التبويب المطابق عند فتح الصفحة مع #ekran-x. تقع اللوحات أسفل الشاشة الأولى، لذا لا يسبب إخفاؤها أي انزياح في التخطيط؛ وتستخدم صور اللوحات loading="lazy".
5. يعمل مفتاح تبديل الأسعار دون JS: زرا اختيار (radio) داخل fieldset (شهري محدد افتراضيًا) وقواعد مثل `.pricing:has(#donem-yillik:checked) .price-m { display: none }` تُظهر الأسعار السنوية. أخفِ زر الاختيار بصريًا لكن أبقِ التسمية كلها قابلة للنقر وقابلة للوصول بلوحة المفاتيح؛ وأظهر حلقة التركيز باستخدام `label:has(input:focus-visible)`. في العرض الشهري تعرض كل خطة سطر "تُحاسَب سنويًا: X TL"، بحيث يكون السعران موجودين في النص.
6. تأتي آراء العملاء فقط من اقتباسات معتمدة يمكن التحقق منها بالاسم والمسمى الوظيفي والشركة. إذا لم يكن لديك أي منها، فاحذف القسم؛ وإذا استخدمت واحدًا أثناء المسودة، فاجعله بطاقة نائبة بحدود متقطعة تذكر أنها ستُملأ عند وصول اقتباس حقيقي، واسألني قبل النشر. لا تكتب schema من نوع Review أو aggregateRating.
7. لقطة شاشة المنتج في القسم الرئيسي هي عنصر LCP على سطح المكتب: fetchpriority="high"، دون lazy، مع sizes يحدد عرضها الفعلي. على الجوال يكون LCP عادةً نص العنوان؛ ومع ذلك يجب أن تحمّل لقطة الشاشة نسختها بعرض 480 بكسل عبر srcset.

Schema: SoftwareApplication في الصفحة الرئيسية وصفحة الأسعار (name وapplicationCategory "BusinessApplication" وoperatingSystem وurl وimage وpublisher وعرض Offer واحد لكل خطة ولكل فترة فوترة: name وprice وpriceCurrency "TRY" وurl). تشترط Google وجود تقييم أو مراجعة لعرض النتيجة المنسقة لتطبيق البرمجيات؛ وبدون مراجعات حقيقية تُجمع على موقعك الخاص لن تظهر نجوم، ولا يجوز حل ذلك بتقييم مختلق. FAQPage في الصفحة الرئيسية والميزات والأسعار، وContactPage في التواصل، وBreadcrumbList في الصفحات الداخلية. تجيب الفقرة الأولى من صفحة الأسعار مباشرة: "تبدأ أسعار [اسم المنتج] من N TL شهريًا". جدول المقارنة هو `<table>` حقيقي ويتمرر أفقيًا على الشاشات الضيقة داخل `<section tabindex="0" aria-label="...">`؛ وفي العرض التجريبي تسبب div بالسمة role="region" في تنبيه prefer-native-element، وتسبب قسمان موسومان بالعنوان نفسه في تنبيه unique-landmark.

الإعداد والمزالق المعروفة (كلٌّ منها كلّف نقاطًا في قياسات العرض التجريبي، فلا تتجاوز أيًّا منها):
1. إذا كان هناك موقع يعمل بالفعل على الخادم، فأخبرني أولًا، لأن الإعداد يستبدل index.html ومجلد assets. اعرض معاينة scaffold_site مع confirm=false، ولا تستدعه مع confirm=true إلا بعد موافقتي. ثم اقرأ site_design_guide وsite_seo_guide. قبل كتابة الكود، ضع اتجاه التصميم (الخطوط والألوان والشبكة والعنصر المميز ولغة الحركة والمكتبات التي لن تُحمَّل) في ملف ART.md قصير خارج assets واعرضه عليّ.
2. قم بتجميع Tailwind ولا تحمّله من CDN. ثبّته عبر site_run_command مع background=true (`npm i -D tailwindcss@3`) وتابع بـ site_command_status. يجب أن تغطي مسارات content في `tailwind.config.js` كل ملفات HTML وقوالب `_src` وأي ملف JS يكتب أصناف CSS. يحتوي `_src/tw.css` على السطر `@import "../assets/app.css";` إضافة إلى أسطر `@tailwind` الثلاثة؛ وجمّعه في ملف واحد باستخدام `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. احذف سكربت cdn.tailwindcss.com وtailwind.config المضمّن من كل صفحة، واربط `/assets/site.css` فقط. أعد التجميع بعد كل تغيير في HTML.
3. استضف الخطوط بنفسك. اقرأ CSS لعائلة Fontshare التي اخترتها، ونزّل woff2 لكل وزن على حدة باستخدام site_fetch إلى `assets/fonts/`، واكتب قواعد @font-face مع `font-display: swap` في `assets/app.css`، فهو المكان الذي يبحث فيه design-check عن خط مخصص. تحقق من اسم font-family في CSS الذي نزّلته وتأكد أن العائلة تحتوي على الحروف التركية ı وİ وş وğ (Tanker لا تحتوي على ı). نفّذ preload لكل وزن مستخدم في الشاشة الأولى باستخدام `<link rel="preload" as="font" type="font/woff2" crossorigin>`، ويوضع قبل سطر ورقة الأنماط؛ وإذا زاد العدد على ثلاثة ملفات، فاستخدم أوزانًا أقل. في العرض التجريبي دفع وزن واحد للنص لم يُحمَّل مسبقًا قيمة LCP على الجوال إلى 2.6 ثانية وخفّض Performance إلى 97. معظم خطوط Fontshare تفتقر إلى رمز ₺، لذا اكتب الأسعار مع "TL".
4. اجعل القائمة والتذييل HTML ثابتًا. لا تحمّل chrome.js أو motion.js أو site.config.js في الصفحات. اكتب ملف `chrome-stamp.mjs` صغيرًا يقرأ قائمة التنقل من site.config.js ويختم `_src/header.tpl` و`_src/footer.tpl` بين العلامتين `` و`` في كل صفحة، مع إضافة aria-current="page" إلى الرابط النشط. استخدم عناصر نائبة مثل `[[NAV]]` بدلًا من `{{...}}` ولا تمنح القوالب امتداد .html، وإلا عامل design-check وseo-check القوالب كصفحات غير مكتملة. ابنِ قائمة الجوال بعنصر `<details>` دون JS. أبقِ اسم النشاط والعنوان والهاتف نصًا عاديًا في التذييل، واجعل ارتفاع روابط التذييل وفتات التنقل 44 بكسل على الأقل.
5. حوّل الصور أثناء جلبها باستخدام site_fetch: اكتب الصورة نفسها كملفات منفصلة مع resize="480x" و"800x" و"1200x" وimage_format="webp" وquality=60 (لا يقص site_fetch الصور، لذا اطلب المصدر بالنسبة التي تحتاجها). أعطِ كل `<img>` سمات srcset وsizes وwidth وheight مطابقة للنسبة الحقيقية. الصورة التي تمثل عنصر LCP في الصفحة تأخذ fetchpriority="high" ولا تكون lazy؛ وكل صورة أخرى تأخذ loading="lazy" decoding="async". إذا ملأت صورة الشاشة الأولى على الجوال، فقدّم قصًّا أصغر للجوال باستخدام `<picture>`.
6. أضف `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` إلى كل صفحة وأنشئ apple-touch-icon بحجم 180 بكسل من الشعار باستخدام site_fetch مع resize="180x180". بدون رابط favicon يطلب المتصفح /favicon.ico ويسجل خطأ 404 وتنخفض Best Practices إلى 96.
7. قواعد مدقق HTML: ابدأ كل مستند بـ `<!DOCTYPE html>` بأحرف كبيرة؛ يجب أن تكون كل مسافة في النص المرئي لرابط tel: هي `&nbsp;`، بما فيها المسافة التي تلي بادئة مثل "اتصل:&nbsp;0212..."؛ لا تستخدم style=""؛ أعطِ كل زر type؛ ضع aria-label فقط على المعالم (landmarks) أو النماذج أو العناصر التفاعلية (على ul أو div بلا role كان ذلك خطأ)؛ لا تسمِّ معلمين باسم واحد؛ ولا تترك مسافات زائدة في نهاية الأسطر.
8. لا تتخطَّ مستويات العناوين: في صفحة قائمة، أدت عناوين البطاقات h3 مباشرة بعد h1 إلى خفض Accessibility إلى 98. عند إعادة استخدام بطاقة، حدد مستوى عنوانها لكل صفحة (h2 في صفحة القائمة، وh3 داخل قسم h2).
9. سمِّ سمة الحركة data-reveal (لا يتعرف design-check على الحركة إلا بهذا الاسم). يمنح JS الحالة الأولية المخفية فقط للكتل الموجودة أسفل الشاشة عند فتح الصفحة، ولا يخفي أبدًا محتوى الشاشة الأولى؛ استخدم transform، لأن التلاشي بـ opacity يخفض نتيجة فحص التباين. ضع السمة على الكتلة التي تحيط بعنوان ووصفه، لا على العنوان وحده؛ ففي العرض التجريبي انزلق عنوان ينتظر فوق الفقرة التي تحته. مع prefers-reduced-motion: reduce لا يُخفى شيء وتتوقف الحركات.

SEO وAEO وGEO:
1. استخدم عناوين URL بنمط المجلدات مع شرطة مائلة في النهاية. املأ كتلة seo في site.config.js ونفّذ `node seo-stamp.mjs`. اكتب schema الخاص بكل صفحة في كتل `<script type="application/ld+json">` منفصلة مرتبطة بالرسم الأساسي عبر @id. لا تضع BreadcrumbList داخل @graph؛ أبقِه في كتلته الخاصة، فهذه هي الطريقة الوحيدة التي يراه بها seo-check.
2. العناوين بحد أقصى 60 حرفًا (يعدّ seo-check أي عنوان أقل من 25 أو أكثر من 65 خطأ)، والأوصاف من 130 إلى 158 حرفًا، وh1 واحد لكل صفحة، و150 كلمة على الأقل من المحتوى الرئيسي في كل صفحة. تميل صفحات التواصل والخصوصية والقوائم إلى القصر؛ أضف معلومات خاصة بالصفحة، لا حشوًا.
3. تجيب الفقرة الأولى في كل صفحة مباشرة عن سؤال الصفحة. اكتب أسئلة شائعة خاصة بكل صفحة باستخدام `<details>` ووسِّمها كـ FAQPage. اعرض الناشر وتاريخ "آخر تحديث" داخل عنصر `<time>`.
4. في robots.txt، اكتب قرارك مع السبب لكل من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot وCCBot، وأشر إلى خريطة الموقع. يحتوي sitemap.xml على تواريخ lastmod حقيقية. يتضمن llms.txt ملخصًا دقيقًا للموقع من جملتين وقائمة بالصفحات المهمة.
5. لا اختلاق: لا تكتب مراجعات أو تقييمات أو جوائز أو أعداد عملاء أو شهادات أو ساعات عمل أو إحداثيات أو أسعارًا دون أن تسألني. اترك أي حقل لا تعرفه خارج schema تمامًا.

البوابات (بالترتيب؛ لا تقل "تم" حتى تنجح جميعها):
1. باستخدام site_run_command نفّذ `node chrome-stamp.mjs`، ثم بناء Tailwind، ثم `node seo-stamp.mjs`، ثم `node seo-check.mjs` (0 أخطاء، 0 تحذيرات)، ثم `node design-check.mjs` (0 أخطاء؛ برّر أي تحذير متبقٍ)، ثم `npx html-validate "**/*.html"` (0 أخطاء).
2. اعرض كل صفحة باستخدام site_preview مع view="mobile" وview="desktop". يلتقط site_preview الصفحة مع تعطيل الحركة (reduced-motion)؛ فإذا كان هناك محتوى ناقص في تلك اللقطة، فالحالة الثابتة معطلة. في اللقطات الكاملة للصفحة قد تظهر عناصر ثابتة مثل شريط sticky في منتصف الصفحة وقد تكون الصور lazy الأبعد فارغة؛ لا تحسب ذلك أخطاء، لكن تحقق من مساراتها.
3. نفّذ core_web_vitals لكل صفحة مع strategy="mobile" وstrategy="desktop". معيار القبول: على الجوال Performance لا تقل عن 95 (الهدف من 99 إلى 100) وAccessibility وBest Practices وSEO بقيمة 100؛ وعلى سطح المكتب تكون الأربعة كلها 100. لأي صفحة لا تحقق المعيار، استخدم resources=true لإيجاد الملف الذي يؤخرها، وأصلحه ثم قِس مجددًا. بعد ذلك نفّذ seo_audit على الصفحة الرئيسية مع strategy="mobile" وruns=2. يجب ألا يبقى أي عنوان خارج نطاقك الخاص في قائمة طلبات الشبكة.
4. لا تمرير أفقي عند عرض 360 و390 و768 و1440 بكسل، وأهداف اللمس 44 بكسل على الأقل، ولا أخطاء في وحدة التحكم (console).

فحص التفاعل: لا يستطيع site_preview عرض التمرير بالمؤشر (hover) ولا الحركة. أخبرني كيف أتحقق في متصفح سطح المكتب من أن بلاطات بنتو ترتفع عند تمرير المؤشر وعند التركيز بمفتاح Tab، وأن زر "إيقاف الشريط مؤقتًا" يوقف الشريط، وأن التبويبات تتبدل بمفاتيح الأسهم، وأن مفتاح تبديل الأسعار يُظهر الأسعار السنوية حتى مع تعطيل JavaScript، وأن الشعارات على هاتف مع تقليل الحركة تتحول إلى شبكة ثابتة.

بعد النشر: اعرض معاينة للقاعدة `/assets/* Cache-Control: public, max-age=31536000, immutable` باستخدام site_headers وطبّقها بعد موافقتي؛ ومن ذلك الحين، غيّر رقم إصدار اسم الملف كلما تغير CSS أو JS (site-v2.css وهكذا). أرسل sitemap.xml باستخدام gsc_submit_sitemap وافحص الصفحة الرئيسية باستخدام gsc_url_inspect. في النهاية سلّمني: جدول نتائج لكل صفحة (الصفحة، أربع نتائج للجوال، أربع نتائج لسطح المكتب، LCP، CLS)، ونتيجة كل بوابة، وقائمة بالإصلاحات التي طبقتها.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقعًا سريعًا لمنتج ذكاء اصطناعي بخلفية شفق بـ CSS وبطاقات زجاجية ومبدّل بين السمة الداكنة والفاتحة

ينشئ موقعًا لمنتج ذكاء اصطناعي على خادم استضافتك بخلفية شفق بـ CSS الخالص وبطاقات زجاجية ضبابية ومبدّل بين السمة الداكنة والفاتحة يتبع إعداد النظام ويتذكر الاختيار. يُقاس التباين في السمتين، وللزجاج بديل صلب، وتُقاس كل صفحة على الجوال حتى تصل إلى 100.

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

ابنِ موقع منتج متعدد الصفحات بخلفية أورورا وبطاقات زجاجية مصنفرة ومظهرين فاتح وداكن لـ [اسم منتج الذكاء الاصطناعي] على موقع [اسم الخادم] في خادم استضافة Opus Growth الخاص بي. المنتج: [ما يقدمه، ولمن]. طريقة العمل: [ثلاث خطوات]. ما ينتجه أو يفعله: [من 4 إلى 6 ميزات]. البيانات والأمان: [مكان تخزين البيانات، ولمدة كم، وهل تُستخدم لتدريب النماذج]. مسار التجربة أو التسجيل: [مدة التجربة، URL التسجيل]. التواصل: [البريد الإلكتروني], [الهاتف], [رقم WhatsApp], [العنوان]. النطاق: [النطاق]. ألوان العلامة التجارية: [الألوان، أو "أنت تختار"]. لقطات شاشة أو صور للمنتج: [الروابط، أو "لا يوجد"].

الصفحات: الرئيسية (/)، الميزات (/ozellikler/)، الأمان (/guvenlik/)، التواصل (/iletisim/)، الخصوصية (/gizlilik/) و404.html. أقسام الصفحة الرئيسية بالترتيب: القسم الرئيسي hero (h1، مقدمة من جملتين، زران وبطاقة المنتج التي هي العنصر المميز)، ثلاث خطوات، لمن هو (مع صورة)، الأسئلة الشائعة ودعوة ختامية لاتخاذ إجراء. في منتجات الذكاء الاصطناعي تمثل صفحة الأمان نصف قرار الشراء؛ اذكر مدة الاحتفاظ بالبيانات والوصول إليها وتدريب النماذج بوضوح. لا نموذج في صفحة التواصل، لأن الخادم يقدّم ملفات ثابتة فقط.

الأسلوب: أورورا وزجاج. ضوء ناعم متعدد الألوان يتحرك ببطء في الخلفية (الأورورا)، مع وضع المحتوى على بطاقات زجاجية مصنفرة. لا لوحة ألوان من البنفسجي إلى الأزرق؛ اختر ثلاث درجات ناعمة تناسب العلامة التجارية، مثل النعناعي والمشمشي والأزرق الجليدي. الخطوط: خط عناوين سيريف ناعم من Fontshare (مثل Gambetta 500) مع خط نص هادئ (مثل Synonym 400 و600). استخدم التأثير الزجاجي على أسطح البطاقات فقط؛ لا تغرق الصفحة بالزجاج. لا canvas ولا WebGL ولا فيديو ولا GSAP ولا Lenis ولا Swiper. JavaScript الوحيد هو مبدّل مظهر صغير مضمّن. العنصر المميز: بطاقة زجاجية في القسم الرئيسي تحتوي على مثال HTML حقيقي لما يفعله المنتج (مثل قرار ومهمة مستخرجين من نص اجتماع).

قواعد الأورورا والزجاج والمظهر (حيث يتعرض هذا الأسلوب للإخلال بالأداء والتباين بسهولة أكبر):
1. اصنع الأورورا بـ CSS خالص: طبقة واحدة `position: fixed` مع aria-hidden، وعنصران وهميان (::before و::after) وثلاثة radial-gradients كبيرة داخلهما. حرّك باستخدام transform فقط (translate3d وrotate وscale) في حلقة `alternate` مدتها من 25 إلى 35 ثانية وأضف `will-change: transform`. لا تحرّك التدرج نفسه ولا background-position ولا filter: blur؛ فهذه تعيد الرسم في كل إطار. ضع الحركة داخل `@media (prefers-reduced-motion: no-preference)`؛ ومع تقليل الحركة تتوقف الأورورا لكنها تبقى ظاهرة.
2. عرّف الألوان كمتغيرات CSS (--bg و--fg و--mute و--line و--card و--solid و--acc و--accfg ودرجات الأورورا) ووجّه ألوان Tailwind إليها (مثل colors: {bg: "var(--bg)"}). اكتب القيم الداكنة تحت كل من `:root[data-theme="dark"]` و`@media (prefers-color-scheme: dark) { :root:not([data-theme="light"]) }`، ليُطبَّق مظهر النظام حتى مع تعطيل JavaScript.
3. مبدّل المظهر: سكربت من سطر واحد في `<head>` بعد ملف الأنماط، يقرأ الاختيار المحفوظ من localStorage ويكتب data-theme على `<html>` ويضيف الفئة `js`؛ ولأنه يعمل قبل أول رسم، لا تومض الصفحة بالمظهر الخاطئ أبدًا. غلّف الوصول إلى localStorage بـ try. سكربت صغير في نهاية الصفحة يبدّل المظهر عند النقر ويحفظ الاختيار ويحدّث الزر عند تغيّر مظهر النظام. الزر هو `<button type="button">` حقيقي مع `aria-pressed` صحيح أثناء تفعيل الداكن، ويحتفظ باسمه المتاح للوصول ("Dark theme") حتى حين تظهر الأيقونة فقط على الجوال. أخفِ الزر بدون JavaScript (`html:not(.js) .theme-toggle { display: none }`). أضف أيضًا `<meta name="color-scheme" content="light dark">`.
4. أبقِ البطاقة الزجاجية في فئة `.glass` واحدة: خلفية صلبة أولًا (--solid)، ثم داخل `@supports (backdrop-filter: blur(1px))` خلفية شبه شفافة مع `backdrop-filter: blur(18px) saturate(140%)` (مع البادئة -webkit- لمتصفح Safari). تحت `@media (prefers-reduced-transparency: reduce), (prefers-contrast: more)` تصبح البطاقة صلبة وتُخفى الأورورا. لا تستخدم أداة backdrop-blur في HTML؛ إذ يحذّر design-check من "الزجاجية في كل مكان" عندما يرى أكثر من خمسة منها في الصفحة.
5. قِس التباين في المظهرين معًا. يدقق Lighthouse المظهر الفاتح فقط؛ وإذا لم تفحص الداكن بشكل منفصل، فسيمر النص الباهت في الوضع الداكن دون ملاحظة. اجعل الخلفية شبه الشفافة للبطاقة معتمة بما يكفي ليبقى النص فوق 4.5:1 حتى فوق أسطع ألوان الأورورا (في العرض التجريبي: أبيض بنسبة 66 بالمئة في الفاتح وأخضر داكن بنسبة 58 بالمئة في الداكن). بدّل لون نص زر التمييز حسب المظهر (أبيض على أخضر صنوبري داكن في الفاتح، وأخضر داكن على نعناعي فاتح في الداكن).
6. امنح بطاقة القسم الرئيسي حركة دخولها باستخدام transform فقط وسمة data-reveal (يتعرف design-check على الحركة بهذه السمة)؛ ولا تُخفِ h1 ولا تجعله يتلاشى أبدًا، لأنه عنصر LCP.

الإعداد والمزالق المعروفة (كلٌّ منها كلّف نقاطًا أو أفشل بوابة في قياس العرض التجريبي، فلا تتجاوزها):
1. إذا كان هناك موقع يعمل بالفعل على الخادم، أخبرني أولًا، لأن الإعداد يستبدل index.html ومجلد assets. اعرض معاينة scaffold_site مع confirm=false أولًا، ثم استدعِ confirm=true بعد موافقتي. ثم اقرأ site_design_guide وsite_seo_guide. قبل كتابة الكود، اكتب اتجاه التصميم (الخطوط والألوان والشبكة والعنصر المميز ولغة الحركة والمكتبات التي لن تُحمَّل) في ملف ART.md قصير خارج assets واعرضه عليّ.
2. صرّف Tailwind ولا تحمّله من CDN. ثبّت `npm i -D tailwindcss@3` باستخدام site_run_command مع background=true، وتابعه بـ site_command_status. يجب أن تغطي مسارات content في `tailwind.config.js` كل ملفات HTML بما فيها المجلدات الفرعية وقوالب `_src/*.tpl` وأي ملف JS يكتب فئات. يحتوي `_src/tw.css` على السطر `@import "../assets/app.css";` وسطور `@tailwind` الثلاثة؛ صرّفه إلى ملف واحد بالأمر `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. أزل سكربت cdn.tailwindcss.com وtailwind.config المضمّن وchrome.js وmotion.js من الصفحات، واربط `/assets/site.css` فقط. أعد التصريف بعد كل تعديل على HTML. ولأن ألوان المظهر متغيرات، فإن اختصارات الشفافية في Tailwind (مثل bg-fg/50) لا تعمل؛ عرّف متغيرًا منفصلًا إذا احتجت إلى لون شبه شفاف.
3. استضف الخطوط بنفسك. اقرأ CSS الخاص بـ Fontshare بطلب واحد لكل عائلة ووزن (`https://api.fontshare.com/v2/css?f[]=family@weight`)، ونزّل كل ملف woff2 إلى `assets/fonts/` باستخدام site_fetch واكتب قواعد @font-face مع `font-display: swap` في `assets/app.css`؛ إذ يبحث design-check عن الخط المخصص هناك. نفّذ preload لكل وزن مستخدم في الجزء العلوي المرئي من الصفحة (العناوين والنص والأزرار) في كل صفحة عبر `<link rel="preload" as="font" type="font/woff2" crossorigin>` وضع هذه الأسطر قبل رابط ملف الأنماط. معظم خطوط Fontshare لا تحتوي على رمز ₺، لذا اكتب الأسعار بـ "TL".
4. اجعل القائمة والتذييل HTML ثابتًا. اكتب `chrome-stamp.mjs` صغيرًا يقرأ قائمة التنقل من site.config.js ويختم `_src/header.tpl` و`_src/footer.tpl` بين العلامتين `` و`` في كل صفحة، مع إضافة aria-current="page" إلى الرابط النشط. لا تعطِ القوالب امتداد .html واستخدم عناصر نائبة مثل `[[NAV]]` بدل `{{...}}`. ابنِ قائمة الجوال بـ `<details>` ودون JS. أبقِ اسم النشاط والعنوان والهاتف في التذييل نصًا عاديًا، واجعل روابط التذييل وفتات التنقل بارتفاع 44 بكسل على الأقل.
5. حوّل الصور أثناء تنزيلها بـ site_fetch: اكتب الصورة نفسها في ملفات منفصلة مع resize="480x" و"800x" و"1120x" (أو العروض التي تحتاجها الصفحة) وimage_format="webp" وquality=65. أعطِ كل `<img>` السمات srcset وsizes وwidth وheight بما يطابق النسبة الحقيقية. تحصل الصورة الرئيسية في الجزء العلوي المرئي على fetchpriority="high" ولا تكون lazy؛ وأعطِ fetchpriority لعنصر LCP الحقيقي فقط، وloading="lazy" decoding="async" لبقية الصور.
6. اكتب `favicon.svg` صغيرًا في جذر الموقع وأضف `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` إلى كل صفحة؛ وإذا كان هناك شعار PNG، فأنشئ apple-touch-icon باستخدام site_fetch مع resize="180x180" وimage_format="png". بدون favicon يسجّل المتصفح خطأ 404 لـ /favicon.ico وينخفض Best Practices إلى 96.
7. قواعد مدقق HTML: ابدأ كل مستند بـ `<!DOCTYPE html>` بأحرف كبيرة، وضع السمات بين علامات اقتباس مزدوجة، واستخدم `&nbsp;` للمسافات في النص المرئي لروابط tel:، ولا تستخدم سمة style="" أبدًا (وإذا احتجت إلى متغير CSS فاستخدم فئة خاصية اعتباطية في Tailwind مثل `[--r:-4deg]`)، وأعطِ كل زر type="button"، ولا تضع aria-label على عناصر بلا دور مثل `<ul>` أو `<div>`، واستخدم `<section aria-label="...">` بدل role="region".

SEO وAEO وGEO:
1. استخدم عناوين URL بنمط المجلدات مع شرطة مائلة في النهاية (/ozellikler/ و/guvenlik/ و/iletisim/ و/gizlilik/ أو ما يعادلها بلغتك). املأ كتلة seo في site.config.js ونفّذ `node seo-stamp.mjs`. بالنسبة لشركة برمجيات بلا متجر فعلي، اضبط localBusiness:false في site.config.js. مخططات الصفحات: الرئيسية WebPage وFAQPage؛ الميزات SoftwareApplication (applicationCategory وoperatingSystem وfeatureList) وFAQPage؛ الأمان WebPage وFAQPage؛ التواصل ContactPage؛ وBreadcrumbList في الصفحات الداخلية. لا تدرج شهادة أمان أو وثيقة امتثال لا تملكها؛ وإذا كنت تملكها فاذكر رقمها وتاريخ صلاحيتها. اكتب كل مخطط خاص بصفحة في كتلة `<script type="application/ld+json">` خاصة به واربطه بالرسم الأساسي عبر @id. لا تُدخل BreadcrumbList داخل @graph؛ أبقه في كتلته الخاصة، لأن هذه هي الطريقة الوحيدة التي يراه بها seo-check.
2. العناوين من 48 إلى 60 حرفًا (يعدّ seo-check ما يزيد على 65 خطأ)، والأوصاف من 145 إلى 158 حرفًا، وh1 واحد في كل صفحة. المحتوى الرئيسي لكل صفحة 150 كلمة على الأقل. في العرض التجريبي جاءت صفحتا التواصل والخصوصية بـ 84 و116 كلمة من المحاولة الأولى، واستُكملتا بمعلومات حقيقية مثل "ماذا يحدث خلال التجربة" و"مع من تُشارَك البيانات".
3. تجيب الفقرة الأولى في كل صفحة عن سؤال الصفحة مباشرة، ويُصاغ h1 على شكل هذا السؤال. اكتب الأسئلة الشائعة الخاصة بالصفحة باستخدام `<details>` ووسمها كـ FAQPage. اعرض الجهة الناشرة وتاريخ "آخر تحديث" باستخدام `<time datetime>`.
4. في robots.txt اكتب قرارك مع السبب لكل من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot وCCBot، وأشِر إلى خريطة الموقع. يحتوي sitemap.xml على lastmod حقيقي. يحتوي llms.txt على ملخص دقيق للموقع من جملتين وقائمة بالصفحات المهمة.
5. لا اختلاق: لا تكتب مراجعات أو تقييمات أو جوائز أو أعداد عملاء أو شهادات أو ساعات عمل أو إحداثيات أو أسعارًا أو أرقام منتج دون أن تسألني. اترك أي حقل لا تعرفه خارج المخطط تمامًا.

البوابات (بالترتيب؛ لا تقل "تم" حتى تنجح جميعها):
1. باستخدام site_run_command، نفّذ بالترتيب `node chrome-stamp.mjs` وبناء Tailwind و`node seo-stamp.mjs` و`node seo-check.mjs` (0 أخطاء، 0 تحذيرات) و`node design-check.mjs` (0 أخطاء؛ برّر أي تحذير متبقٍ) و`npx html-validate "**/*.html"` (0 أخطاء).
2. اعرض كل صفحة باستخدام site_preview مع view="mobile" وview="desktop". يلتقط site_preview الصفحة مع إيقاف الحركة؛ وإذا لم يكن المحتوى مكتملًا في تلك اللقطة، فحالة عدم وجود حركة معطلة. قد تظهر الصور lazy في الأسفل فارغة في لقطة الصفحة الكاملة؛ لا تعدّ ذلك خطأ، لكن تحقق من مساراتها. افحص المظهر الداكن أيضًا: ولأن site_preview لا يستطيع تغيير مظهر النظام، نفّذ تدقيق تباين في الوضع الداكن (مثل قاعدة color-contrast في axe-core مع prefers-color-scheme: dark)، أو اجعل الداكن افتراضيًا مؤقتًا واعرضه مرة واحدة.
3. نفّذ core_web_vitals لكل صفحة مع strategy="mobile" وstrategy="desktop". معيار القبول: على الجوال Performance 95 على الأقل وAccessibility وBest Practices وSEO بـ 100؛ وعلى سطح المكتب تكون الأربعة 95 على الأقل والهدف 100. للصفحة التي لا تحقق ذلك، اعثر على الملف البطيء باستخدام resources=true وأصلحه وقِس مجددًا. ثم نفّذ seo_audit على الصفحة الرئيسية مع strategy="mobile" وruns=2. يجب ألا تحتوي قائمة طلبات الشبكة على أي عنوان خارج نطاقك الخاص (روابط المتجر وWhatsApp روابط وليست طلبات).
4. لا تمرير أفقي عند عرض 360 و390 و768 و1440 بكسل، وأهداف اللمس 44 بكسل على الأقل، ولا أخطاء في وحدة التحكم.

فحص التفاعل: ولأن site_preview لا يستطيع تشغيل الحركة أو تبديل المظهر، أخبرني بما يجب أن أراقبه في متصفحي الخاص: الضوء في الخلفية يتحرك ببطء شديد؛ النقر على المبدّل يبدّل المظهر، ويبقى الاختيار عند تغيير الصفحة ولا تومض الصفحة بالمظهر الآخر أثناء التحميل؛ وإذا كان نظام التشغيل في الوضع الداكن يُفتح الموقع داكنًا؛ ومع تفعيل تقليل الحركة تتوقف الأورورا؛ ومع تفعيل تقليل الشفافية تصبح البطاقات صلبة؛ ومع تعطيل JavaScript يُخفى المبدّل لكن مظهر النظام يظل مطبقًا.

بعد النشر: اعرض معاينة القاعدة `/assets/* Cache-Control: public, max-age=31536000, immutable` باستخدام site_headers وطبّقها بعد موافقتي؛ ومن ذلك الحين، غيّر رقم إصدار اسم الملف كلما تغيّر CSS أو JS (site-v2.css وهكذا). أرسل sitemap.xml باستخدام gsc_submit_sitemap وافحص الصفحة الرئيسية باستخدام gsc_url_inspect. في النهاية سلّمني: جدول نقاط لكل صفحة (الصفحة، أربع نقاط للجوال، أربع نقاط لسطح المكتب، LCP، CLS) ونتائج البوابات وقائمة الإصلاحات التي طبّقتها.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقع lookbook للأزياء بانتقالات صفحات View Transitions وGSAP Flip

ينشئ موقع lookbook متعدد الصفحات على خادم الاستضافة الخاص بك، حيث تنمو صورة المنتج من المجموعة إلى صفحة المنتج، ويتم تحريك فلتر المجموعة والعرض السريع باستخدام GSAP Flip. لا توجد عملية دفع، ويحمل كل منتج ترميز Product وOffer، ولا يتم تحميل Flip إلا في صفحة المجموعة بعد الرسم الأول.

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

أنشئ موقعًا متعدد الصفحات بأسلوب اللوك بوك للأزياء أو نمط الحياة، مع انتقالات صور بين الصفحات، لـ [اسم العلامة التجارية] على موقع [اسم الخادم] في خادم الاستضافة الخاص بي على Opus Growth. العلامة التجارية: [ما ينتجه، وأين، ولمن]. اسم الموسم أو المجموعة: [الاسم]. المنتجات: [لكل منها، الاسم والفئة واللون والخامة والسعر ورابط الصورة]. جدول المقاسات: [القياسات، أو "لا يوجد"]. طريقة الشراء: [عنوان الورشة أو المتجر، رقم WhatsApp، رابط المتجر إن وجد]. الشحن والإرجاع: [إن وجد]. التواصل: [البريد الإلكتروني]، [الهاتف]، [العنوان]. النطاق: [النطاق]. صور اللوك بوك: [الروابط].

الصفحات: الصفحة الرئيسية للوك بوك (/)، المجموعة (/koleksiyon/)، صفحة مستقلة لكل منتج (/urun/[اسم-المنتج]/)، الورشة أو من نحن (/atolye/)، التواصل (/iletisim/) و404.html. أقسام الصفحة الرئيسية: الواجهة الرئيسية (h1، تعريف قصير بالعلامة، زران، وصورة رئيسية طويلة)، ثم لوك بوك من ثلاث صور تحتها، حيث تقود كل صورة إلى منتج، وقصة الخامة أو التصنيع، والأسئلة الشائعة. صفحة المجموعة: عوامل تصفية الفئات وشبكة المنتجات. صفحة المنتج: صورة كبيرة، الاسم، السعر، فقرة أولى توضح ما هو المنتج، قائمة بالخامة واللون والمقاسات والعناية، صندوق "كيف أشتري؟"، جدول المقاسات ومنتجان من المجموعة نفسها. لا سلة مشتريات ولا دفع إلكتروني؛ الشراء يتم عبر WhatsApp أو في المتجر أو في الورشة، وتذكر كل صفحة منتج ذلك بوضوح.

الأسلوب: أزياء تحريرية، كأنها لوك بوك مطبوع. خلفية بلون القماش، وصور بعرض كامل بزوايا حادة، وخطوط رفيعة بسماكة 1 بكسل، وتسميات صغيرة بأحرف كبيرة مع تباعد بين الحروف، ومساحات بيضاء واسعة. الخطوط: خط سيريف أنيق عالي التباين من Fontshare (مثل Melodrama بوزني 400 و600) مع خط نص هادئ من نوع grotesk (مثل Archivo بوزني 400 و500). لون مميز واحد (مثل لون الطين) فقط لحلقات التركيز والتمرير. وزّع ثلاثي اللوك بوك على 5 و4 و3 أعمدة من شبكة من 12 عمودًا مع إزاحة رأسية متدرجة. هناك عنصران مميزان: انتقال الصورة بين الصفحات والمعاينة السريعة بـ Flip في شبكة المجموعة. لا يتم تحميل Lenis وSwiper وScrollTrigger وSplitText.

قواعد انتقال الصفحة وFlip (اتبعها حرفيًا):
1. انتقالات View Transitions بين المستندات: اكتب `@view-transition { navigation: auto; }` في `assets/app.css`. صورة بطاقة المجموعة والصورة الرئيسية في صفحة المنتج تحملان نفس view-transition-name؛ حدده بفئة خاصية عشوائية من Tailwind (`[view-transition-name:u-product-name]`)، وليس بـ style="". يمكن أن يظهر كل اسم مرة واحدة فقط في الصفحة، لأن المتصفح يلغي الانتقال عندما يتشارك عنصران الاسم نفسه؛ ويمكن لبطاقات "المجموعة نفسها" في صفحة المنتج أن تحمل أسماء منتجاتها الخاصة. امنح القائمة العلوية `view-transition-name: site-header` لتبقى ثابتة أثناء الانتقال. مدة المجموعة 0.5 ثانية، والتلاشي المتقاطع للجذر 0.3 ثانية. داخل `@media (prefers-reduced-motion: reduce)` اكتب `@view-transition { navigation: none; }`. المتصفحات غير الداعمة تتنقل بشكل عادي ببساطة؛ لا تكتب بديلًا بـ JavaScript.
2. حمّل GSAP وFlip في صفحة المجموعة فقط؛ لا تحتوي أي صفحة أخرى على أي سكربت. نزّل نواة GSAP 3.13 وإضافة Flip من jsdelivr إلى `assets/vendor/` باستخدام site_fetch وثبّت الإصدار. سكربت من سطر واحد في `<head>` يضيف الفئة `js` إلى `<html>`، والفئة `anim` ما لم تكن قيمة prefers-reduced-motion هي "reduce". محمّل صغير في نهاية الصفحة ينتظر حدث load واستدعاءين لـ requestAnimationFrame وrequestIdleCallback، ولا ينزّل شيئًا إذا لم تكن `anim` موجودة، وإلا يضيف gsap.min.js وFlip.min.js وملفًا صغيرًا يحتوي على `gsap.registerPlugin(Flip)` بهذا الترتيب مع async=false.
3. افصل التفاعل عن Flip: يشغّل `assets/koleksiyon.js` (بـ defer) التصفية والمعاينة السريعة بدون Flip أيضًا. عند كل تغيير، إذا كان Flip و`anim` موجودين، التقط أولًا `Flip.getState(cards)`، ثم غيّر DOM، ثم استدع `Flip.from(state, {duration: 0.6, ease: "power3.inOut", nested: true})`؛ وإلا طبّق التغيير فورًا. بهذه الطريقة يستطيع الزائر الذي لا يريد الحركة استخدام التصفية والمعاينة السريعة.
4. التصفية: أزرار "الكل" والفئات داخل حاوية بـ `role="group"` وaria-label، ولكل منها `aria-pressed`. البطاقات غير المطابقة تحصل على `hidden`؛ في Flip استخدم `absolute: true`، وonEnter للبطاقات الداخلة (opacity وscale من 0.92 إلى 1) وonLeave للخارجة. عنصر بـ `aria-live="polite"` يعلن النتيجة، مثل "تم عرض 3 منتجات".
5. المعاينة السريعة (تحويل الصورة من الشبكة إلى التفاصيل): لكل بطاقة زر "نظرة سريعة" مع `aria-expanded` و`aria-controls` ولوحة تفاصيل بـ `hidden` (الوصف، نصيحة تنسيق، رابط إلى صفحة المنتج). عند الفتح تمتد البطاقة بعرض كامل بـ `grid-column: 1 / -1` وتنقسم على سطح المكتب إلى عمودين، الصورة على اليسار والتفاصيل على اليمين؛ ويحرّك Flip نمو الصورة من المربع الصغير إلى العرض الكبير. حدّث `sizes` للصورة المفتوحة للعرض الكبير حتى يتم تحميل ملف أكبر. تُفتح بطاقة واحدة فقط في كل مرة، ويتحول نص الزر إلى "إغلاق" وينتقل التركيز إلى اللوحة التي تحمل tabindex="-1".
6. بدون JavaScript تُخفى أزرار التصفية والمعاينة السريعة (يظهر `.js-only` فقط تحت `.js`)، وتبقى جميع روابط البطاقات وصفحات المنتجات تعمل. الرابط الرئيسي للبطاقة يقود دائمًا إلى صفحة المنتج؛ والمعاينة السريعة زر منفصل.

الإعداد والمزالق المعروفة (كل واحدة منها كلّفت نقاطًا أو فشلت في اختبار أثناء قياس العرض التجريبي، فلا تتجاوزها):
1. إذا كان هناك موقع يعمل بالفعل على الخادم، أخبرني أولًا، لأن الإعداد يستبدل index.html ومجلد assets. اعرض معاينة scaffold_site مع confirm=false أولًا، ثم استدعِه مع confirm=true بعد موافقتي. بعدها اقرأ site_design_guide وsite_seo_guide. قبل كتابة الكود، اكتب اتجاه التصميم (الخطوط، اللون، الشبكة، العنصر المميز، لغة الحركة والمكتبات التي لن تُحمَّل) في ملف ART.md قصير خارج assets واعرضه عليّ.
2. اجعل Tailwind يُترجم ولا تحمّله من CDN. ثبّت `npm i -D tailwindcss@3` باستخدام site_run_command مع background=true، وتابعه بـ site_command_status. يجب أن تغطي مسارات content في `tailwind.config.js` كل ملفات HTML بما فيها المجلدات الفرعية وقوالب `_src/*.tpl` وأي ملف JS يكتب فئات. يحتوي `_src/tw.css` على السطر `@import "../assets/app.css";` وأسطر `@tailwind` الثلاثة؛ ترجمه إلى ملف واحد بالأمر `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. أزل من الصفحات سكربت cdn.tailwindcss.com وtailwind.config المضمّن وchrome.js وmotion.js، واربط `/assets/site.css` فقط. أعد الترجمة بعد كل تعديل على HTML. أضف `assets/koleksiyon.js` إلى قائمة content أيضًا، لأنه يكتب فئات مثل `is-open`.
3. استضف الخطوط ذاتيًا. اقرأ CSS الخاص بـ Fontshare بطلب واحد لكل عائلة ووزن (`https://api.fontshare.com/v2/css?f[]=family@weight`)، ونزّل كل ملف woff2 إلى `assets/fonts/` باستخدام site_fetch واكتب قواعد @font-face مع `font-display: swap` في `assets/app.css`؛ إذ يبحث design-check عن الخط المخصص هناك. حمّل مسبقًا (preload) كل وزن مستخدم في الجزء الظاهر من الصفحة (العنوان والنص والأزرار) في كل صفحة باستخدام `<link rel="preload" as="font" type="font/woff2" crossorigin>` وضع هذه الأسطر قبل رابط ملف الأنماط. معظم خطوط Fontshare لا تحتوي على رمز ₺، لذا اكتب الأسعار بـ "TL".
4. اجعل القائمة والتذييل HTML ثابتًا. اكتب `chrome-stamp.mjs` صغيرًا يقرأ قائمة التنقل من site.config.js ويختم `_src/header.tpl` و`_src/footer.tpl` بين العلامتين `` و`` في كل صفحة، مع إضافة aria-current="page" إلى الرابط النشط. لا تمنح القوالب الامتداد .html واستخدم عناصر نائبة مثل `[[NAV]]` بدلًا من `{{...}}`. ابنِ قائمة الجوال بـ `<details>` ودون JS. أبقِ اسم النشاط والعنوان والهاتف في التذييل كنص عادي، واجعل ارتفاع روابط التذييل ومسار التنقل 44 بكسل على الأقل.
5. حوّل الصور أثناء تنزيلها بـ site_fetch: احفظ الصورة نفسها في ملفات منفصلة مع resize="480x" و"800x" و"1120x" (أو العروض التي تحتاجها الصفحة)، وimage_format="webp" وquality=65. امنح كل `<img>` الخصائص srcset وsizes وwidth وheight بما يطابق النسبة الفعلية. الصورة الرئيسية في الجزء الظاهر من الصفحة تحصل على fetchpriority="high" وليست lazy؛ امنح fetchpriority فقط لعنصر LCP الحقيقي، وloading="lazy" decoding="async" لبقية الصور.
6. اكتب ملف `favicon.svg` صغيرًا في جذر الموقع وأضف `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` إلى كل صفحة؛ وإذا كان هناك شعار PNG، فأنشئ apple-touch-icon باستخدام site_fetch مع resize="180x180" وimage_format="png". بدون favicon يسجل المتصفح خطأ 404 لـ /favicon.ico وتنخفض الممارسات الفضلى إلى 96.
7. قواعد مدقق HTML: ابدأ كل مستند بـ `<!DOCTYPE html>` بأحرف كبيرة، واجعل قيم السمات بين علامتي اقتباس مزدوجتين، واستخدم `&nbsp;` للمسافات في النص المرئي لروابط tel:، ولا تستخدم سمة style="" أبدًا (إذا احتجت متغير CSS فاستخدم فئة خاصية عشوائية من Tailwind مثل `[--r:-4deg]`)، وامنح كل زر type="button"، ولا تضع aria-label على عناصر بلا role مثل `<ul>` أو `<div>`، واستخدم `<section aria-label="...">` بدلًا من role="region".
8. نزّل صور المنتجات بـ site_fetch بنسبة عمودية 4:5 مع resize="400x" و"640x" و"960x"؛ وأبقِ كل صور المنتجات بالنسبة نفسها لتبقى الشبكة متناسقة ولا يقفز انتقال Flip. الصورة الرئيسية في صفحة المنتج هي عنصر LCP لتلك الصفحة وتحصل على fetchpriority="high".
9. افحص أرقام خط العرض: في العرض التجريبي كان الصفر في Melodrama مشطوبًا وبدا "2026" في h1 من بعيد كأنه "2Ø26". أبقِ الأرقام خارج العناوين المكتوبة بخط العرض، أو اضبط الأرقام بخط النص.

SEO وAEO وGEO:
1. استخدم عناوين URL بنمط المجلدات مع شرطة مائلة في النهاية (/koleksiyon/ و/urun/[اسم-المنتج]/ و/atolye/ و/iletisim/ أو ما يقابلها بلغتك). املأ كتلة seo في site.config.js ثم شغّل `node seo-stamp.mjs`. إذا كانت هناك ورشة أو متجر فعلي، فحدد في site.config.js أدق businessType (مثل ClothingStore) والعنوان؛ وأضف ساعات العمل فقط إذا زودتك بها. مخططات الصفحات: الرئيسية WebPage وFAQPage؛ المجموعة CollectionPage وItemList لكل url منتج؛ كل صفحة منتج ItemPage وProduct (name وdescription وimage وsku وcolor وmaterial وcategory وbrand وOffer مع price وpriceCurrency TRY وavailability وitemCondition وurl وseller @id)؛ الورشة AboutPage؛ التواصل ContactPage؛ وBreadcrumbList في الصفحات الداخلية (اللوك بوك، المجموعة، المنتج). حتى بدون دفع إلكتروني تحمل Offer السعر الصحيح وحالة المخزون؛ وإذا زودتك بشروط الشحن والإرجاع، فأضف shippingDetails وhasMerchantReturnPolicy إلى Offer. لا تختلق تقييمات أو درجات (aggregateRating). اكتب كل مخطط خاص بصفحة في كتلة `<script type="application/ld+json">` مستقلة واربطه بالرسم الأساسي عبر @id. لا تضع BreadcrumbList داخل @graph؛ أبقِه في كتلته المستقلة، لأن هذه هي الطريقة الوحيدة التي يراه بها seo-check.
2. العناوين من 48 إلى 60 حرفًا (يعدّ seo-check ما يزيد على 65 خطأً)، والأوصاف من 145 إلى 158 حرفًا، وh1 واحد في كل صفحة. المحتوى الرئيسي لكل صفحة 150 كلمة على الأقل. في العرض التجريبي جاءت صفحتا الورشة والتواصل بـ 113 و95 كلمة في المحاولة الأولى، وتم استكمالهما بمعلومات حقيقية مثل "ماذا نفعل في الورشة" و"ما الذي تضمّنه عند مراسلتنا". في صفحات المنتجات، اكتب الجمل المشتركة (العناية، القماش) كعناصر قائمة قصيرة واكتب الوصف بشكل منفصل لكل منتج؛ يحذّر seo-check من المحتوى المكرر عندما تتشارك الصفحات أكثر من 50 بالمئة من جملها.
3. الفقرة الأولى في كل صفحة تجيب مباشرة عن سؤال الصفحة، ويُصاغ h1 على شكل هذا السؤال. اكتب الأسئلة الشائعة الخاصة بالصفحة بـ `<details>` وعلّمها بوصفها FAQPage. اعرض الجهة الناشرة وتاريخ "آخر تحديث" باستخدام `<time datetime>`.
4. في robots.txt، اكتب قرارك مع السبب لكل من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot وCCBot، وأشر إلى خريطة الموقع. يحتوي sitemap.xml على lastmod حقيقي. يحتوي llms.txt على ملخص دقيق للموقع في جملتين وقائمة بالصفحات المهمة.
5. لا اختلاق: لا تكتب تقييمات أو درجات أو جوائز أو أعداد عملاء أو شهادات أو ساعات عمل أو إحداثيات أو أسعارًا أو أرقام منتجات دون أن تسألني. اترك أي حقل لا تعرفه خارج المخطط تمامًا.

البوابات (بالترتيب؛ لا تقل "تم" قبل اجتيازها جميعًا):
1. باستخدام site_run_command، شغّل بالترتيب `node chrome-stamp.mjs` وترجمة Tailwind و`node seo-stamp.mjs` و`node seo-check.mjs` (0 أخطاء، 0 تحذيرات) و`node design-check.mjs` (0 أخطاء؛ برّر أي تحذير متبقٍ) و`npx html-validate "**/*.html"` (0 أخطاء).
2. شاهد كل صفحة باستخدام site_preview مع view="mobile" وview="desktop". يلتقط site_preview الصفحة مع إيقاف الحركة؛ فإذا لم يكن المحتوى مكتملًا في تلك اللقطة، فحالة عدم الحركة معطلة. قد تظهر الصور lazy في أسفل الصفحة فارغة في لقطة الصفحة الكاملة؛ لا تعدّ ذلك خطأً، لكن افحص مساراتها.
3. شغّل core_web_vitals لكل صفحة مع strategy="mobile" وstrategy="desktop". معيار القبول: على الجوال Performance لا تقل عن 95 وإمكانية الوصول والممارسات الفضلى وSEO عند 100؛ وعلى سطح المكتب جميعها لا تقل عن 95 والهدف 100. للصفحة التي لا تحقق ذلك، ابحث عن الملف البطيء باستخدام resources=true وأصلحه وأعد القياس. ثم شغّل seo_audit على الصفحة الرئيسية مع strategy="mobile" وruns=2. يجب ألا تحتوي قائمة طلبات الشبكة على أي عنوان خارج نطاقك الخاص (روابط المتجر وWhatsApp هي روابط وليست طلبات).
4. لا تمرير أفقي عند عرض 360 و390 و768 و1440 بكسل، وأهداف اللمس 44 بكسل على الأقل، ولا أخطاء في وحدة التحكم.

فحص التفاعل: بما أن site_preview لا يستطيع إظهار الحركة، أخبرني بما يجب أن أراقبه في متصفحي: في Chrome أو Edge، يؤدي النقر على منتج في المجموعة إلى نمو الصورة من بطاقتها إلى موضعها في صفحة المنتج بينما تبقى القائمة ثابتة؛ وفي Firefox تُفتح الصفحة ببساطة؛ وعند الضغط على عامل تصفية تنزلق البطاقات إلى ترتيب جديد؛ و"نظرة سريعة" تفتح البطاقة داخل الشبكة وتنمو الصورة؛ ومع تفعيل تقليل الحركة تحدث الإجراءات نفسها فورًا؛ ومع إيقاف JavaScript يظهر كل منتج. وفي فحص محلي رأيت أيضًا أن `document.documentElement.matches(':active-view-transition')` تعيد true في صفحة المنتج أثناء الانتقال؛ يمكنك تشغيل الفحص نفسه.

بعد النشر: اعرض معاينة القاعدة `/assets/* Cache-Control: public, max-age=31536000, immutable` باستخدام site_headers وطبّقها بعد موافقتي؛ ومن ثم غيّر إصدار اسم الملف كلما تغيّر CSS أو JS (site-v2.css وهكذا). أرسل sitemap.xml باستخدام gsc_submit_sitemap وافحص الصفحة الرئيسية باستخدام gsc_url_inspect. في النهاية زودني بـ: جدول نتائج لكل صفحة (الصفحة، أربع نتائج للجوال، أربع نتائج لسطح المكتب، LCP، CLS)، ونتائج البوابات، وقائمة الإصلاحات التي طبّقتها.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ موقع شركة ناشئة بأسلوب النيو-بروتاليزم: حدود سميكة، ظلال حادة، شارات ملصقات، بدون JS

ينشئ موقعًا لمنتجك على خادم الاستضافة الخاص بك بحدود سوداء سميكة وظلال حادة وألوان زاهية مسطحة وشارات على شكل ملصقات. تُختار الألوان بالاعتماد على جدول تباين، وتستخدم إزاحات التمرير المرحة transform فقط، ويُقاس الموقع صفحة بصفحة حتى يبلغ 100 دون أي JavaScript.

متى تستخدمهعندما تريد موقعًا لافتًا وجريء الألوان لتطبيقك أو شركتك الناشئة، ويظل سريعًا وسهل القراءة للجميع.

ابنِ موقع منتج بأسلوب النيو-بروتاليزم، متعدد الصفحات وخاليًا من JavaScript، لـ [اسم المنتج أو الشركة الناشئة] على موقع [اسم الخادم] في خادم الاستضافة الخاص بي لدى Opus Growth. المنتج: [ما يفعله ولمن]. كيف يعمل: [ثلاث خطوات]. أبرز الميزات: [من 4 إلى 6 ميزات]. الأسعار: [أسماء الباقات وأسعارها، أو "لا توجد صفحة أسعار"]. روابط التنزيل أو التسجيل: [App Store أو Google Play أو URL للتسجيل]. التواصل: [البريد الإلكتروني]، [الهاتف]، [رقم WhatsApp]، [العنوان]. النطاق: [النطاق]. ألوان العلامة التجارية: [الألوان، أو "اختر أنت"]. صور أو لقطات شاشة حقيقية: [روابط، أو "لا يوجد"].

الصفحات: الرئيسية (/)، كيف يعمل (/nasil-calisir/ أو /how-it-works/)، الأسعار (/fiyat/)، من نحن (/hakkimizda/)، تواصل معنا (/iletisim/)، الخصوصية (/gizlilik/) و404.html. أقسام الصفحة الرئيسية بالترتيب: القسم الرئيسي hero (h1، مقدمة من جملتين، زران، شارات على شكل ملصقات والعنصر المميز)، شريط الفئات، ثلاث خطوات، لمن هو (مع صورة)، الميزات، الأسئلة الشائعة ودعوة ختامية لاتخاذ إجراء. لا نموذج في صفحة التواصل؛ بدلًا منه البريد الإلكتروني والهاتف ورابط WhatsApp برسالة معبأة مسبقًا وروابط التنزيل، لأن الخادم يقدّم الملفات الثابتة فقط.

الأسلوب: نيو-بروتاليزم، لكن بطابع منتج لا لعبة. حدود سوداء سميكة (3 بكسل)، ظلال حادة بلا تمويه (سوداء فقط، بإزاحة 4 و6 و10 بكسل)، كتل ألوان مسطحة زاهية (خمسة ألوان مسطحة كحد أقصى، مثل الطماطم والليموني والنعناعي والأزرق السماوي والليلكي على خلفية كريمية)، شارات مائلة قليلًا تبدو كالملصقات. الخطوط: خط عرض سميك وذو شخصية من Fontshare (مثل Chubbo) مع خط غروتيسك هادئ للنص (مثل Supreme بوزني 400 و700). بلا تدرجات لونية، بلا تأثير زجاجي، بلا ظلال ناعمة وبلا مزج من البنفسجي إلى الأزرق. لا يحتوي الموقع على أي JavaScript؛ لا يتم تحميل GSAP وLenis وSwiper. العنصر المميز: على يمين قسم hero، بطاقة بحدود سميكة ترسم الشاشة الرئيسية للمنتج بـ HTML حقيقي بدلًا من صورة (مثل مصروفات أسرة هذا الشهر وتسوية نهاية الشهر)، مع ملصقات ملصوقة حولها.

قواعد اللون والتباين والحركة (حيث يخسر هذا الأسلوب النقاط بأسهل صورة):
1. اكتب النص بالأسود على كل خلفية ملونة ولا تستخدم النص الأبيض أبدًا. احسب نسبة التباين لكل لون مقابل الأسود وضعها في ART.md على شكل جدول؛ وأغمِق أي لون أقل من 4.5. في العرض التجريبي كانت أدنى نسبة 6.7 على البرتقالي الطماطمي، وبلغت إمكانية الوصول 100 في كل صفحة.
2. اجعل حلقة التركيز 3 بكسل من الأسود بإزاحة 3 بكسل، وتتحول إلى الأصفر الليموني في تذييل أسود. استخدم outline-offset حتى لا تندمج حلقة التركيز مع الحد السميك.
3. نفّذ الإزاحة المرحة للأزرار والبطاقات بـ transform وbox-shadow فقط: عند التمرير translate(-2px, -2px) وظل أكبر، وعند الضغط translate(4px, 4px) وبلا ظل. ارتفاع الأزرار 48 بكسل على الأقل، والأزرار الصغيرة 44 على الأقل.
4. ضع ميل الملصقات في الخاصية المنفصلة `rotate` لا في transform، وحدد الزاوية بفئة خاصية اعتباطية من Tailwind مثل `[--r:-4deg]`. بهذه الطريقة تبقى الملصقات مائلة حتى عندما تعيد قاعدة reduced-motion ضبط transform، ولا حاجة إلى سمة style="".
5. نفّذ دخول "slap on" للملصقات بـ `scale` و`translate` فقط، داخل `@media (prefers-reduced-motion: no-preference)` ومع السمة data-reveal="slap" (يتعرف design-check على الحركة من هذه السمة). بلا إخفاء بـ opacity، ولا يتحرك h1 أبدًا. مع prefers-reduced-motion: reduce تتوقف كل الرسوم المتحركة والانتقالات.
6. ضع aria-hidden="true" على الملصقات الزخرفية؛ أما الشارات التي تحمل معلومة (مثل "مجاني حتى 6 أشخاص") فتبقى عناصر قائمة عادية. على الجوال، أخفِ الملصق الزخرفي تحت 640 بكسل إذا تداخل مع شارة أخرى عند زاوية البطاقة؛ في العرض التجريبي غطّى ملصق "تمت إضافة الإيصال" شارة "3 أشخاص" عند 390 بكسل.

الإعداد والمزالق المعروفة (كلٌّ منها كلّف نقاطًا أو أخفق في بوابة أثناء قياس العرض التجريبي، لا تتجاوزها):
1. إذا كان هناك موقع يعمل بالفعل على الخادم، أخبرني أولًا، لأن الإعداد يستبدل index.html ومجلد assets. اعرض معاينة لـ scaffold_site مع confirm=false أولًا، ثم استدعِ confirm=true بعد موافقتي. بعد ذلك اقرأ site_design_guide وsite_seo_guide. قبل كتابة الكود، اكتب اتجاه التصميم (الخطوط، اللون، الشبكة، العنصر المميز، لغة الحركة والمكتبات التي لن تُحمَّل) في ملف ART.md قصير خارج assets واعرضه عليّ.
2. قم بتجميع Tailwind ولا تحمّله من CDN. ثبّت `npm i -D tailwindcss@3` باستخدام site_run_command مع background=true، وتابعه بـ site_command_status. يجب أن تغطي مسارات content في `tailwind.config.js` كل ملفات HTML بما فيها المجلدات الفرعية وقوالب `_src/*.tpl` وأي ملف JS يكتب فئات. يحتوي `_src/tw.css` على السطر `@import "../assets/app.css";` وأسطر `@tailwind` الثلاثة؛ جمّعه في ملف واحد بالأمر `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. أزل من الصفحات سكربت cdn.tailwindcss.com وtailwind.config المضمّن وchrome.js وmotion.js، واربط `/assets/site.css` فقط. أعد التجميع بعد كل تعديل على HTML. هذا الموقع لا يحتوي على ملفات JavaScript، لذا لا تحتاج قائمة content إلى مدخلات JS.
3. استضف الخطوط بنفسك. اقرأ CSS من Fontshare بطلب واحد لكل عائلة ووزن (`https://api.fontshare.com/v2/css?f[]=family@weight`)، ونزّل كل ملف woff2 في `assets/fonts/` باستخدام site_fetch واكتب قواعد @font-face مع `font-display: swap` في `assets/app.css`؛ يبحث design-check عن الخط المخصص هناك. نفّذ preload لكل الأوزان المستخدمة في الجزء الظاهر قبل التمرير (العنوان والنص والأزرار) في كل صفحة بـ `<link rel="preload" as="font" type="font/woff2" crossorigin>` وضع هذه الأسطر قبل رابط ورقة الأنماط. معظم خطوط Fontshare لا تحتوي على رمز ₺، لذا اكتب الأسعار بـ "TL".
4. اجعل القائمة والتذييل HTML ثابتًا. اكتب `chrome-stamp.mjs` صغيرًا يقرأ قائمة التنقل من site.config.js ويختم `_src/header.tpl` و`_src/footer.tpl` بين العلامتين `` و`` في كل صفحة، ويضيف aria-current="page" إلى الرابط النشط. لا تعطِ القوالب امتداد .html واستخدم عناصر نائبة مثل `[[NAV]]` بدلًا من `{{...}}`. ابنِ قائمة الجوال بـ `<details>` وبدون JS. أبقِ اسم النشاط والعنوان والهاتف في التذييل كنص عادي، واجعل ارتفاع روابط التذييل وروابط breadcrumb 44 بكسل على الأقل.
5. حوّل الصور أثناء تنزيلها باستخدام site_fetch: اكتب الصورة نفسها في ملفات منفصلة مع resize="480x" و"800x" و"1120x" (أو العروض التي تحتاجها الصفحة)، وimage_format="webp" وquality=65. امنح كل `<img>` السمات srcset وsizes وwidth وheight بما يطابق النسبة الحقيقية. تحصل الصورة الرئيسية في الجزء الظاهر قبل التمرير على fetchpriority="high" ولا تكون lazy؛ أعطِ fetchpriority لعنصر LCP الحقيقي فقط، وloading="lazy" decoding="async" لبقية الصور.
6. اكتب `favicon.svg` صغيرًا في جذر الموقع وأضف `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` إلى كل صفحة؛ وإذا كان هناك شعار PNG، فأنشئ apple-touch-icon باستخدام site_fetch مع resize="180x180" وimage_format="png". بدون favicon يسجّل المتصفح خطأ 404 لـ /favicon.ico وينخفض Best Practices إلى 96.
7. قواعد مدقّق HTML: ابدأ كل مستند بـ `<!DOCTYPE html>` بأحرف كبيرة، وضع السمات بين علامات اقتباس مزدوجة، واستخدم `&nbsp;` للمسافات في النص المرئي لروابط tel:، ولا تستخدم سمة style="" أبدًا (إذا احتجت إلى متغير CSS فاستخدم فئة خاصية اعتباطية من Tailwind مثل `[--r:-4deg]`)، وأعطِ كل زر type="button"، ولا تضع aria-label على عناصر بلا role مثل `<ul>` أو `<div>`، واستخدم `<section aria-label="...">` بدلًا من role="region".
8. إذا كان تذييل الصفحة بخلفية سوداء، فاجعل روابطه كريمية مع تمرير ليموني، وأبقِ ارتفاع كل منها 44 بكسل على الأقل.

SEO وAEO وGEO:
1. استخدم عناوين URL بنمط المجلدات مع شرطة مائلة في النهاية (/nasil-calisir/ و/fiyat/ و/hakkimizda/ و/iletisim/ و/gizlilik/ أو ما يقابلها بلغتك). املأ كتلة seo في site.config.js ونفّذ `node seo-stamp.mjs`. بالنسبة لشركة ناشئة بلا متجر فعلي، اضبط localBusiness:false في site.config.js. مخططات الصفحات: الرئيسية WebPage وFAQPage؛ كيف يعمل WebPage وFAQPage؛ الأسعار SoftwareApplication (مع applicationCategory وoperatingSystem وOffer لكل باقة) وFAQPage؛ من نحن AboutPage؛ التواصل ContactPage؛ وBreadcrumbList في الصفحات الداخلية. بما أنك لن تضيف مراجعات أو تقييمات للمستخدمين إلى SoftwareApplication، فقد لا تعرض Google نتيجة غنية للتطبيق؛ لا بأس بذلك، لا تختلق تقييمًا. اكتب كل مخطط خاص بصفحة في كتلة `<script type="application/ld+json">` خاصة به واربطه بالرسم الأساسي عبر @id. لا تضع BreadcrumbList داخل @graph؛ أبقِه في كتلة منفصلة، لأن هذه هي الطريقة الوحيدة التي يراه بها seo-check.
2. العناوين من 48 إلى 60 حرفًا (يعتبر seo-check ما يزيد على 65 خطأ)، والأوصاف من 145 إلى 158 حرفًا، وh1 واحد لكل صفحة. المحتوى الرئيسي لكل صفحة 150 كلمة على الأقل. في العرض التجريبي جاءت صفحات من نحن والتواصل والخصوصية بين 113 و148 كلمة من المحاولة الأولى؛ أضف إليها معلومات حقيقية، مثل "ما الذي يجب تضمينه في طلب الدعم" أو "مع من تُشارك البيانات".
3. تجيب الفقرة الأولى في كل صفحة مباشرةً عن سؤال الصفحة، ويُصاغ h1 على هيئة هذا السؤال. اكتب الأسئلة الشائعة الخاصة بالصفحة بـ `<details>` ووسمها كـ FAQPage. أظهر الجهة الناشرة وتاريخ "آخر تحديث" بـ `<time datetime>`.
4. في robots.txt، اكتب قرارك مع السبب لكل من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot وCCBot، وأشِر إلى خريطة الموقع. يحتوي sitemap.xml على lastmod حقيقي. يحتوي llms.txt على ملخص دقيق للموقع من جملتين وقائمة بالصفحات المهمة.
5. لا اختلاق: لا تكتب مراجعات أو تقييمات أو جوائز أو أعداد عملاء أو شهادات أو ساعات عمل أو إحداثيات أو أسعارًا أو أرقام منتج دون أن تسألني. اترك أي حقل لا تعرفه خارج المخطط تمامًا.

البوابات (بالترتيب؛ لا تقل "تم" حتى تنجح جميعها):
1. باستخدام site_run_command، نفّذ بالترتيب `node chrome-stamp.mjs` وبناء Tailwind و`node seo-stamp.mjs` و`node seo-check.mjs` (0 أخطاء، 0 تحذيرات) و`node design-check.mjs` (0 أخطاء؛ برّر أي تحذير متبقٍ) و`npx html-validate "**/*.html"` (0 أخطاء).
2. اعرض كل صفحة باستخدام site_preview مع view="mobile" وview="desktop". يلتقط site_preview الصفحة والحركة متوقفة؛ وإذا لم يكن المحتوى مكتملًا في هذه اللقطة، فحالة عدم الحركة معطّلة. قد تظهر الصور الكسولة في الأسفل فارغة في لقطة الصفحة الكاملة؛ لا تعدّ ذلك خطأ، لكن تحقق من مساراتها.
3. نفّذ core_web_vitals لكل صفحة مع strategy="mobile" وstrategy="desktop". معيار القبول: على الجوال أن يكون Performance 95 على الأقل وAccessibility وBest Practices وSEO بقيمة 100؛ وعلى سطح المكتب أن تكون الأربعة 95 على الأقل، والهدف 100. للصفحة التي لا تحقق ذلك، ابحث عن الملف البطيء باستخدام resources=true وأصلحه وقِس مجددًا. ثم نفّذ seo_audit على الصفحة الرئيسية مع strategy="mobile" وruns=2. يجب ألا تحتوي قائمة طلبات الشبكة على أي عنوان خارج نطاقك (روابط المتجر وWhatsApp روابط وليست طلبات).
4. لا تمرير أفقي عند عرض 360 و390 و768 و1440 بكسل، وأهداف اللمس 44 بكسل على الأقل، ولا أخطاء في وحدة التحكم.

فحص التفاعل: بما أن site_preview لا يستطيع عرض الحركة، أخبرني بما يجب أن أراقبه في متصفحي: يرتفع الزر إلى الأعلى واليسار عند التمرير ويغوص في ظله عند الضغط؛ تُلصق الملصقات بلطف أثناء تحميل الصفحة؛ يظهر التنقل بمفتاح Tab حلقة تركيز سوداء سميكة على كل رابط؛ وعند تفعيل تقليل الحركة في نظام التشغيل لا يتحرك شيء لكن الملصقات تبقى مائلة؛ ومع إيقاف JavaScript تظل قائمة الجوال تُفتح.

بعد النشر: اعرض معاينة للقاعدة `/assets/* Cache-Control: public, max-age=31536000, immutable` باستخدام site_headers وطبّقها بعد موافقتي؛ ومن ثم غيّر إصدار اسم الملف كلما تغيّر CSS أو JS (site-v2.css وهكذا). أرسل sitemap.xml باستخدام gsc_submit_sitemap وافحص الصفحة الرئيسية باستخدام gsc_url_inspect. في النهاية أعطني: جدول نقاط لكل صفحة (الصفحة، أربع نقاط للجوال، أربع نقاط لسطح المكتب، LCP، CLS)، ونتائج البوابات، وقائمة الإصلاحات التي طبّقتها.

الموقع الإلكترونييجري تغييرات بعد موافقتكعرض تجريبي مباشر

أنشئ صفحة D2C لمنتج واحد: عرض ثلاثي الأبعاد، ومحدد ألوان بلا إزاحة في التخطيط، وشريط شراء ثابت

ينشئ صفحة بيع مباشر للمستهلك لمنتج واحد على خادم استضافتك: عرضًا ثلاثي الأبعاد بـ CSS يميل مع حركة الماوس، ومحدد ألوان بلا JavaScript لا يزيح التخطيط أبدًا، وجداول للمواصفات ومقارنة الطرازات، وقسمًا للأسئلة الشائعة، وشريط شراء ثابتًا على الجوال. وتُوسَم الصفحة بـ ProductGroup وOffer وسياسة الإرجاع وFAQPage، وتُقاس كل صفحة قبل التسليم.

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

أنشئ صفحة منتج مباشرة للمستهلك مع بضع صفحات داعمة لـ [اسم العلامة التجارية]، وهي علامتي التجارية ذات المنتج الواحد، على موقع [اسم الخادم] في خادم استضافة Opus Growth الخاص بي. المنتج: [اسم المنتج، وماذا يفعل، ولمن]. السعر: [السعر]. الألوان أو الخيارات: [لكل خيار اسم ورمز لون ورابط صورة مأخوذة من الزاوية نفسها وعلى اللوحة نفسها]. المواصفات: [الأبعاد والمادة والوزن وأرقام الأداء مع ظروف اختبارها]. الطرازات للمقارنة: [طرازاتك الأخرى وأرقامها]. رابط الشراء: [URL المتجر ومعامل الخيار]. الشحن والإرجاع والضمان: [المدد والشروط]. التواصل: [البريد الإلكتروني]، [الهاتف]، [رقم WhatsApp]، [العنوان]. النطاق: [النطاق].

الصفحات: الصفحة الرئيسية للمنتج (/)، والضمان والإرجاع (/garanti-ve-iade/)، والتواصل (/iletisim/)، والخصوصية (/gizlilik/)، و404.html. أقسام الصفحة الرئيسية بالترتيب: القسم الرئيسي (عرض ثلاثي الأبعاد على اليسار؛ وعلى اليمين تسمية وh1 ومقدمة من جملتين والسعر ومحدد الألوان وزر الشراء وملخص للشحن والإرجاع والضمان)، وثلاثة أقسام قصيرة عن طريقة عمل المنتج، وجدول المواصفات (#ozellikler)، وجدول مقارنة الأحجام أو الطرازات (#karsilastir)، والأسئلة الشائعة (#sss). تربط القائمة بهذه الأقسام داخل الصفحة نفسها إضافة إلى صفحتي الضمان والتواصل. لا توجد في هذا الموقع سلة تسوق ولا صفحة دفع؛ يوجه زر الشراء إلى صفحة المتجر مع الخيار المحدد، وتذكر الصفحة ذلك بوضوح.

الأسلوب: صفحة منتج نظيفة وعصرية مباشرة للمستهلك. خلفية بيضاء دافئة مائلة للكريمي، ولون واحد للعلامة يتناسب مع المنتج، وزر شراء أسود بحواف دائرية، وجداول نظيفة. الخطوط: خط عناوين Grotesk محكم من Fontshare (مثل Familjen Grotesk بوزني 500 و700) مع خط نص مقروء (مثل Ranade بوزني 400 و500). صورة المنتج هي النجمة؛ احتفظ بالجرأة للعرض ثلاثي الأبعاد. لا يتم تحميل GSAP وLenis وSwiper؛ وجافاسكريبت الوحيد هو سكربت مضمّن حجمه أقل من 1 KB يميل العرض.

قواعد العرض ثلاثي الأبعاد ومحدد الألوان وشريط الشراء (اتبعها حرفيًا):
1. ابنِ العرض ثلاثي الأبعاد بـ CSS: `perspective: 1100px` على الحاوية، و`transform: rotateX(var(--rx, 3deg)) rotateY(var(--ry, -7deg))` و`transform-style: preserve-3d` على البطاقة الداخلية، وانتقال للـ transform مدته 0.3 ثانية. بدون جافاسكريبت وعلى شاشات اللمس تبقى البطاقة في هذه الوضعية المائلة قليلًا. تطفو شارتان صغيرتان (مثل السعة ورقم أداء) أمام البطاقة بـ `translateZ(60px)` وتكونان aria-hidden؛ والمعلومات نفسها موجودة أيضًا في النص. ضع إضاءة ناعمة تتبع المؤشر فوق الصورة (radial-gradient تتحكم فيه --gx و--gy).
2. السكربت المسؤول عن الميل مضمّن في نهاية الصفحة ويعمل فقط عندما يتحقق `matchMedia("(pointer: fine) and (prefers-reduced-motion: no-preference)")`. عند pointermove يحوّل موضع المؤشر داخل البطاقة إلى قيمة من -0.5 إلى 0.5، ويضبط --ry بحد أقصى 8 و--rx بحد أقصى 6 درجات، ويحدّ من عمليات الكتابة بـ requestAnimationFrame؛ وعند pointerleave يزيل المتغيرات ويعود إلى الوضعية الافتراضية. يتغير الـ transform فقط ولا يتحرك التخطيط أبدًا. أضف الخاصية data-reveal="tilt" إلى حاوية العرض ليتعرف design-check على الحركة.
3. ابنِ محدد الألوان بدون جافاسكريبت: داخل `<fieldset>` و`<legend>`، عنصر `<input type="radio" name="colour">` حقيقي لكل خيار داخل `<label>` بحجم 44x44 بكسل؛ يكون الـ radio مخفيًا بصريًا (sr-only)، وتحصل نقطة اللون على حلقة مزدوجة عبر `input:checked + .dot` وعلى حلقة تركيز عبر `input:focus-visible + .dot`؛ وتغيّر مفاتيح الأسهم اللون. توضع جميع صور الخيارات فوق بعضها في صندوق `aspect-ratio` نفسه مع `position: absolute; inset: 0`، ويتغير `opacity` فقط، فلا يتحرك التخطيط عند تغيير اللون (CLS يساوي 0 في العرض التجريبي). اعكس الاختيار باستخدام `.product:has(#r-colour:checked)` على الصورة، واسم اللون في الـ legend، ورابط الشراء. إذا كان المتصفح لا يدعم :has، تبقى صورة الخيار الافتراضي واسمه ورابطه ظاهرة.
4. صورة الخيار الافتراضي هي عنصر LCP: fetchpriority="high" وبدون lazy. تحصل صور الخيارات الأخرى على loading="lazy" decoding="async". يجب أن تُلتقط صور الخيارات من الزاوية نفسها وعلى اللوحة نفسها وبالاقتصاص نفسه؛ وإلا فسيقفز المنتج عند تغيير اللون. اسألني عن ذلك بدلًا من محاولة مطابقة صور بزوايا مختلفة عبر الاقتصاص.
5. لا تدع قيمة `display` في فئة زر مثل `.btn-buy` تتجاوز ظهور روابط الشراء الخاصة بالخيارات. في العرض التجريبي تم تجاوز القاعدة `.vb { display: none }` بواسطة `.btn-buy { display: inline-flex }` الواردة بعدها، فظهرت أزرار الشراء الأربعة معًا؛ اكتب القاعدة بمحدد أكثر تحديدًا مثل `.product :is(.vb)` وتحقق في المتصفح من أن زرًا واحدًا فقط يظهر.
6. شريط شراء ثابت على الجوال: أقل من 768 بكسل، شريط بـ `position: fixed; bottom: 0` يعرض اسم المنتج وسعره واسم اللون المحدد وزر "اشترِ" واحدًا (بارتفاع 48 بكسل على الأقل). اجعل نص الزر قصيرًا وفي سطر واحد (`whitespace-nowrap`)؛ وضع اسم اللون داخل الزر كنص sr-only لقارئات الشاشة. أعطِ الـ body حشوة سفلية تساوي ارتفاع الشريط حتى لا يغطي الشريط المحتوى أو التذييل، وتأكد من أن آخر رابط في أسفل الصفحة يبقى فوق الشريط. يكون الشريط مخفيًا على سطح المكتب.
7. الجداول: يحتوي جدول المواصفات على رؤوس صفوف `<th scope="row">` وعنصر `<caption>` مخفي بصريًا وجملة توضح ظروف الاختبار (مثل درجة حرارة الغرفة والغطاء مغلق). في جدول المقارنة قارن طرازاتك أنت فقط، دون أسماء منافسين أو ادعاءات عنهم؛ وأبرز الطراز المعروض للبيع بلون خلفية دون الاعتماد على اللون وحده. غلّف الجدول في `<section aria-label="..." tabindex="0" class="overflow-x-auto">` حتى لا يفيض أبدًا على الشاشات الضيقة؛ ولا تكتب role="region" لأن html-validate يعتبره prefer-native-element.

الإعداد والأخطاء المعروفة (كلٌّ منها كلّف نقاطًا أو أفشل بوابة في قياس العرض التجريبي، فلا تتجاوزها):
1. إذا كان هناك موقع يعمل بالفعل على الخادم، فأخبرني أولًا، لأن الإعداد يستبدل index.html ومجلد assets. اعرض معاينة scaffold_site مع confirm=false أولًا، ثم استدعِ confirm=true بعد موافقتي. بعد ذلك اقرأ site_design_guide وsite_seo_guide. قبل كتابة الكود، اكتب اتجاه التصميم (الخطوط، واللون، والشبكة، والعنصر المميز، ولغة الحركة، والمكتبات التي لن يتم تحميلها) في ملف ART.md قصير خارج assets واعرضه عليّ.
2. اضبط Tailwind بالتجميع، ولا تحمّله من CDN. ثبّت `npm i -D tailwindcss@3` باستخدام site_run_command مع background=true، ثم تابعه بـ site_command_status. يجب أن تغطي مسارات content في `tailwind.config.js` كل ملفات HTML بما فيها المجلدات الفرعية وقوالب `_src/*.tpl` وأي ملف JS يكتب فئات. يحتوي `_src/tw.css` على السطر `@import "../assets/app.css";` وأسطر `@tailwind` الثلاثة؛ جمّعه في ملف واحد باستخدام `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. أزل سكربت cdn.tailwindcss.com وtailwind.config المضمّن وchrome.js وmotion.js من الصفحات واربط `/assets/site.css` فقط. أعد التجميع بعد كل تعديل على HTML. إذا حددت نقاط الألوان بفئات قيم اعتباطية مثل `bg-[#28385C]` فستُجمَّع لأنها تظهر في HTML.
3. استضف الخطوط بنفسك. اقرأ CSS الخاص بـ Fontshare بطلب واحد لكل عائلة ووزن (`https://api.fontshare.com/v2/css?f[]=family@weight`)، ونزّل كل ملف woff2 إلى `assets/fonts/` باستخدام site_fetch، واكتب قواعد @font-face مع `font-display: swap` في `assets/app.css`؛ يبحث design-check عن الخط المخصص هناك. نفّذ preload لكل الأوزان المستخدمة أعلى الصفحة (العناوين والنص والأزرار) في كل صفحة باستخدام `<link rel="preload" as="font" type="font/woff2" crossorigin>` وضع هذه الأسطر قبل رابط ملف الأنماط. معظم خطوط Fontshare لا تحتوي على رمز ₺، لذا اكتب الأسعار بـ "TL".
4. اجعل القائمة والتذييل HTML ثابتًا. اكتب `chrome-stamp.mjs` صغيرًا يقرأ قائمة التنقل من site.config.js ويختم `_src/header.tpl` و`_src/footer.tpl` بين العلامتين `` و`` في كل صفحة، مع إضافة aria-current="page" إلى الرابط النشط. لا تعطِ القوالب امتداد .html واستخدم عناصر نائبة مثل `[[NAV]]` بدل `{{...}}`. ابنِ قائمة الجوال بـ `<details>` ودون JS. أبقِ اسم النشاط والعنوان والهاتف في التذييل كنص عادي، واجعل ارتفاع روابط التذييل ومسار التنقل 44 بكسل على الأقل.
5. حوّل الصور أثناء تنزيلها بـ site_fetch: اكتب الصورة نفسها في ملفات منفصلة مع resize="480x" و"800x" و"1120x" (أو العروض التي تحتاجها الصفحة)، وimage_format="webp" وquality=65. أعطِ كل `<img>` الخصائص srcset وsizes وwidth وheight بما يطابق النسبة الحقيقية. تحصل الصورة الرئيسية أعلى الصفحة على fetchpriority="high" وتكون غير lazy؛ وأعطِ fetchpriority لعنصر LCP الحقيقي فقط، وloading="lazy" decoding="async" لبقية الصور. نزّل صور الخيارات بنسبة 4:5 مع resize="480x" و"720x" و"960x".
6. اكتب ملف `favicon.svg` صغيرًا في جذر الموقع وأضف `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` إلى كل الصفحات؛ وإذا كان هناك شعار PNG فأنشئ apple-touch-icon باستخدام site_fetch مع resize="180x180" وimage_format="png". بدون favicon يسجل المتصفح خطأ 404 للمسار /favicon.ico وتنخفض نتيجة Best Practices إلى 96.
7. قواعد مدقق HTML: ابدأ كل مستند بـ `<!DOCTYPE html>` بأحرف كبيرة، وضع قيم الخصائص بين علامتي اقتباس مزدوجتين، واستخدم `&nbsp;` للمسافات في النص المرئي لروابط tel:، ولا تستخدم خاصية style="" أبدًا (وإذا احتجت متغير CSS فاستخدم فئة خاصية اعتباطية في Tailwind مثل `[--r:-4deg]`)، وأعطِ كل زر type="button"، ولا تضع aria-label على عناصر بلا role مثل `<ul>` أو `<div>`، واستخدم `<section aria-label="...">` بدل role="region".
8. قد يشير تدقيق أهداف اللمس إلى أن الـ radio المخفي بصريًا بحجم 1 بكسل؛ هدف اللمس الحقيقي هو الـ label المحيط به. تحقق من أن الـ label بحجم 44x44 بكسل على الأقل ودوّن السبب في التقرير.

SEO وAEO وGEO:
1. استخدم عناوين URL بنمط المجلدات مع شرطة مائلة في النهاية (/garanti-ve-iade/ و/iletisim/ و/gizlilik/ أو ما يقابلها بلغتك). املأ كتلة seo في site.config.js ونفّذ `node seo-stamp.mjs`. بالنسبة لعلامة بلا متجر فعلي، اضبط localBusiness:false في site.config.js. الصفحة الرئيسية: ItemPage (وmainEntity هو المنتج)، ومخطط المنتج، وFAQPage. مخطط المنتج: مع خيار واحد، Product وOffer؛ ومع خيارات ألوان، ProductGroup (productGroupID وvariesBy https://schema.org/color وbrand وdescription وmaterial) وداخل hasVariant عنصر Product لكل لون (sku وcolor وimage) مع Offer (price وpriceCurrency TRY وavailability وitemCondition ورابط متجر الخيار كـ url وseller @id وshippingDetails مع OfferShippingDetails وhasMerchantReturnPolicy مع MerchantReturnPolicy). انشر MerchantReturnPolicy نفسه مع @id الخاص به في كتلة مستقلة في صفحة الضمان والإرجاع. أضف GTIN أو التقييمات أو المراجعات فقط إذا كانت لديّ قيم حقيقية. اكتب كل مخطط خاص بصفحة في كتلة `<script type="application/ld+json">` مستقلة واربطه بالرسم الأساسي عبر @id. لا تضع BreadcrumbList داخل @graph؛ أبقِه في كتلة مستقلة، لأن هذه هي الطريقة الوحيدة التي يراه بها seo-check.
2. العناوين من 48 إلى 60 حرفًا (يعتبر seo-check ما فوق 65 خطأ)، والأوصاف من 145 إلى 158 حرفًا، وh1 واحد في كل صفحة. المحتوى الرئيسي لكل صفحة 150 كلمة على الأقل. في العرض التجريبي جاءت صفحات الضمان والإرجاع والخصوصية والتواصل بـ 141 و124 و106 كلمات في المحاولة الأولى، وأُكملت بمعلومات حقيقية مثل "خطوات الإرجاع" و"مع من تُشارك البيانات" و"ما يتطلبه طلب الضمان".
3. تجيب الفقرة الأولى في كل صفحة مباشرة عن سؤال الصفحة، ويُصاغ الـ h1 على شكل هذا السؤال. اكتب الأسئلة الشائعة الخاصة بالصفحة باستخدام `<details>` وعلّمها كـ FAQPage. اعرض الجهة الناشرة وتاريخ "آخر تحديث" باستخدام `<time datetime>`.
4. في robots.txt اكتب قرارك مع السبب لكل من GPTBot وOAI-SearchBot وChatGPT-User وClaudeBot وClaude-User وClaude-SearchBot وPerplexityBot وPerplexity-User وGoogle-Extended وApplebot-Extended وBingbot وCCBot، وأشِر إلى خريطة الموقع. يحتوي sitemap.xml على lastmod حقيقي. ويحتوي llms.txt على ملخص دقيق من جملتين للموقع وقائمة بالصفحات المهمة.
5. لا اختلاق: لا تكتب مراجعات أو تقييمات أو جوائز أو أعداد عملاء أو شهادات أو ساعات عمل أو إحداثيات أو أسعارًا أو أرقام منتج دون أن تسألني. اترك أي حقل لا تعرفه خارج المخطط تمامًا.

البوابات (بالترتيب؛ لا تقل "تم" قبل أن تنجح كلها):
1. باستخدام site_run_command نفّذ بالترتيب `node chrome-stamp.mjs` ثم تجميع Tailwind ثم `node seo-stamp.mjs` ثم `node seo-check.mjs` (0 أخطاء، 0 تحذيرات) ثم `node design-check.mjs` (0 أخطاء؛ وبرّر أي تحذير متبقٍّ) ثم `npx html-validate "**/*.html"` (0 أخطاء).
2. افحص كل صفحة بـ site_preview مع view="mobile" وview="desktop". يلتقط site_preview الصفحة مع إيقاف الحركة؛ وإذا لم يكن المحتوى كاملًا في هذه اللقطة فحالة عدم الحركة معطوبة. قد تظهر الصور المحمّلة كسولًا في الأسفل فارغة في لقطة الصفحة الكاملة؛ لا تحسب ذلك خطأ، لكن تحقق من مساراتها.
3. شغّل core_web_vitals لكل صفحة مع strategy="mobile" وstrategy="desktop". معيار القبول: على الجوال Performance لا تقل عن 95 وAccessibility وBest Practices وSEO تساوي 100؛ وعلى سطح المكتب تكون الأربع جميعها 95 على الأقل، والهدف 100. إذا أخفقت صفحة، فابحث عن الملف البطيء باستخدام resources=true وأصلحه وقِس مرة أخرى. بعد ذلك شغّل seo_audit على الصفحة الرئيسية مع strategy="mobile" وruns=2. يجب ألا تحتوي قائمة طلبات الشبكة على أي عنوان خارج نطاقك (روابط المتجر وWhatsApp روابط وليست طلبات).
4. لا تمرير أفقي عند عرض 360 و390 و768 و1440 بكسل، وأهداف اللمس 44 بكسل على الأقل، ولا أخطاء في وحدة التحكم.

فحص التفاعل: بما أن site_preview لا يستطيع إظهار الحركة أو النقرات، أخبرني بما يجب أن أراقبه في متصفحي: على سطح المكتب، عند تحريك الفأرة فوق المنتج تميل البطاقة نحو المؤشر مع طفو الشارتين أمامها، وتعود إلى الوضعية المائلة عند مغادرة الفأرة؛ والنقر على نقطة لون أو الضغط على مفتاح سهم يغيّر الصورة واسم اللون ورابط الشراء دون أن يتحرك أي شيء في الصفحة؛ ومع إيقاف جافاسكريبت يظل محدد الألوان يعمل؛ وعلى الهاتف يكون الشريط السفلي ظاهرًا دائمًا ولا يغطي الروابط في نهاية الصفحة؛ ومع تفعيل تقليل الحركة لا تميل البطاقة.

بعد النشر: اعرض معاينة القاعدة `/assets/* Cache-Control: public, max-age=31536000, immutable` باستخدام site_headers وطبّقها بعد موافقتي؛ ومن ذلك الحين أضف رقم إصدار إلى اسم الملف كلما تغيّر CSS أو JS (site-v2.css وهكذا). أرسل sitemap.xml باستخدام gsc_submit_sitemap وافحص الصفحة الرئيسية باستخدام gsc_url_inspect. وفي النهاية أعطني: جدول نتائج لكل صفحة (الصفحة، النتائج الأربع على الجوال، النتائج الأربع على سطح المكتب، LCP، CLS)، ونتائج البوابات، وقائمة الإصلاحات التي طبقتها.

الموقع الإلكترونييجري تغييرات بعد موافقتك

اكتب ملفي llms.txt وllms-full.txt دقيقين لموقعك المستضاف

يقرأ صفحات موقعك ومحتواه الفعلي ويصيغ ملف ملخص بصيغة مقترح llms.txt، مستخدمًا فقط الحقائق الموجودة في الموقع. ويضيف اختياريًا النص النظيف للصفحات الرئيسية كملف llms-full.txt، وينشره بعد الموافقة ويتحقق منه على الموقع الحي.

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

اكتب ملف llms.txt لموقعي [URL الموقع] على استضافة Opus Growth. حقائق عن نشاطي التجاري غير موجودة في الموقع لكنني أؤكد أنها صحيحة: [معلومات إضافية، أو "لا شيء"]. هل أريد أيضًا llms-full.txt: [نعم أو لا].

قبل أن تبدأ، ضع هذا في اعتبارك وأخبرني به أيضًا: llms.txt مقترح منشور على llmstxt.org. الغرض منه مساعدة مساعدي الذكاء الاصطناعي على فهم الموقع بسرعة وبشكل صحيح، لكن المزوّدين الكبار مثل Google وOpenAI لم يصرّحوا بأنهم يستخدمونه كإشارة ترتيب أو استشهاد. لذلك فالهدف ملف صغير ودقيق، وليس نصًا ترويجيًا.

1. اقرأ الحالة الحالية. تحقق من [URL الموقع]/llms.txt باستخدام site_read_url. إذا وُجد ملف، فاعرضه ونبّه إلى ما هو قديم فيه. اقرأ قواعد SEO الخاصة بالمنصة باستخدام site_seo_guide.
2. اجمع الصفحات. اعرض صفحات HTML باستخدام site_list_files واقرأ [URL الموقع]/sitemap.xml باستخدام site_read_url. دوّن الصفحات الموجودة في خريطة الموقع وغير الموجودة في قائمة الملفات، أو العكس. استبعد الصفحات القانونية وصفحات الشكر وصفحة 404.
3. اقرأ المحتوى. اقرأ الصفحة الرئيسية وصفحات الخدمات أو المنتجات وصفحة التعريف وصفحة الاتصال وصفحة الأسعار باستخدام site_read_url مع text=true. إذا ذكر الرد أن truncated تساوي true، فاقرأ مرة أخرى مع max_bytes=1000000. لكل صفحة اكتب وصفًا من جملة واحدة يعتمد فقط على ما تقوله الصفحة فعلًا.
4. اكتب المسودة بصيغة llms.txt:
   1. السطر الأول هو العنوان `# [اسم النشاط التجاري]`.
   2. تحته ملخص من جملة أو جملتين يبدأ بـ `>`: ماذا نفعل، ولمن، وأين.
   3. ثم فقرة قصيرة بالحقائق الأساسية: نطاق الخدمة، وكيفية التواصل، وطريقة عملنا. استخدم فقط الحقائق الموجودة في الموقع أو التي أعطيتك إياها أعلاه. إذا لم تكن الأسعار أو ساعات العمل أو التقييمات أو أعداد العملاء أو الجوائز أو الشهادات موجودة في الموقع، فلا تكتبها.
   4. ثم أقسام مثل `## Services` و`## FAQ` و`## Company`. يتبع كل سطر الصيغة `- [اسم الصفحة](full URL): one-sentence description`. استخدم الرابط الأساسي (canonical) الذي يعيد 200؛ في هذه المنصة تنتهي روابط المجلدات بشرطة مائلة.
   5. ضع الروابط الثانوية مثل الصفحات القانونية والمدونة في النهاية، تحت `## Optional`.
   6. إذا كان للموقع عدة لغات، فخصص لكل لغة قسمها وحدد أي رابط بأي لغة.
   7. اختم الملف بـ `Last updated: [تاريخ اليوم]`.
5. إذا أردتُ llms-full.txt: ادمج النص النظيف للصفحات الرئيسية في ملف واحد، بحيث تبدأ كل صفحة بـ `## Page name` و`Source: full URL`. احذف القوائم والتذييلات ونص ملفات الكوكيز. إذا تجاوز الملف 500 KB، فضمّن فقط صفحات الخدمات والأسعار والأسئلة الشائعة والتعريف.
6. تحقق منه. شغّل seo_content_lint على نص llms.txt وصحّح العبارات المبالغ فيها أو التي تبدو مكتوبة بالذكاء الاصطناعي. اختبر كل رابط باستخدام site_read_url مع max_bytes=0 واحذف أي رابط لا يعيد 200.
7. اعرض معاينة. أعطني الملف الكامل وجدول مصادر قصيرًا يوضح من أين جاءت كل حقيقة: الحقيقة، صفحة المصدر. انتظر موافقتي.
8. انشر بعد الموافقة. اكتب llms.txt (وllms-full.txt إذا طلبته) في جذر الموقع باستخدام site_write_file. اقرأ الملفين باستخدام site_read_url وأظهر أن الحالة 200 وأن content-type هو text/plain. أخبرني إذا كان robots.txt يحظر /llms.txt. لا تضف llms.txt إلى خريطة الموقع، لأن خريطة الموقع مخصصة لصفحات HTML.

اختم بملاحظة صيانة: في ثلاث نقاط، اذكر أي التغييرات (صفحة خدمة جديدة، تحديث سعر، تغيير عنوان) تعني أن هذا الملف يجب تحديثه أيضًا.

الموقع الإلكترونييجري تغييرات بعد موافقتك

انشر llms.txt على موقع WordPress الخاص بك: جرّب إضافة SEO أولًا، ثم مقتطفًا آمنًا

يتحقق مما إذا كانت إضافة SEO لديك قادرة على إنشاء llms.txt وهل مخرجاتها جيدة بما يكفي. وإذا لم تكن كذلك، يبني ملفًا يدويًا من صفحات الموقع الفعلية، ويقدّمه على /llms.txt عبر مقتطف WPCode بعد موافقتك، ثم يتحقق منه مباشرة.

متى تستخدمهموقعك يعمل على WordPress وتريد نشر llms.txt يصف نشاطك التجاري وصفًا صحيحًا، لكنك لا تعرف هل إضافة SEO لديك تفعل ذلك بالفعل ولا كيف تقدّم الملف.

انشر ملف llms.txt دقيقًا على /llms.txt في موقع WordPress الخاص بي [موقع WordPress]. حقائق عن نشاطي التجاري غير موجودة على الموقع لكنني أؤكد صحتها: [معلومات إضافية، أو "لا شيء"].

llms.txt مقترح منشور على llmstxt.org. يساعد مساعدات الذكاء الاصطناعي على فهم الموقع فهمًا صحيحًا، لكن كبار المزودين لم يذكروا أنهم يستخدمونه كإشارة للترتيب أو الاستشهاد. أخبرني بذلك مرة واحدة فقط، وأبقِ العمل صغيرًا ودقيقًا.

1. ارسم الوضع الحالي. اعثر على الموقع عبر list_wordpress_sites، واعثر على إضافة SEO وإصدارها عبر wordpress_list_plugins، واقرأ إعدادات الإضافة على مستوى الموقع عبر wordpress_seo. افحص [موقع WordPress]/llms.txt عبر site_read_url: اعرض رمز الحالة والمحتوى إن وُجد.
2. مسار الإضافة. تتضمن الإصدارات الحالية من Yoast SEO وRank Math وAll in One SEO ميزة تنشئ llms.txt. اقرأ سجل إعدادات الإضافة عبر wordpress_option مع write=false (في Yoast اسم الخيار هو `wpseo`) واعرف هل ميزة llms.txt مفعّلة. إذا لم تكن متأكدًا من اسم المفتاح فلا تخمّن، وأخبرني بالشاشة التي يجب أن أفحصها في لوحة الإضافة. إذا كانت الميزة مفعّلة، فقيّم مخرجاتها: هل تسرد فقط أحدث مقالات المدونة؟ وهل صفحات الخدمات والتواصل موجودة؟ وهل الأوصاف صحيحة؟ إذا كانت جيدة بما يكفي، فتوقف هنا وقدّم لي تقييمًا موجزًا.
3. ابنِ الملف يدويًا (إذا لم تتوفر ميزة في الإضافة أو كانت مخرجاتها غير جيدة بما يكفي). اعرض الصفحات عبر wordpress_list_posts مع type='page' وstatus='publish'، ثم أهم 10 مقالات. اقرأ الصفحة الرئيسية وصفحات الخدمات أو المنتجات وصفحات من نحن والتواصل والأسعار عبر site_read_url مع text=true؛ وإذا كانت الاستجابة تشير إلى أن truncated تساوي true فأعد القراءة مع max_bytes=1000000. اكتب المسودة هكذا: السطر الأول `# [اسم النشاط التجاري]`، وتحته ملخص من جملة أو جملتين يبدأ بـ `>`، ثم فقرة قصيرة بالحقائق الأساسية، ثم أقسام `## Services` و`## FAQ` و`## Company` بحيث يكون كل سطر بالصيغة `- [اسم الصفحة](full URL): one-sentence description`، وأخيرًا الصفحات القانونية والمدونة تحت `## Optional`. استخدم فقط الحقائق الموجودة على الموقع أو التي زوّدتك بها؛ وإذا لم تكن الأسعار أو ساعات العمل أو التقييمات أو أعداد العملاء أو الشهادات موجودة على الموقع فاتركها. أنهِ الملف بـ `Last updated: [تاريخ اليوم]`. شغّل seo_content_lint على النص وأصلح العبارات التي يشير إليها. اختبر كل رابط عبر site_read_url مع max_bytes=0.
4. المعاينة. اعرض الملف كاملًا، والصفحة المصدر لكل حقيقة، ومسار النشر. المسار هو مقتطف PHP يُنشأ عبر wordpress_snippet بالموقع 'everywhere'. على الخطّاف `init`، عندما يكون مسار الطلب هو `/llms.txt` تمامًا، يرسل الكود `Content-Type: text/plain; charset=utf-8` ويطبع النص ثم ينهي التنفيذ، ولا يمسّ أي طلب آخر. اعرض الكود أيضًا في المعاينة. وإذا كانت ميزة llms.txt في الإضافة نفسها مفعّلة، فاطلب مني إيقافها أولًا حتى لا يتعارض المصدران. انتظر موافقتي.
5. طبّق بعد الموافقة. أنشئ المقتطف عبر wordpress_snippet مع action='create'. يُنشأ غير مفعّل؛ فعّله عبر action='toggle' مع active=true. إذا أعاد التفعيل خطأ فسيبقى المقتطف متوقفًا، فاعرض لي الخطأ. وإذا كانت إضافة تخزين مؤقت مفعّلة، فامسح الذاكرة المؤقتة عبر wordpress_purge_cache.
6. تحقق. اقرأ /llms.txt عبر site_read_url: يجب أن تكون الحالة 200 ونوع المحتوى text/plain والمحتوى هو النص الذي وافقت عليه. وإذا أعاد الـ URL الرمز 404، فهذا يعني أن خادم الويب لا يمرّر طلبات .txt إلى WordPress أصلًا. في هذه الحالة أوقف المقتطف واشرح كيفية رفع الملف إلى جذر الموقع عبر لوحة الاستضافة أو FTP. تحقق أيضًا عبر site_read_url من أن الصفحة الرئيسية ما زالت تعيد 200.

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

الموقع الإلكترونييجري تغييرات بعد موافقتك

حدّد سياسة robots.txt لزواحف الذكاء الاصطناعي وانشرها بأمان

يساعدك على تحديد زواحف الذكاء الاصطناعي التي يجب أن يكون الموقع مفتوحًا لها، عبر الفصل بين أدوار البحث وجلب المستخدم والتدريب. يعرض معاينة لملف robots.txt جديد يحافظ على قواعدك الحالية، ويكتبه على موقعك المستضاف أو WordPress بعد الموافقة ويتحقق منه على الموقع الفعلي.

متى تستخدمهتريد أن يُستشهد بموقعك في البحث بالذكاء الاصطناعي لكنك تريد اتخاذ قرار منفصل بشأن تدريب النماذج، أو لا تعرف ما الذي يقوله ملف robots.txt لديك حاليًا لزواحف الذكاء الاصطناعي.

أعد صياغة ملف robots.txt لموقعي [رابط الموقع] حول سياسة مدروسة لزواحف الذكاء الاصطناعي. نوع الموقع: [استضافة Opus Growth أو WordPress]. تفضيلي: [A: مفتوح للجميع / B: البحث مفتوح والتدريب مغلق / C: مخصص، اشرح].

1. اقرأ الوضع الحالي. اقرأ [رابط الموقع]/robots.txt باستخدام site_read_url. إذا كان الموقع على استضافة Opus Growth، فاقرأ robots.txt أيضًا باستخدام site_read_file وتأكد من أنه يطابق ما هو منشور. إذا كان WordPress، فاكتشف أي إضافة SEO تديره باستخدام wordpress_seo وتحقق باستخدام wordpress_snippet action='list' مما إذا كان أي مقتطف يتدخل في robots.txt. اعرض كل مجموعة قواعد موجودة وكل سطر Disallow وكل سطر Sitemap.
2. اشرح الأدوار. صنّف الزواحف في ثلاث مجموعات وأخبرني في جملة واحدة لكل مجموعة ماذا أخسر أو أكسب:
   1. البحث والاستشهاد: OAI-SearchBot وClaude-SearchBot وPerplexityBot وBingbot وGooglebot وApplebot. إغلاق هذه الزواحف يمنع الاستشهاد بالموقع كمصدر في إجابات ذلك المساعد.
   2. الجلب المباشر نيابة عن المستخدم: ChatGPT-User وClaude-User وPerplexity-User. تصل هذه الزواحف عندما يشارك مستخدم رابطي أو عندما يفتح المساعد صفحة ليجيب. وفقًا لوثائق المزوّدين، قد لا ينطبق robots.txt في كل الحالات على هذه الطلبات التي يبدؤها المستخدم، لذا وضّح أن القاعدة هنا ليست ضمانًا.
   3. تدريب النماذج: GPTBot وClaudeBot وGoogle-Extended وApplebot-Extended وCCBot وmeta-externalagent. إغلاق هذه الزواحف يحدّ من استخدام المحتوى في التدريب المستقبلي، لكنه لا يزيل المحتوى من النماذج المدرَّبة بالفعل. إغلاق Google-Extended لا يؤثر على بحث Google ولا على AI Overviews.
3. اكتب المسودة. جهّز ملف robots.txt الجديد وفق تفضيلي والتزم بهذه القواعد:
   1. عندما تكتب مجموعة باسم زاحف محدد، لا يعود ذلك الزاحف يقرأ مجموعة `User-agent: *`. لذا انسخ كل أسطر Disallow من مجموعة * (منطقة الإدارة، السلة، نتائج البحث الداخلي وغيرها) إلى كل مجموعة مسمّاة، وإلا ستفتح مناطق خاصة دون أن تنتبه.
   2. لا تحظر ملفات CSS أو JavaScript أو الصور، لأن الزواحف تحتاجها لعرض الصفحة.
   3. أبقِ أسطر Sitemap الحالية، وأضف رابط خريطة الموقع الكامل إذا كان مفقودًا.
   4. لا تغلق أي زاحف بحث ما لم أطلب ذلك صراحةً.
   5. اترك زواحف SEO الخاصة بالمنافسين (مثل AhrefsBot وSemrushBot) كما هي ما لم أطلب غير ذلك، فهي خارج نطاق هذه المهمة.
4. اعرض معاينة. قارن الملف القديم بالجديد سطرًا بسطر، واعرض جدولًا يوضح القرار قبل وبعد لكل زاحف: الزاحف، الدور، القرار القديم، القرار الجديد. انتظر موافقتي.
5. طبّق بعد الموافقة.
   1. الموقع المستضاف: اكتب robots.txt باستخدام site_write_file. تأخذ المنصة لقطة نسخة قبل كل كتابة، لذا أخبرني بأي نسخة من site_versions يمكنني العودة إليها.
   2. WordPress: عندما لا يوجد ملف فعلي على الخادم، يولّد WordPress ملف robots.txt بنفسه ويمكن للفلتر `robots_txt` تغييره. أنشئ مقتطف PHP باستخدام wordpress_snippet يستخدم هذا الفلتر، بالموقع 'everywhere'. يُنشأ المقتطف غير مفعّل، لذا اعرض الكود وفعّله فقط بعد موافقتي. إذا كانت هناك إضافة تخزين مؤقت مفعّلة، فامسح الذاكرة المؤقتة باستخدام wordpress_purge_cache.
6. أعد القراءة. اقرأ robots.txt مرة أخرى باستخدام site_read_url وأظهر أن المحتوى الجديد منشور. في WordPress، إذا لم يتغير المحتوى، فهذا يعني وجود ملف robots.txt فعلي على الخادم ولا يستطيع الفلتر الوصول إليه. في هذه الحالة أوقف المقتطف وأرشدني إلى تغيير الملف من محرر الملفات في إضافة SEO (Yoast: Tools ثم File editor؛ Rank Math: General Settings ثم Edit robots.txt) أو من لوحة التحكم في الاستضافة.

اختم بملاحظة من جملتين: يسري التغيير عندما تعيد الزواحف قراءة الملف (عادةً خلال يوم)، وإذا كانت قاعدة في CDN أو جدار حماية تحظر حسب اسم الزاحف، فلا يكفي robots.txt وحده.

الموقع الإلكترونييجري تغييرات بعد موافقتك

أعد بناء قائمة الموقع حول الصفحات التي تحقق التحويلات فعلًا

يطابق أداء صفحات الهبوط في GA4 مع قوائم WordPress لديك، ويحدد الصفحات القيّمة المفقودة من شريط التنقل والصفحات عديمة الفائدة والروابط المعطلة، ويقترح قائمة رئيسية أكثر إيجازًا.

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

قارن قائمة التنقل لدي بما يحقق التحويلات فعلًا.

من خاصية GA4 [موقع GA4]، اسحب بيانات آخر 90 يومًا حسب صفحة الهبوط: الجلسات والأحداث الرئيسية. احسب معدل الأحداث الرئيسية على أنه الأحداث الرئيسية / الجلسات.

ثم اقرأ كل قائمة في [موقع WordPress]، بما فيها شريط التنقل الرئيسي والتذييل، مع جميع روابطها.

طابق روابط القوائم مع صفوف GA4 حسب مسار URL (تجاهل النطاق والشرطات المائلة الأخيرة وسلاسل الاستعلام). إذا لم يكن للرابط صف في GA4، فاعتبره صفر جلسات وأخبرني بذلك.

افحص كل رابط في القائمة بحثًا عن المشكلات:
- افتح كل URL مرتبط وسجّل حالة HTTP الخاصة به. أي حالة 4xx أو 5xx تعني رابطًا معطلًا؛ ودوّن عمليات إعادة التوجيه أيضًا.
- حدد الروابط التي تشير إلى صفحات مسودة أو خاصة، أو إلى slugs قديمة، أو إلى http بدلًا من https.

قدّم ثلاث قوائم:
1. الصفحات التي لديها 20 حدثًا رئيسيًا على الأقل وغير موجودة في القائمة الرئيسية.
2. روابط القائمة التي تشير إلى صفحات لديها أقل من 50 جلسة أو صفر أحداث رئيسية خلال 90 يومًا.
3. الروابط المعطلة أو القديمة، مع سبب كل منها.

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

اعرض القائمة الحالية والقائمة المقترحة جنبًا إلى جنب، مع القائمة الدقيقة لإجراءات القائمة التي ستنفذها (إضافة، إعادة تسمية، إعادة ربط، إعادة ترتيب، إزالة)، على هيئة معاينة. لا تعدّل أي شيء حتى أوافق. بعد الموافقة، طبّق التغييرات، وامسح ذاكرة التخزين المؤقت، واقرأ القوائم مجددًا للتأكد من البنية النهائية.

الموقع الإلكترونييجري تغييرات بعد موافقتك

فحص سلامة الإضافات والتتبع قبل أن يُفسد تحويلاتك

قائمة إجراءات لكل إضافة على حدة تشير إلى الإضافات القديمة والمكررة والمتعارضة وإلى الوسوم التي تعمل مرتين.

متى تستخدمهعندما يحتوي موقع WordPress لديك على إضافات كثيرة جدًا أو تتراكم عليه التحديثات، أو تخشى أن تكون الوسوم المكررة تضخّم التحويلات التي تُحسّن إعلاناتك لتحقيقها.

أجرِ فحصًا لسلامة الإضافات والتتبع على [موقع WordPress].

اقرأ ما يلي:
- إصدارَي WordPress وPHP.
- جميع الإضافات المثبّتة، مع حالة تفعيل كل منها وهل يتوفر تحديث.
- كل موضع يعمل منه وسم GTM أو GA4.
- إعدادات التخزين المؤقت والسرعة الحالية.

قدّم جدولًا بهذه الأعمدة: الإضافة، مفعّلة؟، هل يتوفر تحديث؟، الدور (SEO، تخزين مؤقت، نماذج، تتبع، أداة بناء الصفحات، أخرى)، المخاطر، التوصية (إبقاء، تحديث، تعطيل أو حذف).

نبّهني صراحةً إلى هذه المشكلات:
- أكثر من إضافة SEO واحدة.
- أكثر من إضافة تخزين مؤقت واحدة.
- إضافات غير مفعّلة يمكن حذفها.
- أي وسم GTM أو GA4 يعمل من أكثر من موضع. العمل المزدوج يضخّم التحويلات التي تُحسّن إعلاناتي لتحقيقها.

لا تلمس أداة بناء الصفحات ولا إضافة النماذج ولا WooCommerce.

اعرض قائمة الإجراءات كمعاينة أولًا. ثم نفّذ إضافة واحدة في كل مرة، وبعد موافقتي على كل واحدة فقط. بعد كل تغيير، تأكد من أن الصفحة الرئيسية ما زالت تعيد الحالة 200 قبل المتابعة.

الموقع الإلكترونييجري تغييرات بعد موافقتك

استبدل رقم هاتف قديمًا في كل أنحاء الموقع بأمان

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

متى تستخدمهعندما يتغير رقم هاتفك وتحتاج إلى التأكد من أن الرقم القديم لم يعد يظهر في أي مكان في موقعك.

تغيّر رقم هاتفنا من [الرقم القديم] إلى [الرقم الجديد]. يجب ألا يرى المعلنون والزوار من البحث العضوي الرقم القديم في أي مكان.

1. ابحث عن كل المقالات والصفحات في موقع WordPress الخاص بي التي تحتوي على الرقم القديم بأي صيغة شائعة: مع مسافات، وبدون مسافات، ومع رمز الدولة، وداخل روابط tel:.
2. افحص القوائم بحثًا عن روابط tel: وافحص إعدادات Contact Form 7 بحثًا عن الرقم القديم.
3. اقرأ موقع Business Profile الخاص بي وأخبرني أي رقم يعرضه حاليًا.

قدّم:
- قائمة بالصفحات مع عدد مرات ظهور الرقم في كل منها.
- أي مكان لا يمكن للبحث والاستبدال في المحتوى الوصول إليه، مثل القوائم أو إعدادات النماذج أو Business Profile.

نفّذ البحث والاستبدال الجماعي أولًا كتجربة محاكاة واعرض لي الفروقات (diff) لكل صفحة. طبّقه فقط بعد موافقتي، ثم امسح ذاكرة التخزين المؤقت.

لا تغيّر Business Profile في هذه المهمة. أخبرني فقط إن كان يحتاج إلى تحديث.

الموقع الإلكترونييجري تغييرات بعد موافقتك

تحقق من أن صفحاتك المدرّة للإيرادات مفهرسة وأن الروابط الأساسية (canonical) صحيحة

يفحص دفعةً واحدة صفحات WordPress الرئيسية لديك في Search Console، ويقارن canonical الذي اختاره Google مع المحدد في إضافة SEO لديك، ويحدد مشكلات noindex وخريطة الموقع، ويجهّز الإصلاحات لموافقتك.

متى تستخدمهعندما تكون هناك صفحات مهمة قد تكون غائبة عن Google، أو تشك في أن وسوم noindex أو canonical خاطئة أو فجوات في خريطة الموقع تُبقيها خارج نتائج البحث.

تحقق مما إذا كان Google قد فهرس أهم صفحاتي على [موقع WordPress]. خاصية Search Console هي [موقع Search Console].

هذه هي الصفحات التي أستخدمها كصفحات هبوط للإعلانات: [الصق عناوين URL لصفحات الهبوط الخاصة بإعلاناتك أو اكتب "لا شيء"]

1. اعرض الصفحات والمقالات المنشورة على موقع WordPress لتحصل على كل URL ومعرّف المنشور الخاص به.
2. اسحب بيانات الصفحات من Search Console لآخر 90 يومًا، مرتبة حسب مرات الظهور.
3. اختر ما يصل إلى 50 URL رئيسيًا: صفحات الخدمات، وفئات المنتجات، وصفحة التواصل، وصفحات هبوط الإعلانات التي ذكرتها أعلاه، والصفحات الأعلى في مرات الظهور. اعرض لي القائمة قبل الفحص.
4. افحصها باستخدام فحص URL الدفعي، بواقع 20 URL في كل استدعاء (أي حتى 3 استدعاءات). إذا بلغت حصة Google، فتوقف، وأخبرني بالـ URL التي لم تُفحص بعد، وتابع لاحقًا.
5. لكل URL، أبلغ عن: حكم الفهرسة وحالة التغطية، وتاريخ آخر زحف، وcanonical الذي اختاره Google، وحالة الفهرسة أو robots.
6. فحص خريطة الموقع: اعرض خرائط الموقع المقدمة وحالتها (أخطاء، تحذيرات، قيد الانتظار). ثم استخدم حالة التغطية لكل URL لاكتشاف الفجوات في خريطة الموقع. حالة مثل "Indexed, not submitted in sitemap" أو "URL is unknown to Google" تعني أن الصفحة على الأرجح غير موجودة في خريطة الموقع. اعتبر هذا مؤشرًا قويًا وليس دليلًا قاطعًا.
7. لكل صفحة بها مشكلة، اقرأ حقول SEO الخاصة بها في WordPress: meta title وcanonical والكلمة المفتاحية الأساسية وnoindex. قارن canonical المعلن مع اختيار Google. إذا احتاج URL واحد إلى مزيد من التفاصيل (سهولة الاستخدام على الجوال، النتائج المتقدمة، وcanonical الذي أعلنه المستخدم كما يراه Google)، فنفّذ فحص URL فرديًا عليه.

قدّم جدولًا مرتبًا حسب الخطورة، بهذا الترتيب: غير مفهرسة، عدم تطابق canonical، noindex، يُحتمل غيابها من خريطة الموقع. لكل صف، اذكر السبب المحتمل والإصلاح الدقيق.

إذا كان canonical في WordPress يشير إلى URL خاطئ، أو كانت صفحة يُفترض أن تظهر في الترتيب مضبوطة على noindex، فاعرض لي الحقل بالضبط والقيمة الحالية والقيمة الجديدة، وانتظر موافقتي قبل تعيينها. لا تعد إرسال أي خريطة موقع دون أن تسألني أولًا. تذكّر أنه لا توجد أداة قادرة على الضغط على "طلب الفهرسة"، لذا اعرض الصفحات التي تحتاج إلى إعادة زحف لأطلبها يدويًا في Search Console (نحو 10 يوميًا).

الموقع الإلكترونيللقراءة فقط

اكتشف نقرات إعلانات Meta الضائعة بسبب بطء صفحات الهبوط

يربط معدل مشاهدة صفحة الهبوط لكل URL هبوط في Meta بمؤشرات Core Web Vitals على الجوال، ويقدّر الإنفاق الضائع قبل تحميل الصفحة.

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

في حساب إعلانات Meta [الحساب]، اعرض الإعلانات النشطة التي أنفقت أموالًا خلال آخر 14 يومًا. اقرأ رابط الوجهة لكل إعلان. أزل معلمات UTM، ثم جمّع الإعلانات حسب URL صفحة الهبوط الفريد.

لكل URL:
- من Insights، اسحب الإنفاق ونقرات الرابط ومشاهدات صفحة الهبوط.
- احسب معدل مشاهدة صفحة الهبوط: مشاهدات صفحة الهبوط مقسومة على نقرات الرابط.
- نفّذ فحص Core Web Vitals على الجوال. معظم زيارات Meta تأتي من الجوال، لذا فالجوال هو المعتمد.

قدّم جدولًا بالأعمدة التالية: URL، عدد الإعلانات، الإنفاق، نقرات الرابط، معدل مشاهدة صفحة الهبوط، LCP، INP، CLS.

ضع علامة على الـ URL إذا كان معدل مشاهدة صفحة الهبوط أقل من 70% وكان LCP أعلى من 2.5 ثانية. لكل URL موسوم، قدّر الإنفاق الضائع بالصيغة: الإنفاق × (1 − معدل مشاهدة صفحة الهبوط). رتّب الجدول حسب الإنفاق الضائع.

لأعلى ثلاثة URL، اقترح حلولًا محددة لتسريع الصفحة.

لا توقف أي إعلان ولا تعدّله ولا تكرّره.

الموقع الإلكترونيللقراءة فقط

حوّل زحف سرعة الموقع بالكامل إلى تذاكر للمطورين حسب القالب

يزحف على الموقع بالكامل، ويسحب القائمة الكاملة لعناوين URL لكل مشكلة متعلقة بالسرعة، ويجمّع الصفحات حسب القالب، ويدقق عينات URL لكل قالب بتفاصيل على مستوى الموارد، ويقدّم قائمة مرتبة بتذاكر المطورين مع أعداد صفحات دقيقة.

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

أولًا، تحقق في سجل إضافة SEO لدي مما إذا كان هناك زحف على [النطاق] يمكن إعادة استخدامه مجانًا. إذا وُجد، فأعد استخدامه. وإن لم يوجد، فذكّرني بأن الزحف على الموقع بالكامل يستهلك أرصدة إضافة SEO وانتظر موافقتي قبل أن تبدأ زحفًا يصل إلى [الحد الأقصى للصفحات] صفحة. يعمل الزحف في الخلفية: ابدأه، ثم تحقق من التقدم باستخدام معرّف المهمة كل دقيقة أو دقيقتين حتى يصبح الملخص جاهزًا.

من ملخص الزحف، خذ كل أنواع المشكلات المتعلقة بالسرعة أو ثبات التخطيط، إذا ظهرت في البيانات. أمثلة: حجم صفحة كبير، بطء التحميل، سلاسل إعادة التوجيه، موارد تعيق العرض، صور كبيرة الحجم، صور بدون عرض/ارتفاع. استخدم أسماء المشكلات تمامًا كما يعيدها الملخص. لكل مشكلة من هذه المشكلات، اسحب القائمة الكاملة لعناوين URL (مرّ على جميع الصفحات)، وليس فقط أول 5 أمثلة.

جمّع عناوين URL المتأثرة حسب القالب أو نمط المسار، مثل /blog/ و/product/ و/category/ وصفحات الهبوط. لكل قالب، احسب الصفحات المتأثرة لكل مشكلة من هذه القوائم الكاملة.

ثم اختر أسوأ URL في كل قالب. قبل تشغيل التدقيقات التقنية، أخبرني بعدد ما تنوي تشغيله (فهي تستهلك أرصدة الإضافة أيضًا) وانتظر موافقتي. على كل أسوأ URL، شغّل تدقيقًا تقنيًا وفحصًا لـ Core Web Vitals على الجوال مع تفعيل قوائم الموارد. استخدم قوائم الموارد لتسمية الملفات الفعلية: أي أوراق أنماط وسكربتات تعيق العرض، وكم بايتًا من CSS وJS غير المستخدم، وأي صور كبيرة الحجم أو ليست بصيغة حديثة، وإجمالي عدد الطلبات وعنصر LCP.

لمعرفة ما إذا كانت نتيجة التدقيق تشمل القالب كله أم حالة منفردة، شغّل فحص Core Web Vitals المجاني على الجوال (مع قوائم الموارد) على 2 URL إضافيين من القالب نفسه.

قاعدة العد: فقط المشكلات القادمة من قوائم URL في الزحف يُحتسب لها عدد صفحات. أما المشكلات التي وُجدت في التدقيقات فقط، فاكتب "مؤكدة في X من 3 عناوين URL في العينة" بدلًا من عدد صفحات. لا تستنتج عدد صفحات من URL واحد.

قدّم قائمة تذاكر بهذه الأعمدة: القالب، المشكلة، الصفحات المتأثرة (أو نسبة العينة)، URL مثال، الملفات أو العناصر المعنية، الإصلاح الموصى به، الجهد (S/M/L)، المقياس المتوقع تحسينه (LCP، CLS، INP/TBT، وزن الصفحة). رتّبها حسب الصفحات المتأثرة × الخطورة؛ وللمشكلات المعتمدة على العينة فقط استخدم نسبة العينة وضع عليها علامة توضح ذلك.

هذه مهمة للقراءة فقط. لا تغيّر أي شيء في الموقع.

الموقع الإلكترونييجري تغييرات بعد موافقتك

أنشئ وسم شراء لـ Google Ads بقيمة ديناميكية في GTM

إعداد على مراحل في GTM يرسل قيمة الطلب والعملة ومعرّف المعاملة إلى Google Ads، وتتم مراجعته في مساحة العمل قبل النشر.

متى تستخدمهعندما تُظهر تحويلات Google Ads قيمة غير صحيحة أو بلا قيمة وتحتاج إلى تتبع المشتريات بقيم الطلبات الفعلية عبر Google Tag Manager.

أعدّ تتبع المشتريات في Google Ads بقيم ديناميكية في حاوية GTM [GTM-XXXX] لإجراء التحويل [اسم إجراء تحويل الشراء].

1. احصل على معرّف التحويل (AW-...) والتسمية الخاصة بهذا الإجراء.
2. راجع الوسوم والمشغّلات والمتغيرات الموجودة. إذا كان هناك وسم شراء لـ Google Ads موجود بالفعل، فتوقف وأبلغني بذلك بدلًا من إنشاء وسم ثانٍ.
3. خطّط لهذه العناصر. متغيرات طبقة البيانات لـ ecommerce.value وecommerce.currency وecommerce.transaction_id (أعد استخدام أي منها إن كان موجودًا). مشغّل حدث مخصص لـ "purchase". وسم تتبع تحويلات Google Ads يستخدم هذه المتغيرات، بحيث يمنع معرّف المعاملة تكرار التسجيل عند إعادة تحميل الصفحة.
4. اعرض عليّ الإعداد الكامل لكل عنصر قبل إنشائه. أنشئ العناصر في مساحة العمل فقط بعد موافقتي.
5. اعرض حالة مساحة العمل والإصدار المنشور حاليًا. لا تنشر قبل أن أؤكد أن طلبًا تجريبيًا أطلق الوسم مرة واحدة بالقيمة الصحيحة. إذا حدث أي خلل بعد النشر، فإن إصدار التراجع هو الإصدار المنشور الآن.

الموقع الإلكترونيللقراءة فقط

دقّق في جميع نماذج الاتصال في WordPress واختبر وصول العملاء المحتملين إلى البريد الوارد

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

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

افحص جميع نماذج الاتصال في موقعي على WordPress [الموقع] وأخبرني ما إذا كان العملاء المحتملون يصلون فعلًا إلى بريدنا الوارد.

1. اعرض جميع نماذج Contact Form 7. لكل نموذج، اعرض الحقول وأيها مطلوب وعناوين المستلم والمرسل في إعدادات البريد الخاصة به.
2. ابحث عن الصفحات التي تحتوي على الشورت كود الخاص بكل نموذج لأعرف أين يُستخدم.
3. أشِر إلى هذه المشكلات: المستلم ليس [بريد صندوق العملاء المحتملين]، أو عنوان المرسل يستخدم نطاقًا غير نطاق الموقع نفسه (وهو سبب شائع لوصول البريد إلى مجلد الرسائل غير المرغوبة)، أو وجود أكثر من 5 حقول مطلوبة، أو غياب حقل الهاتف.
4. أرسل تجربة واحدة لكل نموذج وأبلغني بالنتيجة: mail_sent أو mail_failed أو خطأ تحقق أو رسالة مزعجة.
5. اعرض الإضافات المثبتة وأخبرني ما إذا كانت إضافة SMTP مثبتة ونشطة.

المخرج المطلوب: جدول بهذه الأعمدة: اسم النموذج، الصفحات، المستلم، المرسل، الحقول المطلوبة، نتيجة الاختبار، وإصلاح واحد موصى به. لا تعدّل أي نموذج أو إعداد أو إضافة. إذا تطلّب إصلاح ما تغييرًا، فصف بالضبط ما الذي ستغيّره وانتظر موافقتي.

الموقع الإلكترونييجري تغييرات بعد موافقتك

إعداد إرسال بريد نموذج الاتصال على موقعي المستضاف باستخدام حساب Gmail الخاص بي

يفحص نموذج الاتصال في موقعك المستضاف، ويربط حساب Gmail أو Yandex الخاص بك كمرسل بعد موافقتك على الإعداد، ويرسل بريدًا تجريبيًا ويتأكد من تسجيل العميل المحتمل.

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

يعمل موقعنا على خادم استضافة Opus Growth. يجب أن يرسل نموذج الاتصال بريدًا إلكترونيًا بكل عميل محتمل جديد إلى [عنوان Gmail أو Yandex].

1. اعرض خوادمي. إذا كان هناك أكثر من خادم، اسألني أيها يستضيف هذا الموقع. ثم اعرض عنوان الموقع وحالته.
2. اعرض ملفات الموقع، وابحث عن صفحة الاتصال واقرأها. أخبرني أي نموذج موجود وما الحقول التي يرسلها فعليًا (الاسم، الهاتف، البريد الإلكتروني، الخدمة، الرسالة). نبّهني إلى أي حقل ناقص من هذه القائمة، وأخبرني هل يرسل النموذج بياناته بالفعل إلى relay الخاص بـ Opus Growth.
3. أخبرني بالضبط ما الذي تحتاجه مني لربط صندوق بريدي الخاص ولماذا. في Gmail هو كلمة مرور تطبيق من Google وليس كلمة مروري العادية. وفي Yandex، أخبرني أيضًا هل تلزم كلمة مرور تطبيق.
4. قبل تطبيق أي شيء، اعرض لي الإعدادات التي تنوي ضبطها: المزوّد، وحساب الإرسال (from_email)، والمستلم (to_email)، وسطر موضوع ثابت واحد، مثل "عميل محتمل جديد من [اسم الموقع]". يستخدم الـ relay موضوعًا ثابتًا واحدًا وليس فيه إعداد reply-to. سيظهر اسم الزائر وبريده وبقية الحقول في نص الرسالة، لذلك سأرد عليه بنسخ عنوانه من هناك.
5. طبّق الإعدادات فقط بعد تأكيدي، مع تفعيل send_test ليُرسل بريد تجريبي فورًا. أخبرني هل أُرسل الاختبار أم ما الخطأ الذي ظهر.
6. اقرأ صفحة الاتصال المنشورة وتأكد أن النموذج يرسل بياناته إلى الـ relay. إذا احتاج النموذج إلى تعديل (action خاطئ، أو حقل هاتف ناقص، أو أسماء حقول لن تصل)، فاعرض لي الكود بالضبط قبل التعديل وبعده وانتظر موافقتي قبل تعديل الملف.
7. اطلب مني إرسال إدخال تجريبي واحد على النموذج المنشور. ثم اجلب عمليات إرسال النموذج خلال آخر يوم وتأكد أن إدخالي موجود وكل حقوله معبأة، وهل سُلّم أم فشل مع ظهور خطأ.

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

الموقع الإلكترونييجري تغييرات بعد موافقتك

استرجاع العملاء المحتملين الذين استلمهم نموذج الاتصال ولم يُرسَل بريد بشأنهم

يجلب كل عمليات إرسال نموذج الاتصال، ويفصل العملاء المحتملين الذين فشل إرسال بريدهم، ويعدّ قائمة اتصال بعد استبعاد الرسائل المزعجة، ويحدد تاريخ بدء الأعطال، ويقترح إصلاحًا للـ relay بانتظار موافقتك.

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

أشك في أننا نفقد عملاء محتملين لأن رسائل النموذج لم تُسلَّم. اعرض خوادمي (واسألني أيها المقصود إن كان هناك عدة خوادم)، ثم اجلب كل عمليات إرسال نموذج الاتصال من موقعي المستضاف خلال آخر [30] يومًا. استخدم حدًا مرتفعًا، وأخبرني إذا بدت النتيجة مقتطعة لكي نضيّق النطاق الزمني.

1. قسّمها إلى مجموعتين: مُسلَّمة، وفاشلة أو غير مُرسَلة (delivered:false).
2. للمجموعة الفاشلة، أنشئ جدولًا: التاريخ والوقت، الاسم، الهاتف، البريد الإلكتروني، الخدمة المطلوبة، ملخصًا من سطر واحد للرسالة، ونص الخطأ المخزّن. استخدم الحقول التي يرسلها النموذج فعليًا وضع علامة فارغ على الحقول الناقصة. رتّب من الأحدث إلى الأقدم وضع علامة "اتصل اليوم" على كل ما مضى عليه أقل من 48 ساعة. إذا وصلت حقول تتبع مثل gclid أو utm_source فأضف عمودًا يوضح المصدر.
3. انقل الرسائل المحتمل أنها مزعجة إلى قائمة منفصلة: بلا هاتف وبلا بريد إلكتروني، أو فيها روابط، أو نصها لا علاقة له بخدماتنا.
4. باستخدام الطوابع الزمنية في السجلات، احسب عدد الأعطال في كل يوم وأخبرني متى بدأت وهل فشلت كل عمليات الإرسال بعد ذلك التاريخ أم بعضها فقط.

اختم بما يلي: إجمالي العملاء المحتملين الحقيقيين المفقودين، والسبب الأرجح بناءً على نصوص الأخطاء المخزّنة (مثل انتهاء صلاحية كلمة مرور التطبيق أو إلغائها، أو حصة الإرسال، أو رفض مؤقت)، والحل الذي توصي به. اجمع الأخطاء المتطابقة معًا. إذا كان حقل الخطأ فارغًا أو غامضًا، فقل بوضوح إن السبب استنتاج من نمط الأعطال وليس تشخيصًا مؤكدًا. إذا كان الحل كلمة مرور تطبيق جديدة أو تصحيح إعدادات البريد، فاعرض لي الإعدادات التي ستطبقها بالضبط وانتظر موافقتي. وبعد موافقتي، طبّقها مع تفعيل send_test وأخبرني هل أُرسل البريد التجريبي.

الموقع الإلكترونييجري تغييرات بعد موافقتك

أرسل الأعمال المحجوزة من عملاء النماذج المحتملين إلى Google Ads وMeta

يتحقق من أن نماذج العملاء المحتملين في WordPress تلتقط معرّفات النقر، ويُعدّ إجراء تحويل عبر استيراد النقرات، ويتحقق من قائمة الأعمال المحجوزة لديك ويرفعها إلى Google Ads وMeta Conversions API بعد موافقتك.

متى تستخدمهعندما لا يرى Google Ads وMeta سوى تعبئة النماذج وتريد أن يحسّنا الأداء بناءً على الأعمال التي حجزتها فعلًا.

ليس كل عميل محتمل من النماذج يتحول إلى عمل مدفوع. أريد أن يتعلم Google Ads وMeta من الأعمال التي حجزناها فعلًا، وليس من تعبئة النماذج فقط.

1. في [الموقع]، اعرض نماذج Contact Form 7 واقرأ حقول نموذج العملاء المحتملين الرئيسي. ثم اقرأ الصفحة المنشورة [URL صفحة التواصل] وابحث عن الحقول المخفية في HTML. هل يوجد حقل مخفي يلتقط gclid من عنوان URL للصفحة المقصودة، وآخر يلتقط fbclid (أو ملف تعريف الارتباط _fbc)؟ إن لم يوجد، توقف وأخبرني بالضبط ما الحقول المخفية التي يجب إضافتها والنص البرمجي الصغير الذي يملؤها من URL، قبل أن نتابع. لا تغيّر أي شيء في الموقع.
2. في Google Ads، اعرض إجراءات التحويل وإعداداتها. هل يوجد إجراء "استيراد من النقرات" للأعمال المحجوزة؟ اعرض نوع العدّ والقيمة الافتراضية ونافذة الرجوع للنقرات، وأخبرني إن كانت التحويلات المحسّنة للعملاء المحتملين مفعّلة على مستوى الحساب. إذا لم يوجد إجراء مناسب، اعرض معاينة لإجراء جديد: الاسم "Booked job"، النوع UPLOAD_CLICKS، الفئة PURCHASE، القيمة الافتراضية [متوسط قيمة الخدمة]. لا تنشئه إلا بعد موافقتي.
3. ابحث عن حساب إعلانات Meta الخاص بي وعن البكسل الذي سنرسل إليه أحداث الخادم.
4. سألصق الأعمال المحجوزة خلال آخر 30 يومًا: معرّف العمل، الاسم، الهاتف، البريد الإلكتروني، gclid، fbclid (إن وُجد)، تاريخ ووقت الحجز، قيمة العمل. تحقق من القائمة وأشر إلى:
   - الصفوف التي لا تحتوي على gclid (لا يمكن إرسالها إلى Google)،
   - النقرات الأقدم من نافذة الرجوع للإجراء أو من 90 يومًا،
   - الصفوف التي لا تحتوي على بريد إلكتروني ولا هاتف ولا fbclid (لا تستطيع Meta مطابقتها)،
   - أحداث Meta الأقدم من 7 أيام (ترفض Meta معظم أحداث الخادم بعد ذلك، فأخبرني إن كنت بحاجة إلى روتين أسبوعي)،
   - معرّفات الأعمال المكررة.
   عند وجود fbclid، أنشئ قيمة fbc بالصيغة fb.1.<click time in milliseconds>.<fbclid>.
5. جهّز عمليات الرفع. Google: gclid، وتاريخ ووقت التحويل مع المنطقة الزمنية [فرق التوقيت، مثال: +03:00]، والقيمة، والعملة [العملة]، وorder_id = معرّف العمل. Meta: event_name Purchase، والقيمة، والعملة، والبريد الإلكتروني والهاتف (يتولى الأداة تشفيرهما بالتجزئة)، وfbc عند توفره، وaction_source system_generated، وevent_id = معرّف العمل. شغّل الأداتين أولًا في وضع المعاينة واعرض عدد الصفوف لكل منصة وكل صف تم تخطيه مع السبب. بالنسبة إلى Meta، اعرض إرسال صف واحد برمز حدث اختبار قبل الدفعة الكاملة. لا ترفع إلا بعد تأكيدي.

الموقع الإلكترونييجري تغييرات بعد موافقتك

أنشئ صفحة مقصودة لـ Google Ads تطابق رسالة الإعلان الفائز

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

متى تستخدمهعندما تصل زيارات Google Ads إلى صفحة عامة وتريد صفحة مخصصة تطابق رسالة الإعلان التي تحقق التحويلات بالفعل.

أنشئ صفحة مقصودة مخصصة على موقعي المستضاف لحملة Google Ads [اسم الحملة].

1. ابحث عن الحملة ومجموعاتها الإعلانية، ثم اقرأ إعلانات RSA النشطة. من تقرير أصول RSA لآخر 30 يومًا، اختر العناوين الثلاثة الأعلى تحويلًا، مع احتساب العناوين التي حصلت على 1,000 ظهور على الأقل فقط. يجب أن يتردد عنوان الصفحة صدى للعنوان الأول حتى تطابق الرسالة ما نقر عليه الناس. إذا كان عدد العناوين المؤهلة أقل من 3، أخبرني واستخدم أفضل المتاح.
2. اقرأ دليل تصميم الموقع، واعرض الملفات الموجودة، واقرأ الصفحة الرئيسية وملف CSS المشترك حتى تعيد الصفحة استخدام أنماط الموقع وخطوطه وألوانه.
3. تحقق من النموذج: ستحتوي الصفحة على نموذج قصير، لذا تحتاج إلى ترحيل النموذج إلى البريد الإلكتروني. تحقق من عمليات إرسال النموذج الأخيرة؛ إذا لم توجد أي منها أو فشل التسليم، فاقترح إعداد الترحيل باستخدام صندوق بريدي [عنوان Gmail أو Yandex] يرسل إلى [عنوان المستلم] (في حالة Gmail سألصق كلمة مرور تطبيق). اعرض الإعدادات قبل تطبيقها وأرسل رسالة اختبار. أضف حقولًا مخفية لـ gclid وgbraid وwbraid ومعاملات utm حتى يرافق المصدر كل عميل محتمل.
4. البنية: قسم رئيسي (hero) بالرسالة الفائزة، و3 كتل للمزايا، وقسم إثبات (ادعاءات يمكنني دعمها فقط، دون أرقام أو شهادات مختلقة)، ونموذج قصير في أعلى الصفحة، و4 أسئلة شائعة، ودعوة واحدة لاتخاذ إجراء تتكرر مرتين. بلا قائمة تنقل وبلا روابط خارجية.

اعرض لي النص الكامل ومخطط الأقسام أولًا وانتظر موافقتي. ثم اكتبها في /drafts/[slug الصفحة] مع وسم meta من نوع noindex وأرسل لي لقطة شاشة لسطح المكتب وأخرى للجوال. بعد موافقتي الثانية، اكتب النسخة النهائية (بدون noindex) في /[slug الصفحة]، وتأكد من أن URL المنشور يعيد HTTP 200 ويحتوي على H1 واحد بالضبط، وأرسل إدخالًا تجريبيًا واحدًا عبر النموذج فقط إذا وافقت. لا تلمس عنوان URL النهائي للحملة. أعطني عنوان URL الدقيق لأحدّثه بنفسي.

الموقع الإلكترونييجري تغييرات بعد موافقتك

أصلح العناوين والأوصاف التعريفية وschema في كامل الموقع المستضاف

جدول بمشكلات SEO لكل صفحة مع إصلاحات مقترحة للعناوين والأوصاف وH1 وcanonical وJSON-LD، تُطبَّق بعد موافقتك فقط.

متى تستخدمهعندما تكون عناوين موقعك أو أوصافه التعريفية أو schema غير متسقة أو مفقودة أو مكررة وتريد إصلاحها دفعة واحدة.

دقّق أساسيات SEO داخل الصفحة لكل صفحات HTML على موقعي المستضاف وأصلحها في مرور واحد منضبط.

اقرأ أولًا دليل SEO الخاص بالموقع واستخدم قواعده للعناوين والأوصاف وعناوين canonical ورسم @id الخاص بـ schema.org. ثم اعرض ملفات الموقع، واقرأ كل صفحة HTML، ونفّذ تدقيق SEO للصفحة الرئيسية ولـ [عنوان URL لصفحة الخدمة الرئيسية].

سلّم جدولًا يضم: مسار الصفحة، العنوان الحالي (عدد الأحرف)، الوصف التعريفي الحالي (عدد الأحرف)، عدد H1، canonical، أنواع JSON-LD الموجودة، المشكلة، الإصلاح المقترح.

أشر إلى الصفحة إذا: كان العنوان خارج نطاق 50 إلى 60 حرفًا، أو كان الوصف خارج نطاق 140 إلى 160 حرفًا أو مكررًا، أو لم يوجد H1 أو وُجد أكثر من واحد، أو كان canonical مفقودًا أو لا يشير إلى الصفحة نفسها، أو كان نوع schema لا يناسب نوع الصفحة في الدليل.

اكتب العناوين والأوصاف المقترحة بلغة واضحة ومحددة مع وضع الكلمة المفتاحية الرئيسية قرب البداية. بلا حشو للكلمات المفتاحية.

اعرض لي كل تعديل على هيئة فرق قبل/بعد وانتظر موافقتي. بعد أن أوافق، طبّق التعديلات، وأعد قراءة 3 صفحات معدلة على الموقع المنشور وتأكد من أن الوسوم الجديدة تُقدَّم فعليًا.

الموقع الإلكترونييجري تغييرات بعد موافقتك

احمِ الزيارات العضوية بعد إعادة التصميم بخريطة إعادة توجيه 301

يعثر على عناوين URL القديمة التي حصلت على نقرات عضوية، ويتحقق من العناوين التي تعيد الآن 404 أو 410، ويربط كل واحد بأفضل صفحة جديدة حسب الموضوع، وينشئ عمليات إعادة التوجيه 301 بعد موافقتك فقط، ثم يتحقق منها.

متى تستخدمهعندما تكون قد أعدت إطلاق موقعك أو أعدت تصميمه وتخشى أن تعيد عناوين URL القديمة الآن 404 وأنك تفقد زيارات عضوية.

أعدنا إطلاق الموقع على خادم الاستضافة في [تاريخ إعادة الإطلاق] وأحتاج إلى التأكد من أن أي زيارات عضوية لم تُفقد بسبب عناوين URL معطلة.

1. ابحث عن خاصية Search Console المطابقة وخادم الاستضافة الخاص بـ [النطاق].
2. اسحب بيانات Search Console حسب الصفحة والاستعلام معًا، مرتبة حسب النقرات. يحسب Search Console الأيام بدءًا من اليوم، لذا اضبط فترة الرجوع لتغطي 90 يومًا قبل [تاريخ إعادة الإطلاق] بالإضافة إلى الأيام التي تلته؛ أخبرني بالنافذة الزمنية الدقيقة التي استخدمتها ونبّهني إلى أنها تتضمن بعض النقرات بعد إعادة الإطلاق. إذا لصقت تصدير Search Console للنافذة الدقيقة قبل إعادة الإطلاق، فاستخدمه بدلًا من ذلك. ومن ذلك، احتفظ بالصفحات التي لديها 10 نقرات على الأقل وخذ أعلى استعلام لكل صفحة من البيانات نفسها.
3. اطلب كل عنوان من عناوين URL هذه على الموقع المباشر، بدءًا من الأعلى نقرات، على دفعات، وسجّل حالة HTTP وأي ترويسة Location.
4. اعرض قواعد إعادة التوجيه الحالية وملفات الموقع الحالية. لكل عنوان URL يعيد 404 أو 410، اقترح أقرب صفحة جديدة مطابقة حسب الموضوع، وليس فقط حسب تشابه الـ slug (اقرأ مخطط الصفحة المرشحة إذا لزم الأمر). إذا لم توجد صفحة مطابقة جيدة، فاذكر ذلك بدلًا من توجيهه إلى الصفحة الرئيسية.

قدّم جدولًا: عنوان URL القديم، النقرات (النافذة)، أعلى استعلام، الحالة الحالية، وجهة 301 المقترحة، مستوى الثقة (عالٍ/متوسط/منخفض).

رتّبه حسب النقرات. أشِر إلى أي قاعدة مقترحة قد تنشئ سلسلة أو حلقة مع قواعد إعادة التوجيه الموجودة. اعرض عليّ الخريطة الكاملة كمعاينة لإعادة التوجيه وانتظر موافقتي قبل إنشاء أي عملية إعادة توجيه.

بعد موافقتي، أضف عمليات 301 (المسارات كمصدر، مع الإبقاء على القواعد الحالية)، واطلب كل عنوان URL قديم مجددًا للتأكد من أنه يعيد 301 واحدة فقط تعيد وجهتها 200، وافحص أعلى 5 وجهات من حيث النقرات في Search Console للتأكد من أنها مفهرسة أو قابلة للفهرسة مع canonical المتوقع. اختم بـ 3 أسطر يمكنني إرسالها إلى الإدارة: عناوين URL التي تم إصلاحها، النقرات المحمية، البنود المفتوحة.

الموقع الإلكترونييجري تغييرات بعد موافقتك

اعثر على تعديل كسر الموقع وتراجع عنه باستخدام لقطات الإصدارات

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

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

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

0. اعرض خوادمي ومواقعي أولًا. لقطات الإصدارات موجودة فقط على خوادم استضافة Opus Growth. إذا كان [URL الصفحة المتأثرة] ينتمي إلى موقع WordPress متصل عبر الإضافة، فتوقف وأخبرني، لأن طريقة الاستعادة هذه لا تنطبق هناك. إذا كان الخادم يستضيف أكثر من موقع، فاستخدم الموقع الذي يخدم [URL الصفحة المتأثرة].

1. اقرأ [URL الصفحة المتأثرة] مباشرة: حالة HTTP وترويسات الاستجابة وHTML (استخدم عرض المخطط إذا كانت الصفحة كبيرة). التقط لقطات شاشة لسطح المكتب والجوال.

2. اعرض اللقطات التلقائية، وتصفح للخلف حتى تغطي آخر 14 يومًا. اختر اللقطات القريبة من [الوقت التقريبي للتعديل]. تحمل اللقطات وقتًا وتسمية، وليس اسم الشخص الذي أجرى التعديل، لذا اعتمد على الوقت والتسمية فقط ولا تخمّن من غيّر ماذا.

3. لكل ملف مشتبه به، اعرض الفرق (diff) بين اللقطة التي سبقت التعديل مباشرة والملف الحالي. اقرأ الملف الحالي إذا احتجت إلى مزيد من السياق. اشرح بلغة بسيطة ما الذي تغيّر ولماذا يسبب هذا العرض.

4. أوصِ بأضيق إصلاح: ملف واحد، أو مجلد واحد، أو الموقع كله فقط إذا كانت هناك عدة ملفات معنية. اذكر أي تغييرات لاحقة منذ تلك اللقطة ستُفقد أيضًا. إذا كان للموقع مجلد مصدر .src/ (مشروع بناء)، فنبّهني إلى أن الاستعادة ستُستبدل عند إعادة البناء التالية ما لم يُنقل الإصلاح إلى المصدر أيضًا.

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

اختم بملاحظة حادثة من 4 أسطر للإدارة: ما الذي تعطل، ومتى (بناءً على أوقات اللقطات)، ومدة التأثير، وما الذي تمت استعادته.

الموقع الإلكترونيللقراءة فقط

تحقق من أن كل صفحة هبوط في Google Ads تطابق الإعلان الذي يرسل الزيارات إليها

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

متى تستخدمهعندما يكون معدل التحويل في صفحات الهبوط لحملات Google Ads منخفضًا وتشك في أن الصفحة لا تطابق الوعد الذي قدّمه الإعلان.

في حساب Google Ads الخاص بي [اسم الحساب]، ابحث عن صفحات الهبوط التي حصلت على أعلى إنفاق خلال آخر 30 يومًا.

1. نفّذ استعلام GAQL على landing_page_view لآخر 30 يومًا مع landing_page_view.unexpanded_final_url وmetrics.cost_micros وmetrics.clicks وmetrics.conversions. احسب معدل التحويل بقسمة التحويلات على النقرات. اختر أعلى 5 روابط URL من حيث التكلفة.
2. نفّذ استعلام GAQL ثانيًا على ad_group_ad للإعلانات المتجاوبة في البحث المفعّلة، مع إرجاع ad_group_ad.ad.id وad_group.id وcampaign.name وad_group_ad.ad.final_urls، ثم اربط كل إعلان بأعلى 5 روابط URL.
3. بالنسبة للإعلانات المرتبطة، اجلب العناوين والأوصاف باستخدام get_ad_details. استخدم rsa_asset_performance لمعرفة أي العناوين حصلت فعلًا على أكبر عدد من مرات الظهور، لتقارن الصفحة بالنص الذي رآه الناس فعلًا.
4. اقرأ كل صفحة منشورة كما يراها الزائر: مرة باستخدام outline=true للحصول على العنوان والوصف التعريفي (meta description) وH1، ومرة باستخدام text=true للحصول على النص المرئي.
5. قارن بينها. هل يكرر H1 والنص الافتتاحي للصفحة الوعد أو العرض أو الخدمة المذكورة في الإعلانات؟ هل السعر أو الخصم المذكور في الإعلان ظاهر في أي مكان بالصفحة؟ هل توجد دعوة واضحة واحدة إلى اتخاذ إجراء تتطابق مع الدعوة في الإعلان؟

قدّم جدولًا بهذه الأعمدة: URL، التكلفة، معدل التحويل، وعد الإعلان، ما تقوله الصفحة فعليًا، الفجوة، وحل في جملة واحدة. ضع علامة أولوية على أي صفحة يقل معدل التحويل فيها عن [معدل التحويل المستهدف، مثال: 3%]. لا تغيّر أي إعلان أو صفحة. هذه مراجعة فقط.

الموقع الإلكترونييجري تغييرات بعد موافقتك

فحص سرعة الجوال للصفحات التي تصل إليها ميزانية إعلاناتك

يرتّب صفحات الهبوط لديك حسب النقرات من الجوال، ويقيس Core Web Vitals على الجوال لأهم 5 صفحات، وإن كانت على موقع WordPress الخاص بك يوصي بما يصل إلى 3 إعدادات سرعة آمنة مع معاينة وإمكانية التراجع.

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

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

1. في Google Ads [اسم الحساب]، نفّذ استعلام GAQL على landing_page_view لآخر 30 يومًا، مقسّمًا حسب segments.device، مع landing_page_view.unexpanded_final_url وmetrics.clicks وmetrics.cost_micros وmetrics.speed_score وmetrics.mobile_friendly_clicks_percentage. احتفظ بصفوف MOBILE فقط واعرض روابط URL النهائية الأعلى نقرات من الجوال. إذا ظهرت درجة السرعة أو نسبة النقرات المتوافقة مع الجوال فارغة لأي رابط URL، فاذكر ذلك بدلًا من التخمين.
2. نفّذ core_web_vitals مع strategy=mobile على أعلى 5 روابط URL. أبلغ عن LCP وINP وCLS. استخدم قيمة المستخدمين الفعليين (field) لـ INP عند توفرها؛ وإن لم تتوفر، فأبلغ عن TBT من بيانات المختبر ووضّح أنه قيمة تقريبية بديلة. اعتبر LCP أعلى من 2.5 ثانية وINP أعلى من 200 مللي ثانية وCLS أعلى من 0.1 غير ناجحة.
3. فقط إذا كانت روابط URL هذه على موقع WordPress الخاص بي [URL الموقع]، نفّذ wordpress_performance واعرض أي إضافة تخزين مؤقت تعمل عليه، وأي التحسينات مفعّلة بالفعل، وأيها موسوم بأنه محفوف بالمخاطر لهذا الموقع. وإذا كانت الصفحات في مكان آخر، فتخطَّ هذه الخطوة وأخبرني بذلك.

قدّم لي جدولًا بهذه الأعمدة: URL، النقرات من الجوال، التكلفة، LCP، INP (أو TBT)، CLS، ناجح أو غير ناجح، والسبب المرجّح. ثم أوصِ بثلاثة إعدادات سرعة على الأكثر لتفعيلها، بدءًا بالأكثر أمانًا (التخزين المؤقت للصفحة، التخزين المؤقت للمتصفح، التصغير، التحميل الكسول قبل أي شيء محفوف بالمخاطر). اعرض لي بالضبط ما الذي سيتغير وانتظر موافقتي قبل تطبيق أي شيء. طبّق التغييرات الموافق عليها واحدًا تلو الآخر، وامسح ذاكرة التخزين المؤقت بعد كل تغيير، ثم أعد تشغيل core_web_vitals على أسوأ صفحة. أخبرني كيف أتراجع عن كل تغيير (revert=true يتراجع عن آخر تغيير فقط).

الموقع الإلكترونيللقراءة فقط

تحقق من أن علامات التحويل تعمل فعلًا في صفحة الهبوط الخاصة بإعلاناتي

تشخيص واضح لعلامات Google المفقودة أو المكررة أو المعطلة في صفحة الهبوط الخاصة بك، ولإجراءات التحويل التي لا تسجّل أي شيء.

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

لست متأكدًا من أن إعلاناتي تسجّل التحويلات بشكل صحيح. تحقق من التتبع في صفحتي المقصودة الرئيسية [URL صفحة الهبوط].

1. افحص الصفحة واذكر كل وسوم القياس التي تحمّلها (حاوية GTM، وGA4، ووسم Google Ads).
2. في موقعي على WordPress، اعرض كل مكان يُضاف فيه وسم GTM أو GA4: إضافة، أو مقتطف برمجي، أو كود الترويسة، أو القالب. نبّه إلى التكرارات. تحميل معرّف GA4 أو GTM نفسه مرتين يُعد مشكلة.
3. في حاوية GTM الخاصة بي، اذكر الوسوم ومشغّلاتها. تحقق من أن وسم تحويل Google Ads يعمل في صفحة الشكر أو عند إرسال النموذج، وليس عند كل مشاهدة للصفحة.
4. في Google Ads، اذكر إجراءات التحويل لدي ونبّه إلى أي إجراء أساسي لم يسجّل أي تحويلات خلال آخر 30 يومًا. قارن معرّف التحويل والتسمية في GTM بما يتوقعه Google Ads.

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

الموقع الإلكترونييجري تغييرات بعد موافقتك

اختبر نموذج الاتصال الذي يعتمد عليه زوار إعلاناتي المدفوعة

يدقق نموذج Contact Form 7 في صفحتك المقصودة للإعلانات، ويرسل إدخال اختبار واحدًا بعد موافقتك، ويتحقق في GA4 من وجود حدث للنموذج، ويحدد أين قد تضيع العملاء المحتملون.

متى تستخدمهعندما توجّه زيارات مدفوعة إلى صفحة تحتوي على نموذج Contact Form 7 وتشك في أن بعض العملاء المحتملين لا يصلون أبدًا إلى بريدك الوارد.

تقود إعلاناتي الناس إلى صفحة تحتوي على نموذج Contact Form 7، وأشك في أن بعض العملاء المحتملين لا يصلون أبدًا إلى بريدي الوارد.

1. اذكر نماذج Contact Form 7 في موقعي على WordPress [URL الموقع]. ابحث عن النموذج المستخدم في [URL صفحة الهبوط] بقراءة تلك الصفحة ومطابقة معرّف الشورت كود contact-form-7.
2. اعرض حقوله، وأيها إلزامي، وعناوين البريد الإلكتروني للمستلم والمرسل في إعداداته. نبّه إلى كثرة الحقول الإلزامية (أكثر من 4 علامة تحذير لنموذج جمع العملاء المحتملين) وإلى أي عنوان مستلم لا يطابق [عنوان بريدي الإلكتروني].
3. جهّز إدخال اختبار واحدًا موسومًا بوضوح بعبارة "TEST - please ignore" واعرض لي المعاينة أولًا، لأنه يرسل بريدًا إلكترونيًا حقيقيًا. بعد موافقتي، أرسله وأخبرني بالنتيجة: mail_sent أو mail_failed أو validation_failed (مع الحقول المرفوضة) أو spam. إذا ظهرت mail_sent، ذكّرني بالتحقق من وصول البريد فعلًا إلى [عنوان بريدي الإلكتروني]، بما في ذلك مجلد الرسائل غير المرغوب فيها، لأن الأداة لا تستطيع سوى تأكيد أن WordPress أرسله.
4. في GA4، اذكر الأحداث الرئيسية، ثم شغّل ga4_report لآخر 30 يومًا مع dimension=landing_page وdimension2=event. تحقق مما إذا كانت صفحة النموذج تسجّل أي حدث إرسال نموذج أو عميل محتمل. إذا لم يُقبل هذا المزيج، شغّل dimension=event وأخبرني بعدد أحداث النموذج دون تقسيمها حسب الصفحة.

لخّص في 5 نقاط أو أقل: هل يعمل النموذج، وأين قد يضيع العملاء المحتملون، وأهم إصلاح واحد. لا تغيّر النموذج ولا الصفحة ولا أي تتبع. إذا لزم إصلاح، صف التغيير بدقة وانتظر موافقتي.

الموقع الإلكترونيللقراءة فقط

اكتشف أين تضيع نقرات إعلانات Meta قبل تحميل الصفحة المقصودة

يقارن النقرات على الرابط بمشاهدات الصفحة المقصودة لكل إعلان في Meta، ثم يفحص وجهة كل إعلان ضعيف: الحالة وإعادات التوجيه وتطابق الرسالة وLCP على الجوال.

متى تستخدمهعندما تدفع مقابل النقرات على الرابط في Meta لكن يبدو أن كثيرًا من الناس يغادرون قبل تحميل صفحتك المقصودة.

في Meta، أدفع مقابل النقرات على الرابط، لكن كثيرًا من الناس قد يغادرون قبل تحميل صفحتي. تحقق من ذلك في حساب إعلاناتي [اسم حساب الإعلانات].

1. اذكر الإعلانات واحتفظ بتلك التي تكون قيمة effective_status فيها ACTIVE. لآخر 14 يومًا، اجلب spend وinline_link_clicks وactions على مستوى الإعلان (مع ad_id وad_name)، واقرأ مشاهدات الصفحة المقصودة من الإجراء landing_page_view. احسب مشاهدات الصفحة المقصودة مقسومة على النقرات على الرابط. نبّه إلى أي إعلان أقل من 70% أنفق أكثر من [الحد الأدنى للإنفاق، مثال: 500 TL].
2. لكل إعلان تم التنبيه إليه، اقرأ المحتوى الإبداعي واحصل على رابط الوجهة والعنوان والنص الأساسي، إضافة إلى أي معاملات URL يحملها المحتوى الإبداعي.
3. افتح كل URL وجهة كما يفعل الزائر. أبلغ عن حالة HTTP. إذا كانت الاستجابة إعادة توجيه (حالة 3xx أو ترويسة Location)، افتح الهدف أيضًا واستمر حتى تصل إلى 200 أو إلى خطأ، حتى تتمكن من عرض سلسلة إعادات التوجيه. اقرأ الصفحة النهائية مع outline=true وtext=true وأخبرني ما إذا كان عنوانها ومحتواها يطابقان عنوان الإعلان وعرضه، وما إذا كانت معاملات URL قد بقيت حتى URL النهائي.
4. شغّل core_web_vitals مع strategy=mobile على كل وجهة نهائية وأبلغ عن LCP.

قدّم جدولًا بهذه الأعمدة: اسم الإعلان، والإنفاق، والنقرات على الرابط، ومشاهدات الصفحة المقصودة، والنسبة، وURL الوجهة، والحالة، وإعادات التوجيه، وLCP، والسبب المحتمل. اختم بأهم 3 إصلاحات تستعيد أكبر عدد من النقرات المدفوعة. هذا تحليل فقط، لذا لا توقف أي إعلان ولا تعدّله.

الموقع الإلكترونييجري تغييرات بعد موافقتك

اكتشف عناوين URL النهائية المعطلة أو المعاد توجيهها في Google وMicrosoft Ads

يجمع كل عناوين URL النهائية من الإعلانات النشطة وروابط الموقع الفرعية في Google وMicrosoft Ads، ويتحقق من الحالة وقفزات إعادة التوجيه وفقدان المعاملات، ويجهّز إصلاحات عناوين URL كمعاينات بانتظار موافقتك.

متى تستخدمهعندما تغيّر صفحات في موقعك أو تحذفها وتريد التأكد من أن أي إعلان في Google أو Microsoft لا يرسل الناس إلى صفحة معطلة أو معاد توجيهها.

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

1. اجمع كل عناوين URL النهائية الفريدة:
   - Google Ads [حساب Google Ads]: نفّذ استعلام GAQL على ad_group_ad للإعلانات النشطة في الحملات والمجموعات الإعلانية النشطة، بحيث يعيد campaign.name وad_group.name وad_group_ad.ad.id وad_group_ad.ad.final_urls. ثم اعرض روابط الموقع الفرعية (sitelinks) باستخدام list_extension_assets وخذ عناوين URL النهائية الخاصة بها.
   - Microsoft Ads [حساب Microsoft Ads]: اعرض الحملات، ثم المجموعات الإعلانية في كل حملة، ثم الإعلانات في كل مجموعة إعلانية، وخذ عنوان URL النهائي لكل إعلان. اعرض روابط الموقع الفرعية باستخدام list_microsoft_ad_extensions.
   احتفظ بخريطة توضح أي حملة أو مجموعة إعلانية أو إعلان أو رابط موقع فرعي يستخدم كل عنوان URL.
2. افتح كل عنوان URL كما يفعل الزائر، مع إضافة معامل اختبار (?utm_source=opus_test&gclid=opus_test). سجّل رمز حالة HTTP. إذا كانت الاستجابة إعادة توجيه (حالة 3xx أو ترويسة Location)، فافتح الوجهة أيضًا وكرر العملية حتى تصل إلى 200 أو إلى خطأ. سجّل عدد عمليات إعادة التوجيه وعنوان URL النهائي الذي وصلت إليه.
3. ضع علامة على هذه الحالات: أخطاء 4xx أو 5xx؛ أكثر من عملية إعادة توجيه واحدة؛ إعادة توجيه إلى الصفحة الرئيسية بدلاً من الصفحة المحددة؛ ومعاملات الاختبار المفقودة من عنوان URL النهائي.

جمّع النتائج حسب الخطورة: معطلة (أصلحها اليوم)، معاد توجيهها (أصلحها هذا الأسبوع)، سليمة. لكل عنوان URL معطل، اعرض ما يستخدمه واقترح صفحة بديلة مناسبة من موقعي. للعثور على الصفحات المرشحة، اقرأ [URL الموقع]/sitemap.xml؛ وإذا كان موقعي موقع WordPress متصلاً، فاعرض أيضًا صفحاته ومقالاته المنشورة. وإذا لم ينجح أي منهما، فاطلب مني لصق قائمة عناوين URL للصفحات الحالية.

جهّز تغييرات عناوين URL كمعاينات فقط (confirm=false): عناوين URL النهائية لإعلانات RSA في Google باستخدام update_rsa، وروابط الموقع الفرعية في Google باستخدام update_sitelink، وإعلانات RSA في Microsoft باستخدام update_microsoft_responsive_search_ad. لا يمكن تعديل رابط موقع فرعي في Microsoft مباشرة، لذا اعرض معاينة لحذفه وإضافته من جديد بعنوان URL الجديد. لا تطبّق أي تغيير حتى أوافق على كل واحد منها.

الموقع الإلكترونيللقراءة فقط

أصلح الكلمات المفتاحية ذات تجربة صفحة الهبوط الأقل من المتوسط

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

متى تستخدمهعندما تُظهر كلماتك المفتاحية في Google Ads تجربة صفحة هبوط أقل من المتوسط، ويتأثر مستوى الجودة والتكاليف سلبًا.

في Google Ads [اسم الحساب]، ابحث عن الكلمات المفتاحية التي يكون فيها مكوّن تجربة صفحة الهبوط ضمن مستوى الجودة "أقل من المتوسط". أدرج فقط الكلمات المفتاحية التي حصلت على [الحد الأدنى من النقرات، مثال: 50] نقرة على الأقل خلال آخر 30 يومًا.

1. لكل كلمة من هذه الكلمات، اعرض مستوى الجودة ومعدل CTR والتكلفة والتحويلات. افحص سجل مستوى الجودة وأخبرني هل انخفضت تجربة صفحة الهبوط مؤخرًا، وتقريبًا متى.
2. جمّع الكلمات المفتاحية حسب عنوان URL النهائي الذي تشير إليه إعلاناتها.
3. لكل عنوان URL، أجرِ تدقيقًا للصفحة (العنوان، العناوين الفرعية، مدى صلة المحتوى، سهولة الاستخدام على الجوال، السرعة) وافحص Core Web Vitals على الجوال. تحقق مما إذا كانت الكلمة المفتاحية نفسها أو صيغة قريبة منها موجودة في عنوان الصفحة وفي H1.

قدّم قسمًا واحدًا لكل عنوان URL. اذكر الكلمات المفتاحية المتأثرة والمبلغ المنفق عليها، ثم أهم 3 تغييرات في الصفحة يُرجَّح أن ترفع التقييم. وإذا كانت كلمة مفتاحية تنتمي بوضوح إلى صفحة أخرى لدي بالفعل، فأخبرني بذلك. لا تغيّر أي كلمات مفتاحية أو إعلانات.

الموقع الإلكترونييجري تغييرات بعد موافقتك

أعد كتابة عناوين meta لصفحات منتجات WooCommerce ذات معدل CTR العضوي المنخفض

يعثر على صفحات المنتجات التي تظهر في الصفحة الأولى أو الثانية لكنها تحصل على نقرات قليلة، ويربط كل واحدة بمنتجها في WooCommerce، ويصيغ عناوين وأوصاف meta أكثر جاذبية، ويطبّق فقط الصفوف التي توافق عليها ثم يتحقق منها.

متى تستخدمهعندما تظهر صفحات منتجات WooCommerce لديك في الصفحة الأولى أو الثانية من Google لكنها تحصل على نقرات قليلة، وتشتبه في ضعف عناوين وأوصاف meta.

الموقع: [موقع WordPress]. خاصية Search Console: [الخاصية]. تحتوي عناوين URL للمنتجات على: [مسار URL للمنتج].

1. اجلب أداء آخر 90 يومًا من النتائج العضوية باستخدام gsc_performance، مع dimension=page، مرتبًا حسب مرات الظهور، وبحد أعلى كافٍ لتغطية جميع صفحات المنتجات. احتفظ فقط بعناوين URL التي تحتوي على [مسار URL للمنتج].
2. احتفظ فقط بالصفحات التي تستوفي كل ما يلي:
   - 500 مرة ظهور على الأقل
   - متوسط ترتيب بين 3 و15
   - معدل CTR أقل من 2%
3. لكل صفحة متبقية، احصل على أهم 3 استعلامات حسب مرات الظهور: شغّل gsc_performance مع dimension=query وpage=<عنوان URL هذا> وsort=impressions وlimit=3.
4. اربط كل عنوان URL بمنتجه في WooCommerce:
   - خذ الـ slug من عنوان URL وابحث عن منشور المنتج باستخدام wordpress_list_posts (type=product، search=كلمات الـ slug). استخدم المنشور الذي يطابق الـ slug الخاص به عنوان URL تمامًا للحصول على المعرّف.
   - ابحث عن السعر والمخزون باستخدام wordpress_woo_products، مع البحث باسم المنتج الذي وجدته للتو. اقبل النتيجة فقط إذا طابق الاسم ذلك المنتج تمامًا.
   - إذا لم توجد مطابقة تامة أو وُجد أكثر من مرشح، فلا تخمّن. ضع على الصف علامة "unmatched" واذكره بشكل منفصل حتى أزوّدك بمعرّف المنتج.
5. تخطَّ المنتجات التي تُظهر بيانات مخزونها أنها غير متوفرة.
6. لكل صفحة تمت مطابقتها، اقرأ عنوان meta ووصف meta الحاليين باستخدام wordpress_seo (id=معرّف المنتج).

لكل صفحة متبقية، اكتب:
- عنوان meta جديدًا: بحد أقصى 60 حرفًا، مع وضع الاستعلام الرئيسي قرب البداية.
- وصف meta جديدًا: بحد أقصى 155 حرفًا، يتضمن السعر أو فائدة ملموسة وسببًا للنقر. لا تختلق ادعاءات أو شروط شحن أو خصومات.

قدّم جدولًا بهذه الأعمدة: URL، معرّف المنتج، الاستعلام الرئيسي، الترتيب، CTR، العنوان الحالي، العنوان المقترح، الوصف الحالي، الوصف المقترح. اعرض عدد الأحرف للعنوان والوصف المقترحين.

اعتبر هذا الجدول معاينة. لا تغيّر أي شيء حتى أرد عليك بالصفوف التي أوافق عليها. بعد ذلك:
1. اكتب العنوان والوصف المعتمدين باستخدام wordpress_set_seo لكل معرّف منتج موافَق عليه (overwrite=true، لأن هذه الحقول تحتوي على قيم بالفعل).
2. اقرأ كل منتج مرة أخرى باستخدام wordpress_seo وتأكد من أن العنوان والوصف المخزّنين يطابقان ما وافقت عليه. أبلغني بأي صف لم يُحفظ.
3. امسح ذاكرة التخزين المؤقت باستخدام wordpress_purge_cache.
4. ذكّرني بمقارنة CTR لعناوين URL هذه في Search Console بعد 4 إلى 6 أسابيع.

الموقع الإلكترونييجري تغييرات بعد موافقتك

تحقق من تطابق أسعار إعلانات Google وMeta مع أسعار WooCommerce الحالية

يقارن كل سعر وخصم وادعاء بشأن المخزون في إعلانات RSA وروابط الموقع الفرعية (sitelinks) وتصاميم Meta الفعّالة مع كتالوج WooCommerce، ويعرض معاينة لإصلاحات تُجرى على الإعلان نفسه وتحافظ على سجله.

متى تستخدمهعندما غيّرت الأسعار أو المخزون في متجر WooCommerce وتخشى أن تظل إعلانات Google وMeta الفعّالة تعرض أسعارًا أو خصومات أو توافرًا قديمًا.

تغيّرت الأسعار على [موقع WordPress]. تحقق من أن إعلاناتنا الفعّالة ما زالت تطابق المتجر.

1. استعرض جميع منتجات WooCommerce صفحةً صفحة: الاسم وSKU والسعر الحالي والمخزون.
2. في [حساب Google Ads]:
   - اجلب كل إعلانات RSA الممكّنة في المجموعات الإعلانية والحملات الممكّنة باستعلام GAQL واحد على ad_group_ad (معرّف الإعلان، الحملة، المجموعة الإعلانية، العناوين، الأوصاف، عنوان URL النهائي). استخدم get_ad_details فقط عند الحاجة إلى التثبيتات أو الإعلان كاملًا.
   - اقرأ روابط الموقع الفرعية (sitelinks) لجميع الحملات باستخدام list_extension_assets (مع ترك campaign_id فارغًا).
3. في [حساب إعلانات Meta]، اعرض الإعلانات ذات الحالة الفعلية ACTIVE (استخدم list_meta_ads للحساب بالكامل، وأسماء الحملات من list_meta_campaigns) واقرأ تصميم كل إعلان باستخدام get_meta_ad_creative: العنوان والنص الأساسي والوصف ورابط الوجهة والصورة أو الفيديو والزر والصفحة، وهل أُنشئ من منشور موجود على Facebook أو Instagram.
4. ابحث عن كل سعر أو خصم أو ادعاء "متوفر في المخزون" يخص منتجًا. اربطه بمنتج حسب الاسم أو SKU أو عنوان URL للوجهة. وعندما تكون المطابقة غير مؤكدة، قل ذلك بدلًا من فرضها.

قدّم جدولًا: المنصة، الحملة، الإعلان، النص الموجود، المنتج، سعر المتجر، الحالة. تكون الحالة إحدى القيم التالية: match, wrong price, out of stock, product not found, unsure match.

لكل تعارض، اقترح نصًا مصححًا ضمن الحدود التالية:
- عناوين RSA: 30 حرفًا
- أوصاف RSA: 90 حرفًا
- نص sitelink: 25 حرفًا؛ وأسطر وصف sitelink: 35 حرفًا لكل سطر، كلاهما أو لا شيء

اعرض جميع التعديلات كمعاينات بقيمة confirm=false وانتظر موافقتي. بعد الموافقة:
- إعلانات RSA: استخدم update_rsa مع حذف/إضافة العناوين والأوصاف، ليحتفظ الإعلان نفسه بسجله. أبقِ التثبيتات الحالية.
- روابط sitelink: استخدم update_sitelink للتعديل في مكانه.
- Meta: استخدم update_meta_ad_creative، مع تمرير page_id وimage_hash أو video_id والرابط والزر الحالية من التصميم الذي قرأته، بحيث يتغير النص فقط ويحتفظ الإعلان بمعرّفه وبما تعلّمه. لا يمكن إعادة كتابة نص الإعلانات المنشأة من منشور موجود على Facebook أو Instagram بهذه الطريقة: اذكرها لي لأصلحها في المنشور الأصلي أو أستبدلها.
- ذكّرني بأن الإعلانات المعدّلة تعود إلى المراجعة على المنصتين.

الموقع الإلكترونييجري تغييرات بعد موافقتك

أطلق منتجًا جديدًا في WooCommerce مع مجموعة إعلانية جاهزة في بحث Google

ينشئ منتجًا في WooCommerce بعد الموافقة، ويتحقق من أن صفحته تعمل، ثم يبني مجموعة إعلانية موقوفة مؤقتًا في بحث Google مع كلمات مفتاحية تم التحقق من حجم بحثها وكلمات سلبية وإعلان RSA ضمن حملة قائمة.

متى تستخدمهعندما تكون على وشك إضافة منتج جديد إلى متجر WooCommerce الخاص بك وتريد مجموعة إعلانية جاهزة في بحث Google للإعلان عنه.

أضف منتجًا جديدًا إلى [موقع WordPress] وجهّزه للإعلان في [حساب Google Ads].

تفاصيل المنتج: [الاسم، السعر، SKU، وصف مختصر، كمية المخزون].

الخطوة 1: المنتج
- اعرض لي في المحادثة منتج WooCommerce البسيط الذي ستنشئه: الاسم، SKU، السعر، الوصف (ابدأ بالوصف القصير ثم الوصف الكامل الذي تكتبه انطلاقًا من بياناتي) والمخزون.
- أنشئه فقط بعد موافقتي، بحالة publish حتى تكون الصفحة منشورة.
- ابحث عن URL المنتج في الرد، أو باستخدام wordpress_list_posts (النوع product، والبحث بالاسم)، ثم اجلبه باستخدام site_read_url. تأكد من أنه يعيد HTTP 200 وأن العنوان والسعر في الصفحة صحيحان. وإن لم يكونا كذلك، فتوقف وأخبرني.

الخطوة 2: المجموعة الإعلانية، ضمن الحملة القائمة [الحملة]. اقترح:
- مجموعة إعلانية جديدة بحد أقصى افتراضي لتكلفة النقرة يساوي متوسط تكلفة النقرة للحملة خلال آخر 30 يومًا (التكلفة مقسومة على النقرات من performance_report على مستوى الحملة).
- من 10 إلى 15 كلمة مفتاحية بمطابقة العبارة والمطابقة التامة، مبنية على اسم المنتج وفئته ومحفزات نية الشراء.
- أحجام البحث لكل كلمة مفتاحية: شغّل keyword_planner وkeyword_historical_metrics باللغة التركية أو لغة الحملة ومواقع الحملة (اقرأها باستخدام get_campaign_targeting). استبعد المصطلحات التي يقل متوسط عمليات البحث الشهرية لها عن 50.
- كلمات سلبية على مستوى المجموعة الإعلانية مثل مجاني أو مستعمل أو من الدرجة الثانية، فقط حيث لا تتعلق بهذا المنتج.
- إعلان RSA واحد بـ 12 عنوانًا (بحد أقصى 30 حرفًا) و4 أوصاف (بحد أقصى 90 حرفًا) يشير إلى URL المنتج، باستخدام الحقائق المقروءة من صفحة المنتج المنشورة فقط.

اعرض المجموعة الإعلانية كاملة وقائمة الكلمات المفتاحية والكلمات السلبية والإعلان كمعاينات بقيمة confirm=false. انتظر موافقتي قبل إنشاء أي شيء في Google Ads. وبما أن الحملة تعمل بالفعل، فعند الموافقة نفّذ بهذا الترتيب: أنشئ المجموعة الإعلانية، وأوقفها مؤقتًا فورًا باستخدام update_ad_group_status، ثم أضف الكلمات المفتاحية والكلمات السلبية وإعلان RSA (حالة RSA هي ENABLED، بحيث يكون تفعيل المجموعة الإعلانية هو المفتاح الوحيد المتبقي). لا تفعّل المجموعة الإعلانية حتى أخبرك.

الموقع الإلكترونييجري تغييرات بعد موافقتك

حوّل مصطلح بحث مربحًا إلى مسودة صفحة هبوط مخصصة

يعثر على مصطلحات البحث ذات ROAS المرتفع التي تقود حاليًا إلى صفحة عامة، ويجمّعها في محاور، ويفحص التغطية العضوية والتنافس الداخلي بين الصفحات، ثم يكتب مسودة صفحة WordPress مخصصة تتضمن المنتجات والأسئلة الشائعة وحقول meta.

متى تستخدمهعندما تحقق بعض مصطلحات البحث في Google Ads تحويلات جيدة لكنها تقود الزوار إلى صفحتك الرئيسية أو إلى فئة واسعة، وتظن أن صفحة مخصصة ستحقق أداءً أفضل.

ابحث في حساب Google Ads [الحساب] عن مصطلحات البحث خلال آخر 60 يومًا التي تحقق تحويلات مربحة لكنها تقود إلى صفحة عامة، ثم حوّل أفضل محور إلى مسودة صفحة هبوط مخصصة.

1. نفّذ google_ads_query على search_term_view لآخر 60 يومًا: مصطلح البحث، والحملة، ومعرّف واسم المجموعة الإعلانية، والتكلفة، والتحويلات، وقيمة التحويل. احسب ROAS بقسمة قيمة التحويل على التكلفة. أبقِ المصطلحات التي حققت 3 تحويلات على الأقل وROAS يساوي [ROAS المستهدف] أو أعلى. استخدم الفئة already_negative في search_terms_report لاستبعاد كل ما تم حظره بالفعل.
2. اعرف إلى أين تقود هذه المصطلحات. نفّذ google_ads_query على ad_group_ad للمجموعات الإعلانية المعنية واقرأ عناوين URL النهائية لإعلاناتها النشطة. يقود مصطلح البحث إلى عنوان URL النهائي لإعلانات مجموعته الإعلانية، لذا إذا استخدمت المجموعة عدة عناوين URL فاعرضها كلها. أبقِ المصطلحات التي يكون عنوان URL الخاص بها عامًا: الصفحة الرئيسية [URL الصفحة الرئيسية] أو فئة واسعة مثل [عناوين URL للفئات الواسعة].
3. جمّع المصطلحات المتبقية في محاور واعرض أقوى 3 محاور. لكل محور اعرض:
   - مصطلحات البحث مع التكلفة والتحويلات وقيمة التحويل وROAS.
   - الوضع العضوي من gsc_performance (البُعد page,query، مع تصفية حسب الاستعلام الرئيسي للمحور): الصفحة المتصدرة ومتوسط ترتيبها.
   - الصفحات التي تغطي المحور بالفعل، وتجدها عبر wordpress_search_content باستخدام العبارات الرئيسية للمحور، حتى لا تتنافس الصفحة الجديدة معها.

توقف هنا ودعني أختار محورًا واحدًا.

بعد ذلك اكتب مسودة الصفحة:
- عنوان H1 يطابق نية البحث.
- مقدمة من 80 كلمة.
- من 4 إلى 6 منتجات متوفرة في المخزون من wordpress_woo_products، مع سبب شراء في سطر واحد لكل منتج. استخدم فقط الأسماء والأسعار الحقيقية من الأداة.
- قسم قصير للمقارنة أو "كيف تختار".
- أسئلة شائعة من 4 أسئلة.
- عنوان meta (بحد أقصى 60 حرفًا) ووصف meta (بحد أقصى 155 حرفًا).

نفّذ seo_content_lint على المسودة وصحّح ما يُشار إليه. ثم اعرض لي المسودة الكاملة وحقول meta والـ slug الذي تنوي استخدامه.

بعد موافقتي، أنشئ الصفحة باستخدام wordpress_create_post بحالة draft ونوع page، واضبط عنوان meta ووصفه باستخدام wordpress_set_seo على المعرّف الجديد. لا تنشر الصفحة ولا تغيّر أي إعلانات أو كلمات مفتاحية أو عناوين URL نهائية.

الموقع الإلكترونييجري تغييرات بعد موافقتك

اكتب أوصافًا لفئات المنتجات ذات المحتوى الضعيف التي تحصل على ظهور

يعثر على فئات المنتجات التي تحصل على ظهور مرتفع في Search Console وتكاد تخلو من الوصف، ويبحث عن كلمات مفتاحية ذات صلة، ويكتب أوصاف فئات معتمدة إضافة إلى عناوين meta وأوصافها لصفحات الأرشيف.

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

عبارة الثقة التي نستخدمها في الأوصاف: [سياسة الشحن والإرجاع]. إذا تركتُ هذا العنصر النائب فارغًا، فاسألني عنه قبل أن تكتب أي شيء.

1. اعرض كل فئات المنتجات في [الموقع] باستخدام wordpress_terms (action list، وtaxonomy product_cat). احسب بنفسك عدد الكلمات في كل وصف حالي.
2. تتبع عناوين URL للفئات النمط [نمط URL الفئة، مثال: https://site.com/urun-kategori/slug/]. نفّذ gsc_performance على [موقع الويب (الخاصية)] لآخر 90 يومًا بالبُعد page,query، وطابق الصفوف مع عنوان URL لكل فئة: النقرات، والظهور، ومتوسط الترتيب، وأهم 5 استعلامات حسب الظهور.
3. اختر 8 فئات هي الأعلى ظهورًا ويقل وصفها عن 50 كلمة.
4. بحث الكلمات المفتاحية: تحقق من seo_history أولًا حتى لا ندفع مرتين مقابل الكلمة الأساسية نفسها. نفّذ seo_keyword_research على الاستعلام الرئيسي لكل فئة (الموقع [الدولة]، اللغة [اللغة]) وأضف 3 مصطلحات ذات صلة بحجم بحث حقيقي. يتطلب seo_keyword_research الإضافة SEO Intelligence. إذا لم تكن متاحة، فاستخدم keyword_planner على حساب Google Ads الخاص بي [الحساب] مع اللغة والموقع الصحيحين، وأخبرني بالمصدر الذي استخدمته.

ثم اكتب لكل فئة:
- وصفًا من 120 إلى 180 كلمة. ابدأ بما يجده المتسوق في الفئة، ثم اشرح كيف يختار، واختم بعبارة الثقة أعلاه. استخدم الاستعلام الرئيسي مرة واحدة في الجملة الأولى واستخدم المصطلحات ذات الصلة بشكل طبيعي. دون تكرار الكلمات لحشو الكلمات المفتاحية ودون ادعاءات لا يمكننا إثباتها.
- عنوان meta لصفحة الأرشيف (بحد أقصى 60 حرفًا) ووصف meta (بحد أقصى 155 حرفًا).

نفّذ seo_content_lint على كل وصف وصحّح ما يُشار إليه.

سلّم جدولًا بهذه الأعمدة: الفئة، الظهور، الترتيب، الاستعلام الرئيسي، عدد الكلمات الحالي، عنوان meta المقترح. ضع النصوص الكاملة أسفل الجدول.

اعرض كل شيء كمعاينة أولًا: نفّذ wordpress_terms (action update، وterm_id، وdescription) مع confirm=false لأرى التغيير بدقة، واذكر قيم wordpress_set_seo (term_id، وtaxonomy product_cat، وtitle، وdescription) التي ستكتبها. في الموقع متعدد اللغات استخدم المصطلح بلغته الصحيحة. بعد موافقتي، طبّق الأوصاف باستخدام wordpress_terms مع confirm=true، واضبط حقول meta باستخدام wordpress_set_seo، ثم امسح ذاكرة التخزين المؤقت باستخدام wordpress_purge_cache.

الموقع الإلكترونيللقراءة فقط

رتّب صفحات الهبوط في Google Ads حسب مشكلات السرعة والإنفاق المهدور

يربط بيانات التكلفة والتحويلات لصفحات الهبوط في Google Ads بمؤشرات Core Web Vitals الفعلية على الجوال، ويقدّر الإنفاق الضائع على الصفحات البطيئة، ويرتّب الصفحات التي يجب إصلاحها أولًا. للقراءة فقط.

متى تستخدمهعندما تتراجع العملاء المحتملون القادمون من Google Ads وتشتبه في أن صفحات الهبوط البطيئة تهدر ميزانية إعلاناتك.

أدير نشاطًا لخدمات محلية، ومعظم العملاء المحتملين لديّ يأتون من Google Ads في الحساب [الحساب]. اكتشف أي صفحات هبوط تخسر عملاء محتملين بسبب بطء تحميلها. للقراءة فقط: لا تغيّر أي شيء في الحساب.

1. نفّذ google_ads_query على landing_page_view لآخر 30 يومًا (segments.date DURING LAST_30_DAYS): landing_page_view.unexpanded_final_url وclicks وcost وconversions وspeed_score وmobile_friendly_clicks_percentage. احسب معدل التحويل بقسمة التحويلات على النقرات لكل URL، ومتوسط الحساب بقسمة إجمالي التحويلات على إجمالي النقرات عبر جميع عناوين URL. إذا جاءت قيمة speed_score أو mobile_friendly_clicks_percentage فارغة، فسجّلها على أنها غير متاحة وتابع.
2. خذ أعلى 8 عناوين URL من حيث التكلفة ونفّذ core_web_vitals على كل منها، مع strategy mobile وresources=true. أبلغ عن LCP وINP وCLS من بيانات الميدان. إذا لم تتوفر لصفحة ما بيانات ميدانية لـ INP، فأبلغ عن TBT المخبري بدلًا منه، وسجّل INP على أنه "لا توجد بيانات ميدانية" ولا تحتسبه ضعيفًا. وضّح لكل مقياس ما إذا كان من بيانات الميدان أو من بيانات المختبر.
3. صنّف كل مقياس إلى جيد أو يحتاج إلى تحسين أو ضعيف. LCP جيد عند 2.5 ثانية أو أقل، وضعيف فوق 4 ثوانٍ. INP جيد عند 200 ملّي ثانية أو أقل، وضعيف فوق 500 ملّي ثانية. CLS جيد عند 0.1 أو أقل، وضعيف فوق 0.25.
4. حدّد عنق الزجاجة الرئيسي لكل صفحة من قوائم الموارد: عنصر LCP، أو الملفات التي تعطّل العرض، أو CSS أو JS غير المستخدم، أو الصور كبيرة الحجم.
5. قدّر الإنفاق الضائع للصفحات التي يقل معدل تحويلها عن متوسط الحساب: التكلفة × (1 − معدل تحويل الصفحة ÷ معدل تحويل الحساب). الصفحات التي تساوي المتوسط أو تتجاوزه تحصل على 0.
6. أنشئ جدولًا واحدًا بهذه الأعمدة: URL، التكلفة، التحويلات، معدل التحويل، speed score، LCP، INP، CLS، عدد المقاييس الضعيفة، الإنفاق الضائع المقدّر، عنق الزجاجة الرئيسي.
7. رتّب حسب الأولوية: الإنفاق الضائع المقدّر أولًا، ثم عدد المقاييس الضعيفة للفصل بين المتساويين. إذا كانت نقرات الصفحة قليلة (أقل من 50)، فاذكر أن معدل التحويل لم يصبح موثوقًا بعد.

أشِر إلى أي صفحة يزيد فيها LCP على الجوال عن 4 ثوانٍ ويقل معدل تحويلها عن متوسط الحساب. هذه الصفحات تُصلَح أولًا. اختم بأهم 3 إصلاحات ملموسة لكل صفحة مُشار إليها، بناءً على ما أبلغ عنه Lighthouse فعلًا.

الموقع الإلكترونييجري تغييرات بعد موافقتك

اضبط إعدادات التخزين المؤقت والسرعة في WordPress بأمان، مع اختبار قبل وبعد

خطة تغييرات آمنة وبموافقتك لإعدادات سرعة WordPress، مع قياس Core Web Vitals قبل التغيير وبعده.

متى تستخدمهعندما يكون موقعك على WordPress بطيئًا على الجوال وتريد تسريعه دون تعطيل النماذج أو أزرار الاتصال.

موقعي على WordPress [الموقع] بطيء على الجوال، ومن الجوال يأتي عملائي المحتملون عبر الهاتف. حسّن إعدادات السرعة فيه دون أن تعطّل الموقع.

1. اقرأ الإعداد الحالي باستخدام wordpress_performance. أريد أن أعرف أي إضافة تخزين مؤقت تعمل، وأي التحسينات مفعّلة، وأيها مُعلَّم على أنه محفوف بالمخاطر لهذا الموقع.
2. قس خط أساس باستخدام core_web_vitals على الجوال لهذه الصفحات: الصفحة الرئيسية، و[عنوان URL لصفحة الخدمة الرئيسية]، وصفحة التواصل. أبلغني بقيم LCP وINP وCLS.
3. اقترح ما يصل إلى 5 تغييرات في الإعدادات. لكل تغيير، اذكر التأثير المتوقع ومستوى المخاطرة. استبعد كل ما هو مُعلَّم على أنه محفوف بالمخاطر، مثل التأخير الحاد لـ JS الذي قد يعطّل أزرار الاتصال أو النماذج.
4. اعرض لي التغييرات الدقيقة كمعاينة وانتظر موافقتي. لا تطبّق أي شيء قبل أن أؤكد.
5. بعد موافقتي، طبّق التغييرات، وامسح ذاكرة التخزين المؤقت، وأعد تشغيل core_web_vitals على الصفحات نفسها.
6. زوّدني بجدول قبل وبعد.

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

الموقع الإلكترونييجري تغييرات بعد موافقتك

اكتشف علامات GA4 وGTM المكررة في موقع WordPress

جدول بكل علامات GA4/GTM في الموقع، يوضح مكان تثبيت كل منها وأيها يحتسب البيانات مرتين، مع إصلاحات تُعرض للموافقة.

متى تستخدمهعندما تبدو أرقام GA4 لديك مضخّمة وتشتبه في أن علامات Google Tag Manager أو GA4 تُحمَّل مرتين في موقع WordPress الخاص بك.

دقّق في كيفية إطلاق التتبع في موقع WordPress الخاص بي [URL الموقع]. اعثر على كل مكان يحمّل Google Tag Manager أو علامة GA4: الإضافات، ومقتطفات WPCode، وشيفرة الترويسة والتذييل، وملفات القالب النشط، ومخرجات موصل Opus نفسه. ثم نفّذ تدقيقًا لعلامات القياس على الصفحة الرئيسية وعلى [URL صفحة الهبوط الرئيسية].

سلّم جدولًا بهذه الأعمدة: معرّف العلامة، ومكان تثبيتها، والصفحات التي تُطلَق فيها، ومكررة (نعم/لا). ضع علامة "حرج" على:
- أي معرّف قياس GA4 أو حاوية GTM يُحمَّل أكثر من مرة في الصفحة نفسها،
- مقتطف gtag مكتوب مباشرة في ملف قالب إلى جانب GTM،
- أي معرّف قياس لا يطابق تدفق بيانات خاصية GA4 لديّ.

اختم بملخص من 3 أسطر يمكنني إرساله إلى الإدارة. يجب أن يوضح ما يُحتسب مرتين، والأثر المحتمل على الجلسات والتحويلات المبلّغ عنها، والإصلاح.

لا تغيّر أي شيء الآن. لكل إصلاح، اعرض لي التغيير بدقة، أي المقتطف الذي يجب إيقافه أو سطر القالب الذي يجب حذفه، وانتظر موافقتي. بعد أن أوافق على تغيير، امسح ذاكرة التخزين المؤقت ودقّق الصفحة مرة أخرى للتأكد من أن العلامة تُحمَّل الآن مرة واحدة.

الموقع الإلكترونييجري تغييرات بعد موافقتك

ثبّت علامة تحويل Google Ads عبر GTM مع معاينة وإمكانية التراجع

مساحة عمل GTM مُجهزة بعلامة تحويل Google Ads والمشغّل الصحيحين، تُنشر فقط بعد الموافقة ومعها نقطة تراجع واضحة.

متى تستخدمهعندما تحتاج إلى تتبع تحويل Google Ads عبر Google Tag Manager وتريد مراجعته ونشره بأمان.

أعدّ تتبع تحويلات Google Ads لإجراء التحويل [اسم إجراء التحويل] عبر حاوية GTM [GTM-XXXX]. يجب أن تعمل العلامة فقط على [مسار صفحة الشكر].

نفّذ هذه الخطوات بالترتيب:
1. اقرأ Conversion ID وتسمية الإجراء (قيمة send_to).
2. اعرض العلامات والمشغّلات والمتغيرات الموجودة حتى لا ننشئ نسخة مكررة. تحقق مما إذا كانت علامة Conversion Linker تعمل بالفعل على جميع الصفحات.
3. في مساحة عمل جديدة، جهّز ما يلي: علامة تحويل Google Ads واحدة بقيمة send_to الصحيحة، ومشغّل Page View واحد يطابق مسار صفحة الشكر تمامًا (وليس "يحتوي على" إذا كانت عناوين URL أخرى تشترك في هذه السلسلة)، وعلامة Conversion Linker إذا كانت مفقودة.

أرني حالة مساحة العمل مع كل التغييرات المعلقة وأي تعارضات، وانتظر موافقتي قبل النشر.

بعد أن أوافق وتنشر، أبلغني برقم النسخة الجديدة المباشرة والنسخة التي حلّت محلها، حتى نتمكن من التراجع في خطوة واحدة إذا بدت التحويلات خاطئة. اختم بملاحظة قصيرة للإدارة: ما الذي أُضيف، ومتى بدأ العمل، ومتى يُتوقع ظهور أولى التحويلات في Google Ads، وهو عادةً خلال 24 إلى 48 ساعة.

الموقع الإلكترونييجري تغييرات بعد موافقتك

اختبر نموذج الاتصال من البداية إلى النهاية وطابقه مع Ads وGA4

يتحقق من مستلمي كل نموذج Contact Form 7، ويرسل إدخالات اختبار معتمدة، ويفحص مشغّل النجاح في GTM والعلامات التي يشغّلها، ويطابق أحداث النماذج في GA4 خلال 14 يومًا مع تحويلات العملاء المحتملين في Google Ads.

متى تستخدمهعندما لا تكون متأكدًا من أن العملاء المحتملين القادمين من نماذج موقعك يُستلمون ويُحتسبون فعلًا، أو عندما يعرض GA4 وGoogle Ads أرقامًا مختلفة للعملاء المحتملين.

تحقق من أن العملاء المحتملين القادمين من موقع WordPress الخاص بي [URL الموقع] يُسجَّلون ويُتتبَّعون بشكل صحيح. الخطوات 1 و3 و4 للقراءة فقط.

1. اعرض نماذج Contact Form 7 وأظهر الحقول المطلوبة وعناوين البريد الإلكتروني للإشعارات لكل نموذج. نبّه إلى أي عنوان مستلم يبدو خاطئًا أو قديمًا. نطاقنا الحالي هو [نطاق الشركة].
2. ترسل عمليات الإرسال التجريبية رسالة إشعار حقيقية إلى مستلمي كل نموذج، وقد يصل الإدخال أيضًا إلى أي نظام CRM أو رد تلقائي مرتبط بالنموذج. قبل إرسال أي شيء، نفّذ كل اختبار كمعاينة (confirm=false). أرني، لكل نموذج، الحقول والقيم التي سيتم إرسالها والعناوين التي ستستلم الرسالة، ثم انتظر موافقتي. لكل نموذج أوافق عليه، أرسل إدخالًا واحدًا بحيث يكون الاسم والرسالة "TEST - please ignore" والبريد الإلكتروني [بريد إلكتروني تجريبي]. أبلغني بالنتيجة: mail_sent أو mail_failed أو validation_failed (مع الحقول المرفوضة) أو spam. لاحظ أن هذا الاختبار يمر عبر نقطة REST في خادم CF7، لذلك لا تعمل أي علامات في المتصفح. فهو يثبت أن البريد يعمل، وليس التتبع، ولا يضيف أي تحويلات إلى GA4 أو Google Ads.
3. تحقق مما يعمل فعليًا على الموقع. اعرض كل مصادر GTM وGA4 على الموقع ونبّه إذا كانت حاويتان مختلفتان تعملان في الوقت نفسه. في حاوية GTM [GTM-XXXX]، اعرض المشغّلات والعلامات وتحقق من وجود مشغّل يستمع إلى إرسال ناجح في CF7 (حدث مخصص مثل wpcf7mailsent أو ما يعادله)، وليس مجرد نقرة على زر الإرسال أو إرسال نموذج عام. أكّد أي علامة حدث GA4 وأي علامة تحويل Google Ads يشغّلها. طابق Conversion ID وتسمية علامة Ads هذه مع علامات التحويل في الحساب، لنعرف أنها تغذّي إجراء تحويل العملاء المحتملين الصحيح. افحص مساحة العمل بحثًا عن تغييرات غير منشورة، لأنها لا تعمل على الموقع المباشر.
4. للأيام الـ 14 الأخيرة، قارن عدد حدث النموذج في GA4 (تقرير GA4 موزعًا حسب الحدث) مع تحويلات Google Ads لإجراء تحويل العملاء المحتملين.

سلّمني قائمة تحقق بنتيجة نجاح/فشل لكل نموذج (المستلمون، تسليم البريد، مشغّل النجاح، العلامات المُشغَّلة، تطابق تسمية التحويل) وجدول مطابقة يعرض عدد GA4 وعدد Ads والفارق بنسبة %. إذا تجاوز الفارق 20%، اذكر الأسباب المحتملة بالترتيب: مشغّل مرتبط بالنقر بدلًا من النجاح، أو الموافقة على ملفات تعريف الارتباط أو مانعات الإعلانات، أو علامة مكررة أو حاوية ثانية، أو إجراء تحويل أو تسمية خاطئة.

هذا تشخيص فقط. اقترح الإصلاحات، لكن لا تعدّل النماذج أو تتبع الموقع أو GTM حتى أوافق على كل إصلاح. لكل إصلاح معتمد، أرني أولًا معاينة confirm=false وانتظر موافقتي. لا تنشر حاوية GTM أبدًا دون موافقتي الصريحة.

الموقع الإلكترونييجري تغييرات بعد موافقتك

فحص إعداد تحويلات B2B: أهداف Microsoft UET وتحويلات LinkedIn

تقرير حالة عن علامات UET وأهداف التحويل في Microsoft وقواعد التحويل في LinkedIn لكل حملة، مع اقتراح العناصر المفقودة للموافقة عليها.

متى تستخدمهعندما تدير حملات B2B لطلبات العرض التوضيحي على Microsoft Ads وLinkedIn ولا تستطيع معرفة ما إذا كانت التحويلات تُتتبَّع، فتكون تكلفة العرض التوضيحي غير واضحة.

تحقق من أن طلب العرض التوضيحي لدينا على [URL صفحة الشكر] يُتتبَّع كتحويل في Microsoft Advertising وLinkedIn، حتى ترى الإدارة تكلفة العرض التوضيحي الواحد في كل قناة.

Microsoft:
- اعرض علامات UET وحالتها.
- اعرض أهداف التحويل مع النوع وقاعدة URL وطريقة العد والعلامة التي يستخدمها كل هدف.
- للأيام الـ 30 الأخيرة، اعرض الإنفاق والتحويلات لكل حملة.
- نبّه إلى أي حملة أنفقت أكثر من [حد الإنفاق] دون أي تحويل، وإلى أي استراتيجية عروض أسعار قائمة على التحويلات تعمل دون هدف فعّال.

LinkedIn:
- اعرض جميع قواعد التحويل.
- اعرض الحملات النشطة والتحويلات المرتبطة بكل منها.
- للأيام الـ 30 الأخيرة، اعرض الإنفاق والتحويلات لكل حملة.
- نبّه إلى أي حملة نشطة بلا تحويل مرتبط.

سلّمني جدولين، واحدًا لكل منصة، وملخصًا قصيرًا يوضح ما إذا كان يمكن الإبلاغ عن تكلفة العرض التوضيحي بشكل موثوق على كل منصة.

إذا كان هدف URL الخاص بالعرض التوضيحي مفقودًا في Microsoft، أو كانت حملات LinkedIn تفتقر إلى تحويل العرض التوضيحي، فجهّز الهدف أو الربط المطلوب بدقة وأرني إياه أولًا. انتظر موافقتي قبل إنشاء أو ربط أي شيء.

الموقع الإلكترونييجري تغييرات بعد موافقتك

تحقق من وسم Google في موقعنا المستضاف وانقله إلى وضع first-party

قائمة تحقق نجاح/فشل لتحميل الوسم وحظر CSP ومعرّف القياس في الموقع المستضاف، مع إعداد Google tag gateway مقترح للموافقة عليه.

متى تستخدمهعندما لا تكون متأكدًا من أن تتبع Google يعمل على الموقع المستضاف في Opus Growth، أو تشك في أن مانعات الإعلانات وترويسات الأمان تتسبب في فقدان بياناتك.

موقعنا [النطاق] يعمل على استضافة Opus Growth. أريد التأكد من أن تتبع Google يعمل عليه وتقليل فقدان البيانات الناتج عن مانعات الإعلانات.

1. اقرأ الصفحة الرئيسية الفعلية و[URL صفحة التواصل] تمامًا كما يفعل المتصفح. أخبرني أي حاوية GTM أو معرّف قياس GA4 يتم تحميله، وهل يتم تحميله مرة واحدة أم أكثر من مرة.
2. قارن هذا المعرّف بتدفق البيانات في خاصية GA4 الخاصة بي وأشر إلى أي عدم تطابق.
3. افحص ترويسات الاستجابة بحثًا عن Content-Security-Policy قد تحظر googletagmanager.com أو google-analytics.com أو نطاقات Google Ads.
4. اقرأ تقارير مخالفات CSP المجمّعة واذكر أي مخالفات تحظر نطاقات الوسوم.

قدّم قائمة تحقق نجاح/فشل تتضمن هذه البنود: الوسم موجود، المعرّف صحيح، تحميل واحد فقط، CSP يسمح بالوسوم، لا توجد تقارير مخالفات. أضف سطرًا واحدًا يوضح ماذا يعني كل فشل بالنسبة لحركة الزيارات المسجّلة لدينا.

ثم اقترح تقديم وسم Google من نطاقنا الخاص عبر Google tag gateway (وضع first-party). اعرض الإعداد بدقة وأي تغييرات مطلوبة في الترويسات، وانتظر موافقتي. بعد أن أوافق، أعد قراءة الصفحة الفعلية وتحقق من المستخدمين النشطين في الوقت الفعلي في GA4 للتأكد من أن البيانات ما زالت تصل.

الموقع الإلكترونييجري تغييرات بعد موافقتك

أنشئ مسودة صفحة هبوط مخصصة تتوافق مع أفضل إعلان لك على Meta

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

متى تستخدمهعندما توجّه إعلانات Meta الزيارات إلى الصفحة الرئيسية وتريد صفحة هبوط مركّزة تتوافق مع أفضل إعلان لك أداءً.

حملتي على Meta [اسم الحملة] توجّه الزيارات إلى الصفحة الرئيسية. أريد صفحة هبوط مخصصة بدلًا من ذلك.

اسحب بيانات آخر 30 يومًا على مستوى الإعلان: الإنفاق، النقرات على الرابط، CTR، النتائج وتكلفة النتيجة. اقرأ المحتوى الإبداعي لأفضل إعلانين من حيث النتائج: النص الأساسي والعنوان والزر.

ثم اكتب صفحة هبوط بهذا الهيكل:
- عنوان H1 يكرر وعد عنوان أفضل إعلان.
- 3 كتل قصيرة للمزايا.
- قسم للإثبات الاجتماعي، مع عناصر نائبة سأملؤها بنفسي. لا تختلق تقييمات.
- قسم أسئلة شائعة من 4 أسئلة يجيب عن الاعتراضات المحتملة.
- زر CTA واحد، يظهر مرتين، يشير إلى [رابط النموذج أو WhatsApp].

اجعل الصفحة أقل من 400 كلمة، بلغة بسيطة ودون مبالغة. اقترح أيضًا عنوان meta (60 حرفًا كحد أقصى) ووصف meta (155 حرفًا كحد أقصى).

اعرض عليّ النص الكامل أولًا. بعد موافقتي، أنشئ الصفحة كمسودة فقط، واضبط حقول SEO وأعطني رابط المعاينة. لا تنشر الصفحة ولا تغيّر عنوان URL الوجهة لأي إعلان.

الموقع الإلكترونيللقراءة فقط

فحص شهري لـ Core Web Vitals لجميع مواقع العملاء

جدول بألوان إشارة المرور، بصف واحد لكل عميل، لمؤشرات Core Web Vitals للصفحة الرئيسية والصفحات المهمة، إضافة إلى قائمة العملاء الذين يحتاجون إلى إجراء هذا الشهر.

متى تستخدمهعندما تدير عدة مواقع لعملاء وتحتاج إلى رؤية شهرية توضح أيها بطيء أو يزداد سوءًا في Core Web Vitals.

اعرض جميع مواقع العملاء المتصلة بهذا الحساب، سواء مواقع WordPress أو خوادم الاستضافة.

لكل موقع، أجرِ فحص Core Web Vitals على الجوال للصفحات التالية:
- الصفحة الرئيسية
- صفحة التحويل الرئيسية من هذه القائمة: [العميل: قائمة روابط الصفحات المهمة]. إذا كان أحد العملاء غير موجود في القائمة، فافحص الصفحة الرئيسية فقط ودوّن أنه تم تخطيه.

قدّم جدولًا واحدًا بالأعمدة التالية: العميل، الصفحة، LCP، INP، CLS، نوع البيانات (ميدانية أو مخبرية)، الحالة.

حدّد الحالة وفق هذه القواعد:
- أخضر: جميع المقاييس جيدة (LCP بحدود 2.5 ثانية أو أقل، INP بحدود 200 مللي ثانية أو أقل، CLS بحدود 0.1 أو أقل)
- أحمر: أي مقياس ضعيف (LCP أعلى من 4 ثوانٍ، INP أعلى من 500 مللي ثانية، CLS أعلى من 0.25)
- برتقالي: أي حالة أخرى

إذا لصقت جدول الشهر الماضي، فأضف عمودًا للتغيّر. وضع علامة على أي مقياس ازداد سوءًا بأكثر من 20%.

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

هذا الطلب للقراءة فقط.

الموقع الإلكترونييجري تغييرات بعد موافقتك

اسحب الطلبات المستردة والملغاة من تحويلات Google Ads

يتأكد من أن وسم الشراء يرسل معرّف الطلب، ويجمع طلبات WooCommerce المستردة والملغاة خلال آخر 45 يومًا، ويُعدّ دفعة سحب وتعديل مع أثرها على ROAS، ولا يرفعها إلا بعد الموافقة.

متى تستخدمهعندما يبدو ROAS في Google Ads أفضل من الواقع لأن الطلبات المستردة والملغاة في WooCommerce ما زالت تُحتسب كتحويلات.

تؤدي المبالغ المستردة والإلغاءات إلى تضخيم ROAS المعروض في [حساب Google Ads]. نظّف بيانات التحويل منها.

1. حدّد إجراء تحويل الشراء الأساسي وتأكد من إعداداته (طريقة العدّ، فترة الرجوع، القيمة).
2. اعرض الوسوم في حاوية GTM [GTM-XXXX] مع معاملاتها. تحقق من أن وسم تحويل الشراء في Google Ads يرسل معرّف طلب WooCommerce كمعرّف للمعاملة (المعامل orderId). تتم مطابقة التعديلات بهذا المعرّف فقط. إذا كان مفقودًا أو فارغًا، فتوقف واشرح الحل بدلًا من المتابعة.
3. تصفّح طلبات WooCommerce على [موقع WordPress] حتى تتجاوز 45 يومًا للخلف، واجمع كل طلب حالته مستردّ أو ملغى، مع تاريخه وإجماليه. لا تعرض قائمة الطلبات مبالغ الاسترداد الجزئي، لأن الطلب المسترد جزئيًا يحتفظ عادةً بحالة مكتمل. لذلك اطلب مني لصق حالات الاسترداد الجزئي (معرّف الطلب وقيمة الطلب المتبقية) من WooCommerce، أو تجاوزها إذا لم تكن لدي أي حالة.
4. أنشئ دفعة تعديلات بالاعتماد على معرّف الطلب. تتحول عمليات الاسترداد الكامل والإلغاء إلى RETRACT. وتتحول عمليات الاسترداد الجزئي إلى RESTATE بقيمة الطلب المتبقية. لاحظ أن الطلبات الملغاة التي لم يكتمل دفعها قط، والطلبات التي لم تأتِ من نقرة على Google Ads، لم تُسجَّل غالبًا كتحويلات وسيتم رفضها. وهذا متوقع.
5. اسحب تكلفة الحملة وقيمة التحويل لآخر 45 يومًا لحساب ROAS قبل التعديل وبعده.

قدّم جدول معاينة بهذه الأعمدة: معرّف الطلب، تاريخ الطلب، القيمة الأصلية، نوع التعديل، القيمة الجديدة. أضف إجمالًا يوضح الحد الأقصى لانخفاض قيمة التحويل المعروضة وتقدير ROAS قبل التعديل وبعده.

لا ترفع أي شيء حتى أوافق على الدفعة. نفّذ الرفع أولًا كمعاينة (confirm=false)، ثم طبّقه بعد موافقتي وأخبرني بعدد التعديلات المقبولة وعدد المرفوضة، مع الأسباب التي يعيدها الرفع.

الموقع الإلكترونييجري تغييرات بعد موافقتك

تحقّق من أن Google Ads يحتسب عملاء نموذج الاتصال المحتملين بشكل صحيح

حكم حول ما إذا كان إجراء تحويل النموذج يعمل، ويُعد أساسيًا، ويُحتسب مرة واحدة لكل عميل محتمل، مع قائمة إصلاحات معروضة كمعاينة.

متى تستخدمهعندما لا يحقق Smart Bidding أداءً جيدًا وتشك في أن تحويل النموذج في Google Ads مُعدّ بشكل خاطئ أو يُحتسب مرتين أو لا يطابق العملاء المحتملين الذين تحصل عليهم فعليًا.

يجب أن يحسّن Smart Bidding في حساب Google Ads [الحساب] لصالح عملاء نموذج الاتصال المحتملين الحقيقيين. تحقّق مما إذا كان تحويل النموذج مُعدًّا بشكل صحيح، باستخدام آخر 30 يومًا.

1. اعرض إجراءات التحويل وحدّد الإجراء (أو الإجراءات) الخاص بإرسال النماذج. نبّه إلى أي إجراء متوقف أو محذوف أو لم يسجّل أي تحويلات.
2. بالنسبة لإجراء النموذج، اعرض الفئة ونوع الاحتساب ونافذة النظر إلى الوراء للنقرات ونموذج الإسناد وهل هو أساسي. في نشاط خدمات محلية، يجب أن يحتسب "واحدًا" لكل نقرة وأن يكون أساسيًا؛ ولا يجوز أن تكون مشاهدات الصفحة أو التمريرات أو النقرات على الأزرار أساسية.
3. احصل على معرّف التحويل وتسميته وتأكد من وجود وسم في GTM بالقيم نفسها وأنه يُطلق عند مشغّل النجاح، لا عند تحميل الصفحة ولا عند النقر على الزر.
4. قارن تحويلات النموذج في Google Ads بعدد عملاء النموذج المحتملين الذين تلقيتهم فعليًا: [العدد الفعلي للعملاء المحتملين]. فجوة تزيد على 20% تعني وجود خلل.

المخرجات: جدول نجاح/فشل لكل فحص وقائمة إصلاحات مرتّبة حسب الأولوية. اعرض كل تغيير كمعاينة وانتظر موافقتي قبل تطبيق أي شيء.

الموقع الإلكترونييجري تغييرات بعد موافقتك

أضف نموذج عملاء محتملين في Google Ads ليتمكن مستخدمو الجوال من التواصل دون زيارة الموقع

نموذج عملاء محتملين داخل الإعلان مع أسئلة تأهيل، مبرَّر ببيانات سرعة صفحة التواصل ويُرفق فقط بعد الموافقة.

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

كثير من الباحثين لدينا يستخدمون الجوال ويغادرون قبل الوصول إلى نموذج التواصل. ساعدني في تحديد ما إذا كان عليّ إضافة نموذج عملاء محتملين في Google Ads إلى الحملة [الحملة].

1. افحص Core Web Vitals للصفحة [URL صفحة التواصل] على الجوال. إذا كان LCP أعلى من 2.5 ثانية أو فشلت الصفحة في الفحص، فسجّل ذلك كسبب لتقديم نموذج داخل الإعلان.
2. اعرض النقرات والتحويلات ومعدل التحويل للحملة على الجوال مقابل الكمبيوتر خلال آخر 30 يومًا.
3. تحقق مما إذا كان هناك أصل نموذج عملاء محتملين موجود بالفعل في الحساب.
4. أعدّ مسودة نموذج العملاء المحتملين: عنوان ووصف بأسلوبنا، وحقول مقتصرة على الاسم والهاتف والرمز البريدي، وسؤالا تأهيل: أي خدمة ([الخدمات]) ومتى يحتاجها العميل. أضف رسالة نجاح قصيرة تخبره بأننا سنتصل به خلال ساعات العمل.
5. اعرض عليّ المسودة الكاملة والحملة التي سيُرفق بها. لا تنشئه إلا بعد موافقتي.

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

الموقع الإلكترونييجري تغييرات بعد موافقتك

أنشئ صفحات مواقع تتوافق مع قوائم Google Business Profile لديك

صفحة جاهزة لـ SEO لكل فرع من فروع نشاطك التجاري على موقعك المستضاف، مع الاسم والعنوان والهاتف وساعات العمل منسوخة حرفيًا من Business Profile ومخطط LocalBusiness.

متى تستخدمهعندما لا يتطابق عنوان موقعك أو هاتفه أو ساعات عمله مع Google Business Profile، أو عندما يكون لديك عدة فروع دون صفحات خاصة بها.

أنشئ صفحة فرع على موقعي المستضاف لكل موقع من مواقعنا في Google Business Profile، بحيث يقول الموقع وقوائم Maps الشيء نفسه تمامًا.

1. اعرض جميع مواقع Business Profile واقرأ اسم كل موقع وعنوانه وهاتفه وساعات عمله وفئاته وخدماته ورابط Maps الخاص به.
2. اقرأ دليل SEO ودليل التصميم الخاصين بالموقع. استخدم /locations/[city-slug] كنمط للـ URL.
3. لكل موقع، اكتب مسودة تتضمن: H1 يجمع العلامة التجارية واسم الحي، ومقدمة من 100 إلى 150 كلمة فريدة لذلك الموقع (دون نص منسوخ بين الصفحات)، وقائمة الخدمات، وساعات العمل، ورابط اتصال هاتفي بنقرة واحدة، ورابط اتجاهات إلى Maps، وJSON-LD من نوع LocalBusiness مرتبطًا بـ @id الخاص بـ Organization في الموقع. يجب أن يطابق الاسم والعنوان والهاتف القائمة حرفًا بحرف.
4. أضف صفحة فهرس /locations تربط بجميع هذه الصفحات.

اعرض علي صفحة موقع واحدة كاملة مع جدول ملخص لبقية الصفحات (URL والعنوان والوصف ومصدر NAP) وانتظر موافقتي. بعد أن أوافق، اكتب الصفحات وأرسل لقطات شاشة للجوال لصفحتين منها.

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

الموقع الإلكترونييجري تغييرات بعد موافقتك

أعد كتابة القسم العلوي من صفحتي المقصودة المستضافة للزوار القادمين من الإعلانات

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

متى تستخدمهعندما ينقر الناس على إعلانك في Google لكنهم يغادرون صفحتك المقصودة دون تحويل، وتشك في أن الشاشة الأولى غير مقنعة.

صفحتي المقصودة [مسار الصفحة، مثال: /teklif] مستضافة على خادم Opus Growth الخاص بي، وحملتي في Google Ads [اسم الحملة] توجّه الزيارات إليها.

1. التقط لقطة شاشة للصفحة واقرأ ملفها المصدري.
2. اسحب مصطلحات البحث التي حققت تحويلات خلال آخر 30 يومًا وعناوين RSA الخاصة بالحملة. هذا يوضح ما بحث عنه الزوار فعلًا وما وعدت به إعلاناتي.
3. انقد فقط الشاشة الأولى التي يراها زائر الجوال. افحص العنوان والعنوان الفرعي وزر الحث على اتخاذ إجراء (call-to-action) وإشارات الثقة (التقييمات وسنوات الخبرة والضمانات) وأي شيء يشتت الانتباه عن الإجراء الوحيد الذي أريده.

ثم اكتب عنوانًا جديدًا (10 كلمات كحد أقصى) وعنوانًا فرعيًا (20 كلمة كحد أقصى) ونص الزر (4 كلمات كحد أقصى). ابنها على أهم مصطلحات البحث وحافظ على نبرة علامتي التجارية. اعرض تغييرات النص بدقة في الملف على شكل diff قبل وبعد. انتظر موافقتي قبل تعديل أي شيء، ثم أكّد بلقطة شاشة جديدة بعد ذلك.

الموقع الإلكترونييجري تغييرات بعد موافقتك

دقّق في إضافات WordPress وإصدار PHP بحثًا عن أسباب البطء

قائمة إضافة بإضافة تحدد الإبقاء أو التحديث أو التعطيل، مع خطة اختبار دقيقة تُنفَّذ إضافة واحدة في كل مرة.

متى تستخدمهعندما يبدو موقعك على WordPress بطيئًا وقد تراكمت عليه الإضافات على مر السنين دون أن تعرف أيها يمكن إزالته بأمان.

موقعي على WordPress [الموقع] تراكمت عليه إضافات كثيرة على مر السنين. أعتقد أن بعضها يبطئه.

1. اقرأ النظرة العامة على الموقع للحصول على إصدار WordPress وإصدار PHP والقالب وعدد الإضافات. أشِر إلى أن إصدار PHP الأقل من 8.1 مشكلة في السرعة والأمان يجب أن تعالجها شركة الاستضافة.
2. اعرض جميع الإضافات مع حالتها والتحديثات المتاحة. صنّفها ضمن هذه الفئات: ضرورية للعملاء المحتملين (النماذج وتتبع المكالمات وSEO)، ووظيفة مكررة (مثل إضافتي تخزين مؤقت أو إضافتي SEO)، وغير نشطة، وقديمة، ومن المرجح أنها ثقيلة على الواجهة الأمامية (السلايدرات والإضافات الإضافية لمنشئي الصفحات وأدوات الدردشة وخلاصات وسائل التواصل الاجتماعي).
3. تحقق من wordpress_performance حتى لا توصي بإزالة إضافة التخزين المؤقت النشطة.
4. شغّل core_web_vitals على الصفحة الرئيسية وعلى [عنوان URL لصفحة الخدمة الرئيسية] للجوال كخط أساس.
5. أعطني جدولًا بهذه الأعمدة: الإضافة، الفئة، الحالة، التحديث المتاح، والتوصية (إبقاء أو تحديث أو تعطيل أو حذف)، مع سبب في سطر واحد لكل إضافة.

لا تلمس أبدًا إضافات النماذج أو تتبع المكالمات أو الأمان. بالنسبة للتعطيل، اقترح ترتيبًا بإضافة واحدة في كل مرة. اعرض كل إجراء كمعاينة وانتظر موافقتي. بعد كل تغيير تمت الموافقة عليه، امسح ذاكرة التخزين المؤقت وأعد الاختبار قبل الانتقال إلى التالي.

الموقع الإلكترونييجري تغييرات بعد موافقتك

دقّق في تتبع مشتريات WooCommerce في GA4 وGoogle Ads وGTM

يقارن طلبات WooCommerce اليومية بمشتريات GA4 وتحويلات Google Ads على مدى 14 يومًا، ويرسم خريطة لكل مصادر الوسوم، ويحدد تتبع المشتريات المكرر أو المفقود قبل اقتراح إصلاحات مع معاينة.

متى تستخدمهعندما لا تتطابق طلبات WooCommerce ومشتريات GA4 وتحويلات Google Ads وتشك في وجود تتبع مشتريات مكرر أو مفقود.

تحقق مما إذا كان [موقع WordPress] يبلغ عن المشتريات بشكل صحيح إلى GA4 وإلى [حساب Google Ads].

1. مقارنة يومية لآخر 14 يومًا كاملة:
   - WooCommerce: تصفّح صفحات wordpress_woo_orders إلى أن تتجاوز الطلبات الأقدم من 14 يومًا. احسب فقط الطلبات المكتملة (completed) وقيد المعالجة (processing) لكل يوم. أخبرني إذا انتهت الطلبات قبل اليوم الـ14، وعامل أي طلب يبدو تجريبيًا (باسمي الشخصي، أو إجماليه 0) بشكل منفصل.
   - GA4: شغّل ga4_report مع البعد "date" وdimension2 بقيمة "event"، وخذ فقط عدد حدث purchase. لا تستخدم إجمالي التحويلات لأنه يجمع كل الأحداث الرئيسية.
   - Google Ads: شغّل google_ads_query على إجراء تحويل الشراء، مقسّمًا حسب segments.date وsegments.conversion_action_name حتى لا تضخّم الإجراءات الأخرى الرقم. لاحظ أن Google Ads يبلّغ عن التحويلات بتاريخ النقرة، لذا قد تستمر الأيام الأخيرة في الاكتمال.
   - دوّن المناطق الزمنية للمتجر ولموقع GA4 ولحساب Ads إذا اختلفت، لأن ذلك ينقل الطلبات بين الأيام.
2. الإعدادات:
   - تأكد باستخدام ga4_list_conversions أن purchase حدث رئيسي.
   - باستخدام list_conversion_actions وget_conversion_settings، تأكد أن إجراء الشراء في Ads مفعّل ومضمّن في التحويلات (أساسي) وله بيانات مسجّلة، وتحقق من نوع العد. يُعد MANY_PER_CLICK على إجراء شراء مصدرًا شائعًا للعد الزائد.
3. جرد الوسوم:
   - استخدم wordpress_tracking لمعرفة كل مكان يُشغَّل فيه وسم GA4 أو GTM (الإضافات، مقتطفات WPCode، كود الرأس/التذييل، خيارات القالب). اقرأ أي مقتطف مشبوه باستخدام wordpress_snippet وأي خيار قالب يشير إليه باستخدام wordpress_option.
   - استخدم wordpress_list_plugins للعثور على الإضافات التي ترسل بيانات الشراء من تلقاء نفسها (مثل GTM4WP وWooCommerce Google Analytics وSite Kit وPixelYourSite).
   - في GTM، اعرض الوسوم والمشغّلات في مساحة عمل الحاوية المنشورة، وأشر إلى كل وسم يرسل purchase إلى GA4 أو تحويلًا في Google Ads، مع معرّف/تسمية التحويل وشروط المشغّل. استخدم gtm_workspace_status لمعرفة ما إذا كان هناك أي تغيير متعلق بالشراء غير منشور.
   - لا يمكن قراءة وضع الموافقة (consent mode) كإعداد واحد. أبلغني بما يظهره جرد الوسوم (إضافة موافقة، أو إعدادات موافقة في وسوم GTM، أو مقتطف موافقة)، وقل بوضوح إن لم تستطع التحديد.

المطلوب تسليمه:
- جدول يومي بهذه الأعمدة: التاريخ، الطلبات، مشتريات GA4، تحويلات Google Ads، فجوة GA4 % مقابل الطلبات، فجوة Ads % مقابل الطلبات.
- قائمة مرقّمة بالنتائج، وكل نتيجة مرتبطة بالدليل الذي يدعمها.

استخدم هذه الحدود كمؤشرات فقط، ثم أكد السبب من الجرد:
- أكثر من 10% فوق الطلبات: ابحث عن مصدرين يرسلان الشراء نفسه (إضافة مع وسم GTM، أو حاويتين)، أو transaction_id مفقود، أو عدّ MANY_PER_CLICK، أو مشغّل صفحة الشكر الذي يعمل عند إعادة التحميل.
- أكثر من 25% تحت الطلبات: ابحث عن وسم مفقود أو غير منشور، أو شرط مشغّل لا يلتقط URL صفحة الشكر، أو حجب بسبب الموافقة، أو بوابة دفع لا تعيد المستخدم إلى صفحة الشكر. إذا لم تُظهر بيانات الطلب طريقة الدفع، اسألني عن البوابات التي نستخدمها.

اقترح إصلاحات تحدد الوسم أو المشغّل أو المقتطف أو الإضافة المراد تغييرها بدقة. لا تُجرِ أي تغيير حتى أوافق على معاينة كل تغيير.

الموقع الإلكترونيللقراءة فقط

هل يمكن للإدارة الوثوق بأرقام التحويلات لدينا؟ تدقيق Google Ads وGA4

تدقيق للقراءة فقط لكل إجراء تحويل في Google Ads ولكل حدث رئيسي في GA4. يحدد المشكلات حسب درجة الخطورة، ويقدّر مدى انحراف التحويلات وCPA المبلغ عنها، وينتهي بخلاصة بلغة بسيطة موجّهة للإدارة.

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

أحتاج إلى إبلاغ الإدارة ما إذا كانت بيانات التحويل في [حساب Google Ads] موثوقة. راجع آخر 30 يومًا. هذا للقراءة فقط، لذا لا تغيّر أي شيء.

1. أنشئ جدولًا واحدًا يغطي كل إجراءات التحويل بهذه الأعمدة: الاسم، المصدر (وسم الموقع، استيراد GA4، مكالمة، رفع بيانات، إلخ، بحسب نوع الإجراء)، الفئة، الحالة، أساسي أو ثانوي، العدّ (كل تحويل أو تحويل واحد)، نافذة الاسترجاع بعد النقر، نموذج الإسناد، والتحويلات في آخر 30 يومًا. لتحديد أساسي أو ثانوي، استخدم مؤشر "مُدرج في التحويلات" وليس المؤشر القديم primary_for_goal. اعرض أيضًا فئات التحويل القابلة لبناء عروض الأسعار عليها على مستوى الهدف.
2. أضف عمود "تاريخ آخر تحويل". نفّذ استعلام GAQL للقراءة فقط على الحساب لآخر 90 يومًا، مقسّمًا حسب إجراء التحويل والتاريخ، مع اعتبار كل التحويلات هي المقياس. لكل إجراء، خذ أحدث تاريخ بقيمة غير صفرية. إذا لم يكن لإجراء ما أي شيء خلال 90 يومًا، فاكتب "لا شيء خلال 90 يومًا".
3. بجانب الجدول، اعرض الأحداث الرئيسية في GA4 مع طريقة العدّ الخاصة بها. أضف عدد كل حدث خلال 30 يومًا من تقرير GA4 مفصّل حسب الحدث.
4. اسحب إنفاق الحملات خلال 30 يومًا لتعرف أي الحملات كانت تنفق بينما كان كل إجراء صامتًا.

ضع علامة على كل مشكلة بمستوى خطورة:
- حرج: إجراء أساسي بصفر تحويلات خلال 30 يومًا بينما أنفقت الحملات أموالًا. النموذج نفسه أو عملية الشراء نفسها محسوبة بإجراءين أساسيين (مثلًا وسم Google Ads مع استيراد من GA4).
- تحذير: إجراءات العملاء المحتملين المحسوبة بطريقة "كل تحويل". إجراء أساسي موقوف مؤقتًا أو محذوف. نوافذ استرجاع مختلفة بين إجراءات متشابهة.
- معلومة: إجراءات ثانوية بلا تحويلات خلال 90 يومًا.

لتقدير المبالغة أو التقليل، قارن التحويلات الأساسية في Ads بأعداد الأحداث الرئيسية المقابلة في GA4 للفترة نفسها (30 يومًا). وحيث يتتبع إجراءان أساسيان النموذج نفسه أو عملية الشراء نفسها، اعرض كيف سيكون إجمالي التحويلات وCPA لو احتُسب أحدهما فقط. اعرض النتيجة كنطاق وليس كرقم واحد دقيق، واذكر افتراضاتك. الإسناد ونوافذ الاسترجاع والموافقة على الخصوصية تجعل Ads وGA4 لا يتطابقان تمامًا أبدًا، ولا يمكن قياس العدّ المزدوج مباشرة.

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

اعرض الإصلاحات المقترحة بشكل منفصل واذكر الأداة التي ستطبّق كل إصلاح. نبّه إلى أي إصلاح لا يمكن تنفيذه إلا من واجهة Google Ads، مثل إيقاف إجراء تحويل مؤقتًا أو حذفه. سأوافق على الإصلاحات واحدًا تلو الآخر. لكل إصلاح تتم الموافقة عليه، اعرض أولًا المعاينة بقيمة confirm=false وانتظر موافقتي قبل تطبيق أي شيء.

الموقع الإلكترونيللقراءة فقط

حدّد أحداث GA4 الصحيحة كأحداث رئيسية واربط GA4 بـGoogle Ads

قائمة مختصرة بأحداث الأعمال التي ينبغي أن تُحتسب كأحداث رئيسية، وفحص للربط بين GA4 وAds، وتغييرات مقترحة للموافقة عليها.

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

راجع موقع GA4 [اسم موقع GA4] الخاص بالموقع [URL الموقع].

1. اسحب إجمالي الأحداث حسب اسم الحدث لآخر 28 يومًا، واعرض الأحداث الرئيسية المحددة حاليًا.
2. حدّد الأحداث التي تمثل نتائج أعمال حقيقية لكنها ليست أحداثًا رئيسية. من الأمثلة المعتادة generate_lead وform_submit وpurchase وأحداث النقر على الهاتف أو WhatsApp وتأكيدات الحجز. تجاهل ضجيج التفاعل مثل scroll وpage_view وuser_engagement.
3. أشر إلى الأحداث الرئيسية التي لا ينبغي أن تكون كذلك، مثل حدث نقر عام قد يضخّم عدد التحويلات.
4. تحقق مما إذا كان هذا الموقع مرتبطًا بحساب Google Ads [حساب Google Ads].

سلّم جدولًا بهذه الأعمدة: اسم الحدث، العدد خلال 28 يومًا، حدث رئيسي حاليًا (نعم/لا)، التوصية (إضافة أو إزالة أو إبقاء)، وسبب في سطر واحد. أضف ملاحظة قصيرة للإدارة توضح النتائج التي سنتمكن من الإبلاغ عنها بعد هذه التغييرات.

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

الموقع الإلكترونييجري تغييرات بعد موافقتك

تتبّع عمليات إرسال النماذج الناجحة كحدث رئيسي في GA4 عبر GTM

مشغّل في GTM وعلامة حدث في GA4 مع معاينة، تعمل فقط عند الإرسال الناجح، ويتم نشرها ووسمها كحدث رئيسي بعد موافقتك.

متى تستخدمهعندما يتم احتساب عملاء محتملين من نموذج الاتصال بأكثر من عددهم الحقيقي لأن GA4 يسجّل كل نقرة على الزر بدلًا من الإرسال الناجح فعليًا.

الموقع الإلكترونيللقراءة فقط

اعثر على العناوين والأقسام التي يكررها قالب الصفحة في المكان الخطأ

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

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

أجرِ تدقيقًا على [URL الموقع] بحثًا عن النصوص القادمة من قالب صفحة مشترك والخاطئة في بعض الصفحات التي تستخدمه. من الحالات الشائعة جدول مقارنة بعنوان منتج واحد يظهر في كل صفحات المنتجات، أو عنوان قسم يذكر المنصة الخطأ، أو نص إنجليزي متروك في صفحات مترجمة.

1. ابدأ زحفًا على الموقع باستخدام seo_site_crawl للنطاق [النطاق] واجمع العناوين المكررة والأوصاف المكررة والصفحات التي لا تحتوي على H1. جمّع عناوين URL المتأثرة حسب القالب، أي نمط المسار المشترك مثل /product/ أو /blog/ أو /solutions/، وحسب بادئة اللغة.
2. اختر حتى [عدد الصفحات، مثال: 5] صفحات من كل قالب ومن كل لغة، واقرأ هيكلها باستخدام site_read_url مع outline=true: العنوان، والوصف التعريفي، وcanonical، وشجرة العناوين الكاملة.
3. قارن عناوين H2 وH3 بين صفحات القالب نفسه. أي عنوان متطابق في كل الصفحات لكنه يذكر منتجًا أو منصة أو مدينة أو منافسًا بعينه فهو مشبوه. تحقق منه بمقارنته بموضوع الصفحة نفسها المستخلص من H1 وURL، وصنّفه خاطئًا عند اختلافهما.
4. افحص كل نسخة بلغة غير الإنجليزية بحثًا عن عناوين أو أوصاف ما زالت مكتوبة بالإنجليزية، وافحص كل صفحة بحثًا عن عناوين تكرر H1 حرفيًا.

سلّم جدولًا واحدًا لكل قالب بهذه الأعمدة: نص العنوان، والصفحات التي يظهر فيها، والموضوع الذي يجب أن يذكره في كل صفحة، والحكم (صحيح، موضوع خاطئ، غير مترجم، نسخة من H1)، والإصلاح مكتوبًا على هيئة العنوان الجديد بالنص الدقيق لكل لغة متأثرة. اختم بملاحظة قصيرة للمطوّر: أي قالب يحتوي على الأرجح على النص الثابت، وأن العنوان يجب أن يُبنى من بيانات الصفحة نفسها لا من نص مكتوب مباشرة في الكود.

للقراءة فقط. لا تغيّر أي شيء في الموقع.

تعمل هذه الأوامر بأفضل شكل عندما يكون مساعد الذكاء الاصطناعي لديك متصلًا بحساباتك عبر Opus Growth.

اربط حساباتك مجانًا