اگر یک وبسایت جدید راهاندازی میکنید و هیچ بودجهای برای لینکسازی ندارید، احتمالاً هرگز در صفحه اول گوگل ظاهر نمیشوید. اما تصور کنید بتوانید بهطور مستقیم به منبعی تبدیل شوید که ChatGPT در پاسخ به کاربران از آن نقلقول میکند.
در حالی که سئو سنتی روی اعتبار دامنه و بکلینکها متمرکز است، یک وبسایت ۱۲۶ صفحهای در حال آزمایش رویکردی متضاد است: ساختار دادهای، کلید واقعی پیروزی در نقلقولهای هوش مصنوعی است. این پروژه که توسط یک نویسنده برای معرفی مجموعهای از کتابها، بدون بودجه و بدون مخاطبان قبلی ساخته شده، رتبههای سنتی را نادیده میگیرد. هدف این است که سایت به منبع اصلی تبدیل شود که هوش مصنوعی زاینده (Generative AI) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — هنگام پاسخ به سؤالات خاص کاربر، آن را استخراج و نقل کند.
در سئو سنتی، اولویت با بکلینکها و اعتبار دامنه (Domain Authority) است؛ سیگنالهایی که به دست آوردن آنها برای یک دامنه جدید ممکن است سالها طول بکشد. اما این رویکرد جدید، بازیابی اطلاعات توسط مدلهای زبانی بزرگ (LLM) را به عنوان یک «تکلیف استخراج» (Extraction Task) میبیند. پیشفرض این است که موتورهای جستوجو «سند» را رتبهبندی میکنند (و ۱۰ لینک به کاربر میدهند تا خودش تصمیم بگیرد)، اما مدلهای زبانی «استخراج» میکنند. یک مدل نیاز به قطعهای تمیز و مستقل از متن دارد تا بتواند بدون تغییر آن را بردارد و به یک موجودیت شناختهشده نسبت دهد. این تغییر استراتژی، «قابلیت استخراج» را به یک محور رقابتی مجزا و قابل کنترل تبدیل میکند که سایتهای نوپا میتوانند از روز اول در آن رقابت کنند.
به نقل از مستندات این پروژه، تفاوت در این است که موتورهای جستوجو «سند» را رتبهبندی میکنند، اما مدلهای زبانی «استخراج» میکنند. همانطور که در تحلیل قبلی ما دربارهی نحوه بهینهسازی توسعهدهندگان برای پاسخهای هوش مصنوعی اشاره کردیم، این پروژه از حالت تئوری فراتر رفته و به یک پیادهسازی مستند رسیده است. نویسنده این پروژه آن را نه به عنوان یک مطالعه موردی، بلکه به شکل یک «گزارش ساخت» (Build Log) پیش برده است. در زمان نگارش این گزارش، موتور جستوجوی Bing سایت را «کشفشده اما هنوز نخوانده» (discovered but not crawled) شناسایی کرده که برای دامنهای با صفر لینک ورودی، کاملاً طبیعی و مورد انتظار است.
معماری هسته
سایت با استفاده از فریمورک Astro در حالت استاتیک ساخته شده و محتوا از طریق Markdown و طرحهای (Schemas) تایپشده در Cloudflare Workers به صورت داراییهای استاتیک (Static Assets) مستقر شده است. برای تضمین سازگاری حداکثری، توسعهدهنده تقریباً تمام جاوااسکریپتها را از صفحات محتوایی حذف کرده است. مقدار کل جاوااسکریپت در یک صفحه محتوایی نزدیک به صفر است. منوهای ناوبری، آکاردئونهای FAQ و جستوجوی واژهنامه همگی با استفاده از تگهای <details> و <summary> ساخته شدهاند یا بهگونهای هستند که در صورت عدم پشتیبانی، به محتوای ساده و قابل مشاهده تبدیل شوند (Degrade). این کار تضمین میکند که محتوا حتی برای ابتداییترین خزندههایی (Crawlers) که قادر به اجرای اسکریپت نیستند، در دسترس باشد.
محتوای سایت در ۱۲۶ صفحه توزیع شده است که همگی در زمان Build پیش-رندر شدهاند و شامل موارد زیر است:
- ۴۲ مقاله آموزشی در چهار ستون موضوعی.
- ۶۰ ورودی واژهنامه (هر عبارت در یک صفحه مجزا).
- ۵ صفحه پرسشوپاسخ (FAQ).
- ۱۹ صفحه هاب (Hub)، معرفی کتاب و صفحات کاربردی.
تنها نقطه پویا در کل سایت، مسیر /api/geo است که برای پیشانتخاب فروشگاه آمازون (Amazon Storefront) بر اساس موقعیت کاربر استفاده میشود. هر چیز دیگری در سایت، یک فایل استاتیک روی لبه (Edge) کلودفلر است.
قوانین اجرایی «بدون خطا»
طبق گزارشهای منتشر شده در dev.to، حیاتیترین عامل، HTML رندر شده در سرور است. چون برخی خزندهها جاوااسکریپت را اجرا نمیکنند، یا آن را در مرحله دوم و با بودجه محدود اجرا میکنند، HTML استاتیک تضمین میکند بایتهای ارسالی حاوی محتوای واقعی باشند. نویسنده این مورد را یک ضرورت «غیر چشمگیر» اما حیاتی مینامد که بر تمام عوامل دیگرe اولویت دارد.
هر صفحه آموزشی و FAQ از فرمت سختگیرانه «یک سؤال در هر صفحه» پیروی میکند:
- سلسلهمراتب هدها: عنوان صفحه دقیقاً همان سؤال است و تگ H1 نیز عیناً همان سؤال را تکرار میکند.
- پاسخ فوری: اولین المان بعد از H1، یک پاسخ مستقیم ۴۰ تا ۷۰ کلمهای است که بهطور مستقل معنا دارد. برای مثال، صفحهای با عنوان «سرمایهگذاری واقعاً چیست؟» تعریفی موجز ارائه میدهد: خرید سهمی از چیزی مولد برای کسب درآمد در طول زمان، و اشاره میکند که بازدهی در واقع بهایی است که برای پذیرش عدم قطعیت پرداخت میشود.
- اجبار در طرح: این فیلد پاسخ توسط طرح محتوایی (Content Schema) اجباری شده است؛ یعنی یک صفحه نمیتواند بدون داشتن این پاسخ سریع منتشر شود.
- استقلال از بستر: پاسخها بهگونهای طراحی شدهاند که اگر در محیطی جداگانه نقل شوند، معنایشان تغییر نکند. عباراتی مثل «همانطور که در بالا دیدیم» کاملاً حذف شدهاند چون وقتی یک مدل زبانی متنی را استخراج میکند، این ارجاعات در محیط جدید بیمعنی و گمراهکننده هستند.
برای حل مشکل متادیتای پراکنده، سایت از یک گراف موجودیتی واحد (Unified Entity Graph) استفاده میکند. بهجای ارسال بلوکهای جداگانه JSON-LD (مانند یک بلوک برای Article و یک بلوک جدا برای Organization)، هر صفحه یک @graph واحد ارسال میکند که در آن گرهها (Nodes) از طریق @id به یکدیگر ارجاع میدهند.
اجزای کلیدی این گراف عبارتند از:
- گره شخص (Person Node): تعریف نویسنده، شامل تخصصها یا آنچه نویسنده درباره آن میداند (
knowsAbout) مانند امور مالی شخصی، پسانداز، سرمایهگذاری و بدهی، و همچنین لینکهایsameAsبه پلتفرمهایی مثل آمازون. - گره وبسایت (WebSite Node): شناسایی وبسایت و اتصال ناشر به گره نویسنده.
- گره مقاله (Article Node): مربوط به محتوای خاص هر صفحه که به گره نویسنده ارجاع میدهد و پاسخ ۴۰ تا ۷۰ کلمهای را در بخش
abstractقرار میدهد.
استفاده از یک کامپوننت واحد برای ارسال گرههای Person و WebSite در تمام صفحات باعث میشود حقایق موجودیتی در کل سایت از نظر بایتی دقیقاً یکسان باشند. این کار از توصیفات متناقض نویسنده در صفحات مختلف جلوگیری میکند. ویژگی sameAs بهعنوان ارزشمندترین خط در این گراف ذکر شده است، زیرا به موتورهای جستوجو میگوید پروفایلهای مختلف در پلتفرمهای گوناگون، همگی متعلق به یک شخص واحد هستند.
بهینهسازیهای فنی و «شرطبندیها»
لینکسازی داخلی توسط یک کامپوننت سفارشی انجام میشود که متن رندر شده را با استفاده از Regular Expression برای یافتن عبارات واژهنامه اسکن میکند تا مطمئن شود تطبیق کلمات بهصورت کامل است (مثلاً کلمه "share" نباید داخل کلمه "shareholder" لینک شود). برای جلوگیری از ظاهر «ماشینی» یا بیش از حد بهینهشده، توسعهدهنده دو تصمیم گرفت:
۱. تطبیقها به صورت اجباری در میان متن تزریق نمیشوند تا از ایجاد لنگرهای (Anchors) نامناسب جلوگیری شود.
۲. لینکها به صورت یک لیست صادقانه در پایین صفحه نمایش داده میشوند و تعداد آنها در هر صفحه به حداکثر ۵ مورد محدود شده است.
برای ایندکس شدن، نویسنده از IndexNow استفاده میکند؛ اسکریپتی ۶۸ خطی که نقشه سایت را میخواند و هنگام استقرار (Deployment)، به موتورهای Bing، Yandex و Seznam پینگ میفرستد تا محتوا را سریعتر شناسایی کنند. تأییدیه این روند با یک فایل استاتیک در ریشه سایت انجام میشود. این کار اولویت بالایی دارد چون ایندکس Bing مستقیماً به ChatGPT و Copilot تغذیه میکند.
چندین «شرطبندی» تجربی نیز اجرا شده است که نویسنده اعتراف میکند شواهد تجربی قطعی برای آنها ندارد اما هزینه اجرای آنها بسیار کم است:
- طرح Abstract: پاسخ ۴۰ تا ۷۰ کلمهای در فیلد
abstractدر اسکیما تکرار شده است. چون این متن در ظاهر صفحه هم هست، ریسک «کلوکینگ» (Cloaking) وجود ندارد. - فایل llms.txt: یک فایل Markdown در ریشه سایت که حقایق ساده درباره موجودیت و URLهای استاندارد را لیست میکند. اگرچه این هنوز یک استاندارد جهانی نیست، اما نویسنده را مجبور میکند ادعاهای سایت را یکپارچه نگه دارد.
- وارونگی Robots.txt: بهجای روش رایج مسدود کردن رباتهای AI، نویسنده صراحتاً آنها را دعوت کرده است. فایل
robots.txtشاملUser-agent: *با سیگنالهایContent-Signal: ai-train=yes, search=yes, ai-input=yesاست و بلوکهایAllowصریحی برایGPTBot،ClaudeBot،PerplexityBot،CCBotوGoogle-Extendedدارد.
نویسنده خاطرنشان میکند که برای یک نویسنده ناشناس، ریسک «غایب بودن» در پاسخهای هوش مصنوعی بسیار بیشتر از ریسک «حضور داشتن» است. با این حال، هشدار میدهد که تنظیمات Bot-protection در CDN میتواند بهطور بیصدا این خطوط Allow را نادیده بگیرد و توصیه میکند کاربران محتوای ارسالی واقعی را با مخزن کد خود مقایسه کنند، بهخصوص اگر از سرویسهای مدیریت robots.txt استفاده میکنند.
چالشهای استقرار در کلودفلر
این استقرار دو مشکل خاص در Cloudflare Workers را برملا کرد که در مستندات رسمی واضح نبودند:
- تداخل ریدایرکت: ریدایرکتهایی که در کد Worker نوشته میشوند، هرگز برای فایلهایی که از قبل به عنوان Asset استاتیک وجود دارند اجرا نمیشوند. درخواستهایی که با یک فایل استاتیک مطابقت دارند، مستقیماً از لبه سرو میشوند و اسکریپت Worker فراخوانی نمیشود. برای مثال، ریدایرکت
wwwبه دامنه اصلی در Worker کد مرده بود؛ ریدایرکتهای سطح میزبان باید از طریق Redirect Rules مدیریت شوند. - اولویت مسیرهای Wildcard: یک مسیر Wildcard (مانند
*.example.com/*) اولویت بیشتری نسبت به دامنههای سفارشی R2 دارد. توسعهدهنده یک روز کامل را صرف رفع خطاهای ۴۰۴ برای فایلهای ویدئویی در R2 کرد، زیرا Worker درخواست را میگرفت و صفحه ۴۰۴ وبسایت را برمیگرداند، در حالی که Bucket R2 و دامنه سفارشی فعال بودند.
این رویکرد ساختاری در واقع یک بیمه است. اگر فرضیه «بهینهسازی برای استخراج LLM» شکست بخورد، نتیجه باز هم یک وبسایت استاتیک با عملکرد بالا است که اصول سنتی جستوجو را رعایت کرده است. بدترین حالت این است که شما صرفاً «یک سایت با ساختار عالی» ساختهاید.
برای کسانی که سایتهای جدیدی بدون اعتبار مدیریت میکنند، ترتیب اولویتهای پیشنهادی این است:
۱. ارسال HTML رندر شده در سرور.
۲. پیادهسازی ساختار «یک سؤال در هر صفحه» با پاسخی مستقل در ۷۰ کلمه اول.
۳. ایجاد یک گراف موجودیتی یکپارچه با ارجاعات @id که از یک کامپوننت واحد ارسال شود.
۴. تکمیل لینکهای sameAs برای ایجاد سیگنال هویتی قوی.
۵. لینکسازی داخلی بر اساس محتوای متنی واقعی بهجای نقشههای کلیدواژهای.
اینکه آیا این تغییرات ساختاری واقعاً نرخ نقلقولها را نسبت به نوشتن محتوای باکیفیت افزایش میدهد یا خیر، همچنان یک سؤال باز است. نویسنده قصد دارد پس از عبور دامنه از مرحله اولیه کشف، دادههای عملکرد را به اشتراک بگذارد. توسعهدهندگان علاقهمند میتوانند با بررسی سایت edmundwarde.com ساختار @graph را در سورس کد مشاهده کنند.
گام بعدی شما
- اگر محتوا تولید میکنید، پاسخهای کلیدی خود را در ۷۰ کلمه اول صفحه قرار دهید تا برای استنتاج (Inference) — لحظهای که مدل واقعاً جواب تولید میکند، شبیه خودِ آشپزی و نه دورهی آموزش آشپزی — بهینه باشد.
- یک گراف موجودیتی واحد با استفاده از
@idبسازید تا هوش مصنوعی هویت شما را در تمام صفحات یکسان شناسایی کند. - دسترسی رباتهای AI را در
robots.txtبهجای مسدود کردن، صراحتاً باز کنید.
اما اثر این متد روی نرخ تبدیل کاربران واقعی هنوز مشخص نیست — به تحلیل ما درباره آینده سئو در عصر پاسخهای مستقیم مراجعه کنید.
گفتگو