Query Fan out در گوگل معماری جستجوی AI و تاثیر آن بر Semantic SEO

Query Fan-out در گوگل پرسش را به چند جستجوی مرتبط تبدیل می کند. این مقاله سازوکار، تاثیر بر Semantic SEO، AI Overviews و کنترل محتوای سایت را بررسی می کند.

انتشار: , زمان مطالعه: 21 دقیقه
Query Fan-out در گوگل؛ سازوکار جستجوی هوش مصنوعی
دسته بندی: مرجع تعداد بازدید: 20

مخاطب هدف

متخصصان SEO، مدیران سایت، تولیدکنندگان محتوا، متخصصان Digital Marketing، توسعه دهندگان وب و مدیران فنی.

خلاصه یک جمله ای مقاله

Query Fan-out روشی است که Google برای شکستن پرسش های پیچیده به چند جستجوی مرتبط و بازیابی مجموعه گسترده تری از منابع در AI Mode و AI Overviews به کار می گیرد.

Query Fan-out در گوگل؛ معماری جستجوی AI و تاثیر آن بر Semantic SEO

Query Fan-out در گوگل یکی از مهم ترین تغییرات معماری Search در عصر جستجوی مبتنی بر هوش مصنوعی است. در Search کلاسیک، کاربر معمولا یک Query وارد می کرد و Google اسناد مرتبط با همان نیاز را رتبه بندی می کرد. در قابلیت هایی مانند AI Mode و AI Overviews، این جریان می تواند پیچیده تر باشد.

Google توضیح می دهد که AI Mode و AI Overviews ممکن است از تکنیک Query Fan-out استفاده کنند. سیستم در این روش، موضوع را به چند زیرموضوع تقسیم می کند، جستجوهای مرتبط متعددی را روی منابع و Data Sourceهای مختلف اجرا می کند و سپس از اطلاعات بازیابی شده برای ساخت پاسخ و معرفی منابع پشتیبان استفاده می کند.

این تغییر به این معنا نیست که SEO کلاسیک منسوخ شده است. Google صریحا اعلام می کند که برای حضور در قابلیت های AI Search نیازی به Schema مخصوص AI، فایل مخصوص AI یا تکنیک SEO جداگانه وجود ندارد. اصول بنیادی SEO همچنان پایه حضور در AI Overviews و AI Mode هستند.

Query Fan-out در گوگل؛ معماری جستجوی AI و تاثیر آن بر Semantic SEO

Query Fan-out چیست؟

Query Fan-out را می توان نوعی تجزیه پرسش Query Decomposition و بازیابی چندمسیره اطلاعات دانست.

فرض کنید کاربر این سوال را مطرح کند:

«بهترین روش افزایش امنیت یک سایت WordPress چیست و بین Security Headers، WAF و افزونه امنیتی کدام را باید انتخاب کنم؟»

یک موتور جستجوی کلاسیک می تواند اسنادی را پیدا کند که بیشترین ارتباط را با کل Query دارند. اما یک سیستم مبتنی بر Query Fan-out می تواند نیاز اطلاعاتی کاربر را به چند شاخه تبدیل کند، برای مثال:

  • WordPress Security Best Practices
  • نقش Security Headers در امنیت WordPress
  • تفاوت WAF و افزونه امنیتی
  • مزایا و محدودیت های CSP
  • کاربرد HSTS
  • امنیت Login در WordPress
  • مقایسه Cloud WAF و Application Plugin
  • روش Hardening وردپرس

این نمونه صرفا برای توضیح معماری است و به معنای آن نیست که Google دقیقا همین Queryها را تولید می کند.

Google توضیح رسمی ساده تری ارائه می دهد: سیستم چند جستجوی مرتبط را به صورت همزمان در زیرموضوع ها و منابع داده مختلف اجرا می کند و نتایج را برای تهیه یک پاسخ جامع تر کنار هم قرار می دهد.

Query Fan-out چگونه کار می کند؟

Query Fan-out چگونه کار می کند؟

Google جزئیات کامل الگوریتم داخلی Query Fan-out را منتشر نکرده است. بنابراین هر معماری دقیق چندمرحله ای که خارج از اطلاعات رسمی ارائه شود باید در حد مدل مفهومی یا Inference تلقی شود.

با این محدودیت، براساس توضیحات رسمی می توان جریان کلی را چنین تصور کرد:

پرسش کاربر → تشخیص Intent → شناسایی Subtopicها → اجرای چند Search → بازیابی منابع → ارزیابی و ترکیب اطلاعات → پاسخ AI + Supporting Links

1. درک Search Intent

سیستم ابتدا باید بفهمد کاربر واقعا چه چیزی می خواهد.

برای یک Query ساده مانند:

«CSP چیست؟»

نیاز اطلاعاتی محدود است.

اما Query زیر چند Intent دارد:

«برای فروشگاه WordPress استفاده از CSP بهتر است یا WAF و هرکدام چه مشکلاتی ایجاد می کنند؟»

اینجا Intent شامل تعریف، مقایسه، امنیت، Compatibility، پیاده سازی و تصمیم گیری است.

2. شکستن موضوع به Subtopic

Query Fan-out به سیستم اجازه می دهد سوال پیچیده را به فضای جستجوی کوچک تر تقسیم کند.

این ویژگی اهمیت زیادی دارد، زیرا یک صفحه ممکن است برای Query اصلی بهترین نتیجه نباشد، اما برای یکی از زیرموضوع هایی که Google پشت صحنه بررسی می کند منبع بسیار مناسبی باشد.

Google می گوید این روش به AI Search اجازه می دهد صفحات پشتیبان بیشتری پیدا کند و مجموعه متنوع تری از لینک های مفید را نسبت به Search کلاسیک در پاسخ قرار دهد.

3. اجرای چند جستجوی مرتبط

AI Mode می تواند چند Search را همزمان اجرا کند.

Google در توضیحی درباره Visual Search در مارس 2026، Query Fan-out را به حالتی تشبیه کرد که AI Mode چندین جستجو را در زمانی انجام می دهد که کاربر قبلا مجبور بود آنها را جداگانه انجام دهد. این مثال نشان می دهد که Fan-out صرفا Keyword Expansion نیست؛ سیستم می تواند مسئله را به چند نیاز اطلاعاتی مستقل تبدیل کند.

4. بازیابی منابع متنوع

Query Fan-out باعث می شود سیستم فقط به نتایج یک Query وابسته نباشد.

در نتیجه یک پاسخ می تواند اطلاعات خود را از چند نوع منبع دریافت کند:

  • صفحات آموزشی
  • اسناد رسمی
  • صفحات محصول
  • مقاله مقایسه ای
  • انجمن ها
  • منابع تصویری
  • داده های Shopping
  • Knowledge Graph
  • منابع به روز وب

Google درباره AI Mode اعلام کرده که Search می تواند اطلاعات Web را با سیستم های اطلاعاتی دیگر Google ترکیب کند.

5. ساخت پاسخ و Supporting Links

مدل اطلاعات مناسب را ترکیب می کند و در کنار پاسخ، لینک هایی برای بررسی بیشتر در اختیار کاربر قرار می دهد.

از دید ناشر، همین Supporting Link اهمیت دارد. هدف SEO فقط این نیست که صفحه برای Query اولیه کاربر رتبه بگیرد؛ صفحه می تواند برای یکی از جستجوهای فرعی Query Fan-out نیز به عنوان منبع مناسب انتخاب شود.

تفاوت Query Fan-out با Search کلاسیک

تفاوت Query Fan-out با Search کلاسیک

ویژگی Search کلاسیک Query Fan-out
Query اولیه معمولا محور اصلی Retrieval نقطه شروع تحلیل
تعداد نیازهای بررسی شده بیشتر حول Query اصلی امکان بررسی چند Subtopic
Retrieval مجموعه نتایج مرتبط چند مسیر Retrieval مرتبط
نوع پاسخ SERP و لینک ها پاسخ ترکیبی همراه Supporting Links
Query پیچیده ممکن است چند Search دستی لازم باشد سیستم می تواند چند Search را اجرا کند
اهمیت پوشش موضوع مهم اهمیت بیشتری پیدا می کند
فرصت دیده شدن رتبه برای Query امکان حضور از طریق Subtopicهای مرتبط

این جدول یک مقایسه مفهومی است و نباید آن را توصیف کامل معماری داخلی Google تلقی کرد.

ارتباط Query Fan-out با Semantic SEO

اینجا باید Fact را از Recommendation جدا کرد.

Google اعلام نکرده است که «Semantic SEO برای Query Fan-out یک Ranking Factor جدید است». همچنین هیچ دستورالعمل رسمی با عنوان «Query Fan-out Optimization» منتشر نکرده است.

اما از معماری اعلام شده یک نتیجه منطقی حاصل می شود: اگر Search یک موضوع را به چند Subtopic تبدیل کند، محتوایی که روابط مفهومی موضوع را دقیق و ساختارمند پوشش می دهد می تواند برای مجموعه بزرگ تری از نیازهای اطلاعاتی مرتبط باشد.

از Keyword به Topic و Entity حرکت کنید

روش قدیمی می توانست روی تکرار یک Keyword تمرکز زیادی داشته باشد.

در Semantic SEO، سوال اصلی این است:

«این صفحه درباره چه Entityهایی صحبت می کند و رابطه میان آنها چیست؟»

برای مثال در مقاله CSP، صرفا تکرار عبارت Content Security Policy کافی نیست. محتوای مرجع ممکن است لازم باشد ارتباط CSP را با موارد زیر توضیح دهد:

  • XSS
  • HTTP Response Headers
  • nonce
  • hash-source
  • script-src
  • report-only
  • Browser Enforcement
  • Third-party Scripts
  • WordPress
  • CDN
  • CSP Reporting

این ساختار علاوه بر انسان، به موتور جستجو نیز Context بیشتری درباره Topic می دهد.

Search Intent را به مجموعه ای از Intentها تبدیل کنید

هنگام طراحی محتوا فقط نپرسید:

«Keyword اصلی چیست؟»

این سوال ها را نیز بررسی کنید:

  • کاربر قبل از رسیدن به این سوال چه چیزی باید بداند؟
  • بعد از دریافت پاسخ چه سوالی خواهد داشت؟
  • برای تصمیم گیری به چه مقایسه ای نیاز دارد؟
  • چه محدودیت یا Trade-offی وجود دارد؟
  • چه اصطلاحاتی ممکن است باعث ابهام شود؟
  • چه Entityهای دیگری مستقیما به موضوع وابسته هستند؟

این روش به معنای تولید متن طولانی نیست. هر Subtopic فقط زمانی ارزش دارد که یک نیاز واقعی کاربر را پوشش دهد.

آیا برای AI Overviews و AI Mode باید SEO متفاوتی انجام دهیم؟

آیا برای AI Overviews و AI Mode باید SEO متفاوتی انجام دهیم؟

طبق مستند رسمی Google، خیر.

Google اعلام کرده است که شرایط فنی اضافه ای برای نمایش در AI Overviews یا AI Mode وجود ندارد. صفحه برای حضور به عنوان Supporting Link باید Index شده باشد و شرایط لازم برای نمایش در Google Search همراه Snippet را داشته باشد.

Google موارد زیر را همچنان مهم می داند:

  • Googlebot بتواند سایت را Crawl کند.
  • CDN یا Hosting مانع Crawling نشود.
  • Internal Linking مناسب وجود داشته باشد.
  • محتوای مهم به صورت متن در صفحه قرار داشته باشد.
  • Page Experience مناسب باشد.
  • تصاویر و ویدیوهای باکیفیت در صورت نیاز استفاده شوند.
  • Structured Data با محتوای قابل مشاهده صفحه تطابق داشته باشد.
  • Search Console برای تشخیص مشکلات فنی استفاده شود.

آیا Schema مخصوص Query Fan-out یا AI Search وجود دارد؟

خیر.

Google صریحا اعلام می کند برای حضور در AI Overviews و AI Mode:

  • AI Schema خاصی نیاز نیست.
  • Markup اختصاصی AI نیاز نیست.
  • فایل Machine-readable جدیدی نیاز نیست.
  • AI Text File خاصی نیاز نیست.

Structured Data همچنان مفید است، اما همان وظیفه اصلی خود را دارد: ارائه نشانه های صریح درباره معنی و نوع اطلاعات صفحه.

Google توصیه می کند Structured Data با محتوایی که کاربر واقعا روی صفحه می بیند مطابقت داشته باشد. همچنین Google برای Structured Data عمدتا JSON-LD را به دلیل سهولت پیاده سازی و نگهداری پیشنهاد می کند.

بنابراین ساخت Schema ساختگی مانند AIOptimizedContent یا QueryFanOut هیچ مبنای رسمی در Google Search ندارد.

معماری محتوا برای Query Fan-out

به جای ساخت ده ها مقاله مشابه برای Keywordهای بسیار نزدیک، معماری محتوا را براساس رابطه موضوعی طراحی کنید.

Pillar Page

صفحه Pillar باید تصویر کامل موضوع را ارائه کند.

برای مثال:

«راهنمای کامل HTTP Security Headers»

Cluster Content

سپس صفحات تخصصی تر می توانند موضوعات مستقل را بررسی کنند:

  • Content Security Policy چیست؟
  • HSTS چیست؟
  • X-Frame-Options چیست؟
  • Permissions Policy چیست؟
  • CSP nonce چگونه کار می کند؟
  • خطاهای رایج Security Headers
  • تست Security Headers
  • مقایسه CSP و WAF

Internal Linking میان این صفحات به کاربر و Google کمک می کند رابطه میان محتواها را بهتر درک کنند.

Google رسما می گوید Internal Links و Anchor Text مناسب به کاربران و Google در یافتن صفحات و درک رابطه آنها کمک می کنند. همچنین هر صفحه مهم سایت باید حداقل از یک صفحه دیگر لینک قابل Crawl دریافت کند.

کیفیت محتوا از پوشش حجمی مهم تر است

کیفیت محتوا از پوشش حجمی مهم تر است

Query Fan-out نباید بهانه ای برای تولید صدها صفحه Thin Content باشد.

Google در راهنمای People-first Content تاکید می کند که محتوا باید اطلاعات، تحلیل یا ارزش افزوده واقعی ارائه کند. Google همچنین تولید انبوه محتوا صرفا برای جذب Search Traffic یا بازنویسی مطالب دیگران بدون ارزش اضافه را نشانه رویکرد Search Engine-first می داند.

بنابراین هدف صحیح این نیست:

«برای هر Fan-out Query احتمالی یک صفحه بسازیم.»

رویکرد بهتر این است:

«برای هر نیاز اطلاعاتی مهم، بهترین منبعی را بسازیم که واقعا برای کاربر ارزش دارد.»

کنترل حضور محتوا در AI Search

Google برای AI Mode و AI Overviews همان کنترل های Search را در اختیار ناشر قرار می دهد.

noindex

noindex به Google می گوید صفحه یا Resource را در Search Results نمایش ندهد.

از آنجا که Google برای حضور به عنوان Supporting Link در AI features، Index بودن صفحه را الزامی می داند، صفحه noindex عملا شرایط حضور به عنوان Supporting Link را از دست می دهد.

nosnippet

nosnippet اجازه نمایش Text Snippet و Video Preview را نمی دهد. Google می گوید این Directive همچنین مانع استفاده مستقیم از محتوای صفحه به عنوان Direct Input در AI Overviews و AI Mode می شود.

Thumbnail تصویری ثابت در برخی شرایط همچنان ممکن است نمایش داده شود.

max-snippet

max-snippet:N تعداد کاراکترهایی را که Google می تواند به عنوان Text Snippet استفاده کند محدود می کند.

این محدودیت روی مقدار محتوایی که ممکن است به عنوان Direct Input در AI Overviews و AI Mode استفاده شود نیز اثر دارد.

دو مقدار ویژه وجود دارد:

  • max-snippet:0 معادل nosnippet است.
  • max-snippet:-1 به Google اجازه می دهد طول مناسب Snippet را انتخاب کند.

data-nosnippet

data-nosnippet کنترل دقیق تری فراهم می کند.

ناشر می تواند فقط بخش مشخصی از صفحه را از استفاده در Snippet خارج کند، بدون آنکه کل صفحه را با nosnippet محدود کند.

Google این Attribute را برای عناصر span، div و section تعریف کرده است. همچنین هشدار می دهد تغییر این Attribute روی Nodeهای موجود از طریق JavaScript می تواند باعث عدم قطعیت شود، زیرا استخراج ممکن است قبل یا بعد از Rendering انجام شود.

مقایسه چهار کنترل

کنترل Index Snippet تاثیر بر AI Search
noindex خیر خیر صفحه شرایط حضور عادی در Search را ندارد
nosnippet بله Text Snippet ندارد Direct Input برای AI Overviews و AI Mode محدود می شود
max-snippet بله طول محدود Direct Input نیز به همان شکل محدود می شود
data-nosnippet بله بخش انتخابی محدود کنترل بخشی از محتوای قابل استفاده

اشتباه مهم: robots.txt جای noindex نیست

اگر صفحه ای را در robots.txt از Crawl منع کنید، Googlebot ممکن است نتواند noindex یا سایر Robots Meta Directives داخل همان صفحه را ببیند.

Google این موضوع را صریحا توضیح می دهد: Robots Meta Tag و X-Robots-Tag زمانی قابل اعمال هستند که Crawler بتواند URL را Crawl کند.

بنابراین:

Crawl Control و Index Control دو مفهوم متفاوت هستند.

این تفاوت در معماری Technical SEO اهمیت زیادی دارد.

Google-Extended چه ارتباطی با Query Fan-out دارد؟

Google-Extended چه ارتباطی با Query Fan-out دارد؟

Google-Extended را نباید با کنترل AI Overviews و AI Mode اشتباه گرفت.

Google-Extended یک Robots Token است که ناشر می تواند با آن استفاده از محتوای Crawl شده برای Training نسل های آینده Gemini و Grounding در برخی محصولات Gemini و Vertex AI را مدیریت کند.

اما Google صریحا اعلام می کند Google-Extended:

  • بر حضور سایت در Google Search اثر ندارد.
  • Ranking Signal در Google Search نیست.

بنابراین Block کردن Google-Extended به تنهایی روش خروج از AI Overviews یا AI Mode نیست.

برای کنترل محتوای Search باید تنظیمات مربوط به Googlebot، Indexing و Preview Controls را بررسی کرد.

اندازه گیری حضور در AI Overviews و AI Mode

این بخش در سال 2026 تغییر مهمی داشته است.

Google در 3 ژوئن 2026 از Generative AI Performance Report در Search Console رونمایی کرد. Google فعلا این گزارش را به صورت تدریجی برای بخشی از Website Ownerها ارائه می کند.

گزارش فعلی Impressionهای مربوط به:

  • AI Overviews
  • AI Mode

را نشان می دهد.

طبق مستند جاری Search Console، می توان داده ها را براساس این Dimensions مشاهده کرد:

  • Pages
  • Countries
  • Dates
  • Devices

Google در مستند فعلی این گزارش، Query Dimension، Click Metric یا Position Metric را فهرست نکرده است. بنابراین نباید انتظار داشت در این گزارش بتوان تمام Fan-out Queryهای پشت صحنه را مشاهده کرد.

داده های این گزارش همچنان بخشی از Web Search Performance Data هستند.

این نکته مهم است، زیرا Query Fan-out یک فرایند داخلی Retrieval است و Search Console فهرست Subqueryهایی را که مدل در پشت صحنه ایجاد کرده در اختیار مدیر سایت قرار نمی دهد.

چگونه فرصت های Query Fan-out را در سایت پیدا کنیم؟

چون Subqueryهای داخلی Google مستقیما در اختیار ما نیستند، باید آنها را از روی نیازهای واقعی موضوع استخراج کنیم.

برای هر صفحه این فرایند مفید است:

مرحله اول: Intent اصلی را مشخص کنید

مثلا:

«کاربر می خواهد CSP را یاد بگیرد.»

مرحله دوم: Entityهای اصلی را استخراج کنید

مانند:

CSP، Browser، HTTP Header، XSS، Directive، nonce، hash.

مرحله سوم: روابط را پیدا کنید

برای مثال:

CSP → جلوگیری از اجرای Script ناخواسته
nonce → اجازه اجرای Inline Script مشخص
report-only → آزمایش Policy بدون Enforcement

مرحله چهارم: سوال های تصمیم گیری را اضافه کنید

  • چه زمانی باید استفاده شود؟
  • چه محدودیت هایی دارد؟
  • چه چیزی را حل نمی کند؟
  • خطای رایج چیست؟
  • چگونه تست می شود؟
  • چه جایگزین هایی وجود دارند؟

مرحله پنجم: Content Cluster بسازید

اگر Subtopic آن قدر بزرگ است که Search Intent مستقل دارد، آن را به صفحه جداگانه تبدیل کنید و از Pillar Page به آن لینک بدهید.

اگر فقط یک سوال کوتاه فرعی است، همان صفحه اصلی جای مناسب تری برای پاسخ است.

خطاهای رایج در SEO برای Query Fan-out

تولید صفحه برای هر Keyword Variation

Google در SEO Starter Guide یادآوری می کند که سیستم های Language Matching آن می توانند ارتباط صفحه را با Queryهای مختلف درک کنند و لازم نیست تمام شکل های احتمالی عبارت جستجو را پیش بینی کنید.

بنابراین ایجاد صفحات جداگانه برای تفاوت های جزئی Keyword معمولا معماری مناسبی نیست.

ساخت محتوای بسیار طولانی بدون Information Gain

Topical Coverage با Word Count یکی نیست.

Google هیچ Word Count ترجیحی برای Ranking معرفی نمی کند و حتی در راهنمای Helpful Content هشدار می دهد که نوشتن براساس تعداد کلمات فرضی Google رویکرد درستی نیست.

استفاده از Schema ساختگی برای AI

هیچ Schema اختصاصی برای Query Fan-out یا AI Mode وجود ندارد.

Structured Data فقط زمانی ارزش دارد که Type معتبر و مرتبط با محتوای واقعی صفحه باشد.

بستن Googlebot برای جلوگیری از AI

AI Search بخشی از Google Search است. بستن Googlebot می تواند پیامد بسیار گسترده تری از محدود کردن یک قابلیت AI داشته باشد.

برای کنترل Preview یا استفاده مستقیم از متن، Directive مناسب را براساس هدف انتخاب کنید.

راهبرد حرفه ای برای Semantic SEO در عصر Query Fan-out

یک راهبرد منطقی را می توان در هفت اصل خلاصه کرد:

  1. Topic را جایگزین Keyword Stuffing کنید.
    Keyword همچنان برای فهم Search Demand مهم است، اما معماری محتوا را فقط براساس تطبیق Exact Match نسازید.
  2. Entityها و روابط آنها را پوشش دهید.
    صرف نام بردن از Entity ارزش محدودی دارد. رابطه، علت، محدودیت و Context آن را توضیح دهید.
  3. هر Search Intent مستقل را تشخیص دهید.
    Intent مستقل می تواند صفحه مستقل داشته باشد؛ سوال فرعی کوچک لزوما به URL جدید نیاز ندارد.
  4. Internal Linking معنایی ایجاد کنید.
    Anchor Text باید موضوع صفحه مقصد را روشن کند.
  5. منابع اولیه و Evidence را وارد محتوا کنید.
    این کار هم اعتماد کاربر را افزایش می دهد و هم کیفیت اطلاعات را بالا می برد.
  6. اطلاعات مهم را در متن قابل Crawl قرار دهید.
    Google این مورد را مشخصا برای AI features توصیه می کند.
  7. عملکرد را اندازه گیری کنید.
    Search Console، Generative AI Performance Report و Analytics را برای تشخیص تغییر Visibility و رفتار کاربران بررسی کنید.

پرسش های متداول

آیا Query Fan-out یک Ranking Factor است؟

Google آن را به عنوان تکنیک جستجو و Retrieval در AI Mode و AI Overviews معرفی کرده است، نه یک Ranking Factor مستقل. بنابراین عبارت «Ranking Factor جدید Query Fan-out» مبنای رسمی ندارد.

آیا می توان Queryهای تولید شده توسط Query Fan-out را در Search Console دید؟

در مستند فعلی Generative AI Performance Report چنین قابلیتی وجود ندارد. گزارش فعلی Impressionها را براساس Page، Country، Date و Device ارائه می کند و Query Dimension را فهرست نمی کند.

آیا llms.txt برای حضور در Google AI Search لازم است؟

خیر. Google اعلام کرده برای حضور در AI Overviews و AI Mode نیازی به فایل Machine-readable یا AI Text File جدید نیست.

آیا Structured Data شانس حضور در Query Fan-out را تضمین می کند؟

خیر. Structured Data به Google در فهم اطلاعات صفحه کمک می کند و ممکن است Eligibility برخی Rich Results را فراهم کند، اما حتی پیاده سازی صحیح Structured Data نیز نمایش یک Feature را تضمین نمی کند.

آیا Block کردن Google-Extended سایت را از AI Overviews خارج می کند؟

خیر. Google اعلام می کند Google-Extended روی Inclusion در Google Search و Ranking اثر ندارد. کنترل Search AI باید از طریق کنترل های مربوط به Search و Googlebot انجام شود.


دیدگاه های مربوط به این مقاله (برای ارسال دیدگاه در سایت حتما باید عضو باشید و پروفایل کاربری شما تکمیل شده باشد)