تاپیکال آتوریتی (Topical Authority) چیست؟

اصطلاح از کجا آمد

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

مثلا یه مقاله هست به اسم Joint Modeling of Topics, Citations, and Topical Authority in Academic Corpora. نویسنده هاش Jooyeon Kim، Dongwoo Kim و Alice Oh ان، تو Transactions of the Association for Computational Linguistics، جلد 5، سال 2017 چاپ شده. این مقاله دقیقا همین عبارت رو به کار برده، ولی برای رتبه بندی اعتبار نویسنده ها تو یه موضوع علمی، نه برای رتبه بندی گوگل.

اون کاربرد به گراف استناد مقاله ها برمیگرده و کاملا محدود به فضای دانشگاهیه. هیچ ربطی به رتبه بندی گوگل یا سئو نداره.

تو ادبیات بازیابی اطلاعات (Information Retrieval) کلاسیک، تو زمینه رتبه بندی وب، چیزی که مطرح بود مفاهیمی مثل ربط موضوعی (Topical Relevance) و خوشه بندی اسناد بود، نه اتوریتی موضوعی (Topical Authority) به این شکل.

شکل امروزی این اصطلاح تو جامعه سئو، بیشتر از طریق Koray Tuğberk Gübür رایج شد. اون یه چارچوب ساخت که Topical Authority رو ترکیبی از پوشش موضوعی (Topical Coverage) و داده تاریخی تعریف میکنه و بر اساسش مفاهیمی مثل نقشه موضوعی و شبکه محتوایی معنایی رو وارد ادبیات عملی سئو کرد.

این یه واقعیت تاریخیه و گفتنش لازم بود. ولی یه نکته رو باید همینجا روشن کنم، چون بقیه متن رو همین پایه ساختم.

از اینجا به بعد، هر ادعایی که میخونید یا منبع اولیه داره یا صراحتا به عنوان استنباط علامت گذاری شده.

اتوریتی در Information Retrieval در برابر اتوریتی در سئو

تو ادبیات Information Retrieval، اتوریتی یه معنای نسبتا دقیق داره و بیشتر به ساختار گراف برمیگرده. الگوریتم هایی مثل PageRank و HITS اتوریتی رو از الگوی ارجاع استخراج میکنن، نه از محتوای متن. تو HITS حتی صراحتا دو نقش جدا تعریف میشه، صفحه ای که منبعه و صفحه ای که فهرست منابعه.

تو ادبیات سئو، همین کلمه کم کم یه معنای دیگه گرفت و به تخصص موضوعی نزدیک شد. این جابجایی معنا بدون اینکه کسی اعلامش کنه اتفاق افتاد و امروز منشا بخش بزرگی از سردرگمیه.

نتیجه عملی این جابجایی مهمه. وقتی میگید یه سایت تو یه موضوع اتوریتی داره، دو چیز کاملا متفاوت ممکنه منظورتون باشه. یکی اینکه سایت های دیگه تو اون موضوع بهش ارجاع میدن. یکی دیگه اینکه محتوای سایت حول یه محور معنایی متمرکزه. اولی چیزیه که دیگران بهتون میدن. دومی چیزیه که خودتون میسازید.

موضع رسمی گوگل

جان مولر، سخنگوی گوگل، بارها گفته سیستمی به اسم Topical Authority وجود نداره. این جمله ها معمولا تو جامعه سئو یا کامل نادیده گرفته میشه یا به عنوان دروغ تفسیر میشه. هر دو برخورد اشتباهه.

چیزی که گفته میشه دقیقا اینه که یه امتیاز واحد با این اسم وجود نداره. این با اینکه مکانیزم های سنجش تمرکز موضوعی وجود دارن تناقضی نداره. تو ادامه میبینیم که چند فیلد جدا، هر کدوم یه بعد از این مفهوم رو اندازه میگیرن.

چرا نبود امتیاز واحد به معنی نبود مکانیزم نیست

یه قیاس ساده کار رو روشن میکنه. تو خودرو چیزی به اسم امتیاز ایمنی به عنوان یه قطعه وجود نداره. ترمز هست، کیسه هوا هست، ساختار بدنه هست. ولی وقتی میگید این خودرو ایمنه، جمله بی معنایی نگفتید. فقط دارید یه خاصیت نوظهور رو با یه اسم صدا میزنید.

Topical Authority هم دقیقا همینه. یه خاصیت نوظهور از چند مکانیزم جدا. اسمش ساخته صنعته، مکانیزم هاش ساخته گوگل.

تفکیک اتوریتی موضوعی از انسجام موضوعی

این تفکیک را Carolyn Holzman مطرح کرد و Shaun Anderson هم پذیرفت و در نوشته هایش به کار برد. به نظر من مهم ترین اصلاح مفهومی سال های اخیر در این حوزه است.

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

تعریف عملیاتی این متن

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

و هر جا مینویسم پوشش موضوعی، منظورم میزان کامل بودن مجموعه محتوای سایت نسبت به فضای پرسش های ممکن در آن موضوع است.

این دو مستقل از هم اند و در ادامه خواهیم دید که گاهی حتی با هم در تعارض قرار میگیرند.

بیشتر متن های فارسی درباره این موضوع از وسط شروع میکنن. میگن گوگل تمرکز موضوعی رو میسنجه و بعد میرن سراغ توصیه. ولی اگه ندونید این مکانیزم برای حل چه مسئله ای ساخته شده، همه توصیه ها در حد شعار میمونن.

وضعیت پیشین

تو پرونده ضدانحصار وزارت دادگستری آمریکا علیه گوگل، یه مجموعه از ارائه های داخلی از حالت محرمانه خارج شد. یکیشون ارائه ایه از Eric Lehman، از مهندسان ارشد جستجو.

چیزی که تو اون ارائه گفته میشه، برای کسی که سال ها درباره فهم معنایی گوگل مطلب خونده، تکون دهنده است. Lehman صراحتا میگه سیستم اسناد رو نمیفهمه و این فهم رو شبیه سازی میکنه. توضیحش اینه که گوگل به جای خوندن سند، واکنش انسان ها به سند رو ثبت و حفظ میکنه.

منطقش این بود که اگه واکنش کاربرها به یه سند مثبت باشه، سند احتمالا خوبه. اگه منفی باشه، احتمالا بد.

مسئله Cold Start

تو همون ارائه، ضعف این معماری هم اعتراف شده. وقتی سندی تازه است یا تازه تغییر کرده یا کم نمایش داده شده، Behavioral Data وجود نداره و سیستم عملا کوره.

این همون چیزیه که تو Machine Learning بهش میگن Cold Start. سیستمی که کاملا به بازخورد وابسته باشه، برای ورودی تازه هیچ تخمینی نداره.

برای گوگل این فقط یه نقص فنی نبود. هر روز میلیون ها صفحه تازه منتشر میشه. سیستمی که تا رسیدن Behavioral Data نتونه دربارشون قضاوت کنه، عملا بخش بزرگی از وب رو از دست میده.

Semantic Layer به عنوان راه حل

تا اینجا چیزی که از ارائه Lehman مستنده، فقط توصیف مسئله است، نه راه حل. خود اون سند درباره اینکه گوگل چطور این مسئله رو حل کرد چیزی نمیگه.

از اینجا به بعد تفسیر منه. برای اینکه سیستم بتونه قبل از دیدن هر کلیکی درباره سند حدس بزنه، باید از متن به یه نمایش عددی برسه که با نمایش بقیه اسناد قابل مقایسه باشه. اگه یه صفحه تازه هیچ سابقه ای نداره، آیا چیز دیگه ای هست که سابقه داشته باشه؟ فرضم اینه که جوابش سایته.

اگه سیستم بدونه این دامنه تو گذشته درباره چه چیزی محتوا تولید کرده و اون محتواها چه سرنوشتی داشتن، میتونه برای صفحه تازه یه تخمین اولیه بسازه. این فرض رو باید در برابر فیلدهای Site-level تو مستندسازی لو رفته، تو بخش های بعدی، بسنجیم.

دو محور جدا در معماری رتبه بندی

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

سوال اول اینه که آیا این منبع قابل اعتماده. این محور Quality/Trust است و مستقل از Query. برای یه سایت مشخص، جوابش تقریبا ثابت میمونه، فرقی نمیکنه کاربر دنبال چی بگرده.

سوال دوم اینه که آیا این سند به این Query مشخص مربوطه، این همون محور Relevance است. کاملا وابسته به Query است و برای هر جستجو از نو محاسبه میشه.

فرض کنید ترافیک سایتتون افت کرده. اگه ندونید مشکل روی کدوم محوره، شش ماه وقت رو روی کار اشتباه میذارید.

اگه مشکل روی محور Quality باشه، هر چقدر محتوای موضوعی تر تولید کنید فایده نداره. اگه مشکل روی محور Relevance باشه، هر چقدر روی اعتماد و شفافیت کار کنید جواب نمیده.

اسناد و شهادت های دادگاه

چیزی که تو این قسمت گفتم، حدس تحلیلگرها نیست. منبعش پرونده ضدانحصار وزارت دادگستری آمریکا علیه گوگله، پرونده شماره 1:20-cv-03010-APM تو دادگاه ناحیه کلمبیا.

تو جریان این پرونده دو نوع سند وارد پرونده عمومی شد. یکی Exhibits، یعنی ارائه ها و اسناد داخلی که از حالت محرمانه خارج شدن. یکی دیگه شهادت زیر سوگند مدیرها و مهندس های ارشد جستجو.

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

تو همین اسناد به یه محور سوم هم اشاره شده که به محبوبیت و گستردگی ارجاعات مربوطه و بیشتر با Link Graph و داده استفاده مرورگر سر و کار داره. ذکرش برای کامل بودن تصویره. موضوع این متن نیست.

سیگنال های Anchor، Body و User Interactions

تو ارائه ای با عنوان Life of a Click (15 مه 2017)، یکی دیگه از اسناد همین پرونده، ساختار پایه رتبه بندی به سه ستون تقسیم شده. ستون اول Body سند است، یعنی چیزی که سند درباره خودش میگه. متن، عنوان، سرتیترها. ستون دوم Anchors هستن، یعنی چیزی که بقیه وب درباره اون سند میگن. ستون سوم User Interactions است، یعنی چیزی که کاربرها با رفتارشون درباره سند میگن.

چرخه عمر Query و اینکه موضوع کجا وارد میشود

وقتی کاربر Query میزنه، پیش از دیدن نتیجه چند مرحله طی میشه.

1. Query تفسیر و گاهی بازنویسی یا به زیرپرسش شکسته میشه.
2. از میون میلیاردها سند، یه مجموعه از کاندیداها بیرون کشیده میشه (Candidate Generation). این مرحله باید خیلی سریع باشه، پس با سیگنال های ارزون کار میکنه.
3. کاندیداها امتیازدهی میشن (Ranking). اینجا سیگنال های گرون تر و دقیق تر وارد میشن.
4. لایه های بازرتبه بندی اعمال میشن، مثل تازگی یا رفتار تاریخی کاربرها.
5. فیلترهایی مثل تنوع نتایج اجرا میشن تا یه دامنه کل صفحه رو نگیره.

موضوع تو دو نقطه وارد میشه. یه بار تو مرحله Candidate Generation، برای اینکه اصلا انتخاب بشید. یه بار دیگه تو مرحله Ranking، برای اینکه رتبه بگیرید.

تفاوت مرحله Retrieval با مرحله Ranking

این تفکیک، عملی ترین چیزیه که از این قسمت میتونید بردارید. Retrieval، مرحله ایه که سیستم تصمیم میگیره شما اصلا وارد رقابت بشید یا نه. Ranking، مرحله ایه که تصمیم میگیره تو رقابت چندم بشید.

برای فهمیدن اینکه فیلدهای امروزی چیکار میکنن، باید بدونید سیستم قبلا چطور موضوع رو تشخیص میداد و چرا اون روش ها کافی نبودن. این مسیر از شمارش ساده کلمه شروع میشه و به Vector میرسه، و هر مرحله اش یه Topic Model متفاوته.

دوران آماری

قدیمی ترین روش، شمارش بود. اگه یه کلمه تو یه سند زیاد تکرار شده و تو کل مجموعه اسناد کم دیده میشه، احتمالا اون سند درباره اون کلمه است. این منطق پایه TF-IDF است و نسخه پیشرفته ترش تو BM25 با در نظر گرفتن طول سند و اشباع تکرار پیاده شد.

این روش هنوز هم تو لایه های اولیه Retrieval کاربرد داره. سریعه و ارزون. ولی یه ضعف بنیادی داره. هیچ درکی از معنا نداره. برای این روش، دو کلمه خودرو و ماشین دو رشته کاملا بی ربط ان.

افسانه ای که باید تمام شود

تو متن های فارسی هنوز به وفور به LSI اشاره میشه و حتی اصطلاحی به اسم کلمات LSI ساخته شده. این اصطلاح ساختگیه.

تکنیک LSI یه روش ریاضی واقعی از اواخر دهه 1980 است که با تجزیه مقدار منفرد روی ماتریس سند و کلمه کار میکنه. ولی اولا هیچ وقت شواهدی مبنی بر استفاده گوگل ازش تو مقیاس وب ارائه نشده، دوما این تکنیک برای مجموعه اسناد تو ابعاد وب از نظر محاسباتی عملی نیست، سوما چیزی به اسم کلمه LSI تو اون روش اصلا تعریف نشده. چیزی که فروشنده های ابزار بهش میگن کلمه LSI، معمولا صرفا هم رخدادی آماری کلماته.

ایندکس مبتنی بر عبارت (Phrase-based Indexing)

پیشرفت واقعی با کار Anna Patterson تو گوگل اومد. ایده اش این بود که به جای کلمه، عبارت رو واحد ایندکس کنیم و مهم تر از اون، برای هر عبارت یه مجموعه از عبارت های مرتبط رو نگه داریم.

نتیجه اش اینه که سیستم میتونه بفهمه سندی که درباره موتور احتراق داخلی است، احتمالا عبارت هایی مثل میل لنگ و سیستم خنک کننده هم داره. اگه سندی ادعا کنه درباره یه موضوعه ولی هیچ کدوم از عبارت های مورد انتظار رو نداشته باشه، پرچم بلند میشه.

تفسیر من اینه که همین جا مفهوم Topical Coverage، اونطور که تو این متن تعریفش کردم، اولین بار یه پایه فنی پیدا میکنه. نه Patterson و نه پتنت هاش اسمی از Topical Coverage یا Topical Authority نمیبرن، این ربطیه که من بین اون کار و مفهومی که تو ادامه دنبال میکنیم میبینم. سند خوب تو یه موضوع، سندیه که عبارت های مورد انتظار اون موضوع رو داره.

ورود Vector

مرحله بعد، تبدیل متن به Vector عددی بود. ایده اصلی اینه که کلمات و بعدها جمله ها و اسناد رو تو یه فضای چندصدبعدی نقطه گذاری کنیم، طوری که فاصله تو اون فضا با شباهت معنایی متناسب باشه.

با این کار، شباهت دو سند دیگه به اشتراک کلمات وابسته نیست. دو مقاله میتونن هیچ کلمه مشترکی نداشته باشن و باز هم Vector هاشون نزدیک باشه.

موجودیت (Entity)

لایه بعدی، Entity است. تفاوت Entity با کلمه کلیدی اینه که Entity به یه چیز واقعی تو جهان اشاره میکنه، نه به یه رشته حروف.

تو ماژول های لو رفته، فیلدی وجود داره که Entity های شناسایی شده رو به محتوای صفحه پیوست میکنه. یعنی سیستم صرفا نمیبینه که رشته سعدی تو متن اومده، بلکه تشخیص میده کدوم سعدی.

مدل چندلایه Intent

تقسیم بندی سنتی Intent جستجو به سه دسته اطلاعاتی و راهبری و تراکنشی، سال هاست تو آموزش های سئو تکرار میشه. این تقسیم بندی برای شروع مفیده ولی برای کار جدی خیلی درشته.

تو مستندسازی لو رفته، فیلدی به نام asteroidBeltIntents وجود داره که اسمش به یه مدل خیلی دانه ریزتر برای طبقه بندی Intent سند اشاره داره. اسمش استعاره ایه از کمربندی از اجرام کوچک، و همین استعاره نکته رو میرسونه. به جای سه دسته بزرگ، تعداد زیادی برچسب کوچک. توجه کنید که این استنباط از نام فیلده، نه از توضیح رسمی. جزئیات عملکردش مستند نیست.

چرا Vector سطح صفحه کافی نبود

حالا به نقطه ای میرسیم که کل این متن حولش میچرخه. فرض کنید یه صفحه دارید که Vectorش دقیقا تو مرکز موضوع حسابداری مالیاتی نشسته. عالی. ولی این صفحه تو سایتی منتشر شده که نود درصد محتواش درباره آشپزیه.

Vector سطح صفحه این تناقض رو نمیبینه. برای دیدنش باید یه Vector در سطح دامنه هم داشته باشید و فاصله صفحه ازش رو حساب کنید. این دقیقا کاریه که فیلدهایی مثل siteFocusScore و siteRadius، که تو ادامه میان، انجام میدن.

کیفیت سایت (Site Quality) و کوئری های مرجع (Reference Queries)

این خانواده که به الگوریتم پاندا نسبت داده میشه، مفهومی معرفی میکنه که تو بحث ما کلیدیه. پتنت اصلی این خانواده Site quality score است، شماره US9031929B1، مخترعان April R. Lehman و Navneet Panda، ثبت شده به نام Google، تاریخ اولویت ژانویه 2012، اعطا شده در می 2015. ایده اینه که برای یه سایت میشه یه مجموعه از Reference Queries تعریف کرد و نسبت ارجاعات یا اشارات به اون سایت رو تو اون مجموعه سنجید.

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

دوم، و این بخش تفسیر منه نه چیزی که خود پتنت میگه: خود متن پتنت این Reference Queries رو برای محاسبه یه Site Quality Score به کار میبره، نه برای تعریف موضوع سایت. اما به نظر من، همین مجموعه Reference Queries، به طور غیرمستقیم یه چیزی هم درباره موضوع سایت نشون میده، چون سیستم عملا داره از روی کوئری هایی که براشون دیده میشید میفهمه سایت شما درباره چیه، نه از روی چیزی که ادعا میکنید.

Phrase-based Indexing و خوشه بندی موضوعی

پتنت اصلی این خانواده Phrase-based indexing in an information retrieval system است، شماره US7536408B2، مخترع Anna L. Patterson، ثبت شده به نام Google، درخواست اولیه ژوئیه 2004. تفسیر من اینه که این خانواده پایه فنی مفهوم Topical Coverage است، اونطور که تو این متن تعریفش کردم، خود پتنت این اصطلاح رو به کار نمیبره. ادعای مرکزیش اینه که برای هر عبارت میشه یه مجموعه از عبارت های مرتبط ساخت و از روی حضور یا غیاب اونها درباره موضوع سند قضاوت کرد.

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

چیزی که این خانواده پشتیبانی میکنه اینه که سیستم انتظار مشخصی از واژگان یه موضوع داره. چیزی که پشتیبانی نمیکنه اینه که هر چه عبارت بیشتری بگنجونید بهتره. پتنت مرتبط دیگه ای از همین مخترع، Detecting spam documents in a phrase based information retrieval system (شماره US8078629B1، اعطا شده دسامبر 2011)، صراحتا درباره Spam Detection از طریق تراکم غیرطبیعی عبارت صحبت میکنه.

طبقه بندی سایت و تخصیص موضوع به دامنه

پتنت این خانواده یه Patent Application است، نه پتنت اعطاشده: Website representation vector، شماره انتشار US20200050707A1 (انتشار بین المللی WO2020033805)، مخترع Yevgen Tsykynovskyy، ثبت شده به نام Google LLC. تفسیر من اینه که این خانواده مستقیم ترین پیشینه فنی چیزیه که امروز اسمش رو تمرکز موضوعی گذاشتیم، خود متن درخواست این اصطلاح رو به کار نمیبره. ایده اصلی اینه که میشه یه سایت کامل رو، نه فقط یه صفحه، با یه بردار نمایشی تو یه حوزه دانش (Knowledge Domain) طبقه بندی کرد. یعنی موضوع، ویژگی صفحه نیست، ویژگی سایت هم هست.

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

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

خانواده Information Gain و منطق تکراری نبودن

پتنت اصلی این خانواده Contextual estimation of link information gain است، شماره درخواست US20200349181A1، اعطا شده به عنوان US11354342B2، ثبت شده به نام Google. این خانواده به سوالی جواب میده که تو عصر تولید انبوه محتوا حیاتی شده. اگه ده سند مشابه داریم، سند یازدهم چی اضافه میکنه؟

منطقش اینه که ارزش یه سند تازه، تابعی از اطلاعاتیه که نسبت به چیزی که کاربر قبلا دیده اضافه میکنه. سندی که فقط بازگوییه، Information Gain نزدیک به صفر داره.

خانواده Query Variants و شکستن Query به زیرپرسش

پتنت اصلی این خانواده Generating query variants using a trained generative model است، شماره US11663201B2، ثبت شده به نام Google، درخواست اولیه 2018 با تاریخ اولویت 2017، اعطا شده در می 2023. این خانواده مربوط به شکستن یه Query به چند زیرپرسش و جستجوی جداگانه برای هر کدومه. تو جستجوی مبتنی بر Language Models این مکانیزم نقش مرکزی پیدا کرده.

ارتباطش با موضوع ما مستقیمه. اگه یه Query به 6 زیرپرسش شکسته بشه، سایتی که هر 6 تا رو پوشش داده، 6 فرصت برای انتخاب شدن داره.

جدول جمع بندی خانواده های پتنتچه ادعایی پشتیبانی میشود و چه ادعایی نمیشود

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

تو سال 2024 حجم بزرگی از مستندسازی داخلی Content Warehouse گوگل به شکل ناخواسته منتشر شد. چیزی که منتشر شد، تعریف ساختارهای داده بود، نه کد الگوریتم ها. این تمایز حیاتیه. ما میدونیم چه چیزهایی ذخیره میشن. نمیدونیم با چه وزنی و تو کدوم مرحله استفاده میشن.

موتور زیرین

فیلدی به نام site2vecEmbeddingEncoded تو مستندسازی لو رفته وجود داره که یه Vector فشرده از محتوای سایت نگه میداره. تفسیر من اینه که این Vector، یه Site Representation عددی از هویت موضوعی دامنه است، خود مستندسازی این تعبیر رو با همین کلمات نمیده. اگه این تفسیر درست باشه، هر چیزی که تو ادامه میاد روی همین یه Vector سواره، بدون اون، هیچ کدوم از سنجه های بعدی قابل محاسبه نیست.

تو همون مستندسازی، فیلد دیگه ای هم هست به اسم asteroidBeltIntents که تو بخش قبل، زیر عنوان مدل چندلایه Intent، بدون نام بردن ازش صحبت کردم. نام فیلد مستنده، چیزی که از عملکردش میفهمیم، تا حدی از خود نام و بافتار اطرافش استنباط میشه، نه از توضیح رسمی. تفسیر محتاطانه اینه که این فیلد به یه مدل دانه ریزتر برای طبقه بندی Intent سند اشاره داره. اینکه دقیقا چند بعد داره، چطور روی رتبه بندی اثر میذاره، یا امروز هم استفاده میشه یا نه، مستند نیست.

امتیاز تمرکز (Topical Focus)

فیلد siteFocusScore میزان اختصاص سایت به یه موضوع مشخص رو کمی میکنه. عدد بالا یعنی سایت تخصصی. عدد پایین یعنی سایت عمومی یا پراکنده.

سه برداشت غلط رایج از این فیلد رو باید همینجا رد کنم. اول اینکه این امتیاز معیار کیفیت نیست. تو قسمت بعدی مفصل بازش میکنم. دوم اینکه بالا بودنش همیشه مطلوب نیست. سایتی که تو موضوعی بدون تقاضا کاملا متمرکز باشه، امتیاز عالی و ترافیک صفر داره. سوم اینکه این عدد رو نمیشه مستقیما دید. هیچ ابزاری بهش دسترسی نداره. هر ابزاری که ادعا کنه این عدد رو نشون میده، عدد خودش رو نشون میده.

شعاع (Topical Radius)

فیلد siteRadius اندازه میگیره که محتوای یه صفحه چقدر از موضوع مرکزی سایت فاصله داره. رابطه این دو ساده است. Radius در سطح صفحه محاسبه میشه، Focus در سطح سایت. Focus، تجمیع Radius های همه صفحاته.

استعاره منظومه و جایی که میشکند

رایج ترین استعاره برای توضیح این دو، منظومه شمسیه. موضوع مرکزی خورشید، هر صفحه یه سیاره، شعاع مدار همون فاصله معناییه. استعاره خوبیه برای شروع، ولی دو جا میشکنه و باید بدونید کجا.

اول اینکه تو منظومه واقعی، خورشید مستقل از سیارات وجود داره. اینجا مرکز از خود صفحات محاسبه میشه. یعنی اگه نصف صفحاتتون رو عوض کنید، خود خورشید جابجا میشه. این نکته تو عمل خیلی مهمه و اکثر توضیح ها نادیده اش میگیرن. برای همین، استعاره منظومه رو زیادی جدی نگیرید، مرکز یه محاسبه است، نه یه جرم مستقل.

دوم اینکه فاصله تو فضای Vector چندصدبعدی، شهود دوبعدی نداره. نمایش زیر یه ساده سازیه، نه تصویر واقعیت.

چهار وضعیت سلامت موضوعی

با این دو سنجه میشه هر سایتی رو تو یکی از چهار وضعیت زیر قرار داد. پیش از خوندن ادامه متن، حدس بزنید سایت خودتون کدومه. تو قسمت اندازه گیری ابزاری میدم که این حدس رو بسنجید.

خانواده NSR و ابهام نامگذاری Chunk

تو همون مستندسازی، خانواده ای از فیلدها با پیشوند NSR وجود داره. گوگل هیچ وقت رسما این مخفف رو باز نکرده، تو تحلیل های ثانویه معمولا اون رو رتبه نرمال شده سایت میخونن، اما این تعبیر قطعی نیست. حداقل یه تحلیلگر شناخته شده حدس جایگزین Neural Semantic Retrieval رو هم مطرح کرده. من از اینجا به بعد فقط از خود مخفف NSR استفاده میکنم. اینها سیگنال هایی در سطح سایت یا میزبان هستن، نه در سطح صفحه.

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

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

و حالا ابهامی که باید حل بشه. تو ادبیات سئو، کلمه Chunk به دو چیز کاملا متفاوت اطلاق میشه و این منشا سردرگمی گسترده ست.

یکی تقسیم متن به قطعات کوچک برای Retrieval تو سیستم های مبتنی بر Vector. این چیزیه که اکثرا وقتی از Chunk حرف میزنن منظورشونه. دیگری فیلدهایی تو همون مستندسازی که به تقسیم سطح دامنه اشاره دارن، یعنی تقسیم یه سایت به زیرمجموعه ها برای محاسبه سیگنال. این با تقسیم متن هیچ ارتباطی نداره. اینکه هر دو یه اسم دارن، اتفاق نامگذاریه، نه نشونه ارتباط.

نسخه بندی Vector ها

بعضی از سیگنال های سطح سایت تو این مستندسازی، نوع داده ای دارن که نشون میده مقدارشون به همراه نسخه نگهداری میشه. معنی فنیش اینه که سیستم فقط مقدار امروز رو ذخیره نمیکنه، بلکه تاریخچه ای از مقادیر قبلی هم داره.

این قسمت رو جدا نوشتم چون به نظرم مهم ترین اصلاح فکریه که خواننده فارسی زبان لازم داره.

Topical Focus با Quality یکی نیست

فرض کن یه سایت بسازی که فقط و فقط درباره یه موضوع باریکه و 100 مقاله کاملا متمرکز داره. Topical Focus ات تقریبا کامله. حالا فرض کن همه اون 100 مقاله سطحی، بازنویسی شده، و بدون منبع باشن. آیا این سایت رتبه میگیره؟

نه. چون Focus به این سوال جواب میده که سایت درباره چیه، نه به این سوال که آیا خوبه.

سایت عمومی با Trust بالا و Topical Focus پایین

یه روزنامه بزرگ عمومی رو در نظر بگیرید. سیاست، ورزش، اقتصاد، آشپزی، همه چیز. Topical Focus اش قطعا پایینه. اما این سایت ها تو خیلی از Query ها رتبه های بالا میگیرن. اگه Focus تنها عامل بود، این ممکن نبود.

توضیحم اینه، و این تفسیر منه نه ادعای مستند: این سایت ها روی محور دیگه ای امتیاز خیلی بالایی دارن، و به نظرم الگوی موضوعی شون هم قابل تشخیصه، چیزی شبیه الگوی رسانه عمومی معتبر. خانواده پتنت Site Classification که تو بخش پتنت ها دیدیم (Website representation vector، شماره US20200050707A1) نشون میده چنین طبقه بندی ای از نظر فنی ممکنه، اما این ثابت نمیکنه گوگل امروز دقیقا چنین دسته ای رو تو رتبه بندی زنده به کار میبره.

مثال معکوس، سایت کاملا متمرکز با محتوای نازک

حالت برعکس هم به همون اندازه آموزنده ست و تو سایت های فارسی خیلی رایج تر. سایتی بسازید که فقط درباره یه موضوع باریک باشه و 200 مقاله کاملا متمرکز داشته باشه. Topical Focus اش تقریبا کامله.

اگه اون 200 مقاله بازنویسی مطالب موجود باشن، بدون منبع، بدون داده اولیه، و بدون تجربه دست اول، این سایت رتبه نمیگیره. و مهم تر اینکه صاحبش هیچ وقت نمیفهمه چرا، چون همه توصیه های رایج رو رعایت کرده.

اثر ناهنجاری

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

مثال فارسیش رو دیده ام. سایتی که نیمی محتوای حقوقی و نیمی محتوای تناسب اندام داره. هیچ کدوم بد نیستن. ولی این ترکیب با هیچ الگوی شناخته شده ای جور در نمیاد.

Quality Ceiling

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

پیامدش اینه که یه سایت با سابقه طولانی Quality پایین، حتی اگه امروز Topical Focus بی نقصی بسازه، سقفی بالای سرش هست که یه شبه برداشته نمیشه. اگه روی سایتی کار میکنید که سابقه بدی داره، این رو در برآورد زمانی تون لحاظ کنید.

اسم صنعتی است، مکانیزم نه

اصطلاح کاوریج آتوریتی (Coverage Authority) برخلاف بقیه مفاهیم این متن، حتی یه منبع ثانویه معتبر هم پشتش نداره. کاملا ساخته صنعته. اما مکانیزمی که بهش اشاره میکنه واقعیه و همون چیزیه که تو خانواده پتنت Query Variants دیدیم. پس اسم رو جدی نگیرید، مکانیزم رو جدی بگیرید.

عمق در برابر گستره

پیش از هر چیز باید بدونید Coverage دو جهت داره و این دو با هم رقابت میکنن، چون منابع شما محدوده. گستره یعنی تعداد موضوعات فرعی که لمس میکنید. عمق یعنی اینکه هر موضوع فرعی رو تا کجا میبرید.

تیمی که ماهی 10 مقاله میتونه بنویسه، یا میتونه 10 موضوع فرعی رو یه بار لمس کنه، یا 3 موضوع رو کامل کنه. هر دو انتخاب مشروعه ولی نتیجه شون فرق داره.

سه نوع Coverage که با هم اشتباه گرفته میشوند

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

Query Coverage یعنی سایت شما برای چند درصد از Query های اون موضوع محتوا داره. این ساده ترین و سطحی ترین سنجه است.

Entity Coverage عمیق تره. یعنی سایت شما چند درصد از Entity های مرتبط با اون حوزه رو واقعا پوشش داده، نه فقط اسمشون رو آورده.

Intent Coverage سخت ترین و ارزشمندترینه. یعنی سایت شما برای چند نوع Intent مختلف تو اون موضوع، یه جواب واقعی داره، نه یه صفحه واحد که بخواد همه رو با هم جواب بده.

رابطه Coverage با Query Variants

تو پتنت های Query Variants دیدیم که یه Query میتونه به چند زیرپرسش شکسته بشه و برای هر کدوم جستجوی جداگانه ای انجام بگیره. تو جستجوی مبتنی بر Language Models، این مکانیزم نقش مرکزی داره.

پیامدش برای Coverage مستقیمه. اگه Query کاربر به 6 زیرپرسش شکسته بشه، سایتی که هر 6 تا رو پوشش داده، 6 بار شانس داره که به عنوان منبع انتخاب بشه. سایتی که فقط یکی رو پوشش داده، یه بار.

سقف Coverage، جایی که استراتژی حجم شکست میخورد

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

تو مستندسازی لو رفته، ماژولی به نام QualityCopiaFireflySiteSignal هست که سیگنال های سطح سایت رو نگه میداره. تفسیر من اینه که این سیگنال ها برای تشخیص Scaled Content به کار میرن، خود مستندسازی این هدف رو با همین کلمات نمیگه. دو فیلد اون مستقیما به این توصیه میخورن.

فیلد numOfUrlsByPeriods تعداد آدرس های کشف شده رو در بازه های 30 روزه پشت سر هم ثبت میکنه، یعنی سرعت رشد تعداد صفحات. فیلد numOfArticlesByPeriods تعداد صفحاتی رو میشمره که Threshold کیفی مشخصی (طبق گزارش ها، امتیاز 0.8 یا بالاتر) رو رد کرده ان، اون هم در همون بازه های 30 روزه.

پیامدش روشنه. Publishing Velocity و سرعت تولید صفحه باکیفیت جدا از هم اندازه گیری میشن. نسبت این دو به هم، یه سیگنال مستقله.

نقطه اشباع و بازدهی منفی

هر موضوعی یه فضای محدود از پرسش های واقعی داره. وقتی اون فضا پر شد، مقاله بعدی چیزی اضافه نمیکنه.

از اون نقطه به بعد، تولید بیشتر سه اثر منفی داره. اول اینکه Information Gain اش نزدیک صفره. دوم اینکه به ناچار به حاشیه موضوع میره و Radius رو باز میکنه. سوم اینکه شکاف دو ستون شکل قبل رو باز میکنه.

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

چرا Coverage بدون Quality، Focus را رقیق میکند

این قسمت، Coverage و Focus رو به هم وصل میکنه و توضیح میده چرا این دو گاهی در تعارض قرار میگیرن. مرکز موضوعی سایت شما از میانگین محتواتون محاسبه میشه. این رو تو توضیح استعاره منظومه گفتم و اینجا نتیجه اش رو میبینیم.

وقتی برای Coverage بیشتر، محتوای حاشیه ای اضافه میکنید، دو اتفاق همزمان میفته. اول اینکه صفحات تازه Radius بزرگی دارن. دوم و مهم تر اینکه خود مرکز به سمتشون جابجا میشه. یعنی صفحات هسته شما، بدون اینکه یه کلمه شون عوض بشه، از مرکز دورتر میشن.

چرا صفحه خوب در سایت پراکنده کمتر دیده میشود

اگه مکانیزم Cold Start رو که در ابتدا توضیح دادم به یاد داشته باشید، و با تفسیری که تو بخش های قبل ساختیم، جواب واضحه. سیستم برای صفحه تازه شما تخمین اولیه ای میسازه و بخشی از اون تخمین، طبق اون تفسیر، از هویت موضوعی دامنه (Site Identity) میاد.

سایت پراکنده، تخمین اولیه ضعیف تری تولید میکنه. صفحه شما با نقطه شروع پایین تری وارد رقابت میشه و باید مسافت بیشتری رو با Behavioral Data جبران کنه.

سایت چندموضوعی (Multi-topic)، کجا جواب میدهد

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

Subdomain یا Subdirectory

این سوال قدیمی، تو چارچوب این بحث جواب روشن تری پیدا میکنه. اگه دو موضوع شما واقعا دو کسب و کار جدا هستن و هر کدوم حجم و کیفیت کافی دارن، Subdomain مرز موضوعی روشن تری میسازه.

اگه یکی از دو موضوع کوچیکه، Subdomain فقط یه Entity ضعیف تازه میسازه که هیچ چیز از سایت اصلی به ارث نمیبره. تو این حالت Subdirectory بهتره، یا اصلا نداشتن اون محتوا.

محتوای قدیمی خارج از موضوع

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

نقشه موضوعی (Topic Map)، بدون اسطوره سازی

Topic Map چیز پیچیده ای نیست. یه مدل مفهومی از حوزه شماست که مشخص میکنه چه چیزهایی تو اون حوزه وجود دارن و چه نسبتی با هم دارن.

چیزی که اونو از فهرست کلمه کلیدی جدا میکنه، اینه که واحدش مفهومه نه عبارت جستجو. دو عبارت جستجوی متفاوت میتونن یه مفهوم باشن، و یه عبارت جستجو میتونه چند مفهوم رو تو خودش داشته باشه.

1. فهرست Entity های حوزه رو بنویسید. برای بیمه بدنه یعنی شرکت بیمه، بیمه نامه، خسارت، کارشناس، فرانشیز، پوشش اضافی و مانند اینها.
2. برای هر Entity، ویژگی هاش رو بنویسید. فرانشیز چند نوع داره، چطور محاسبه میشه، قابل تغییره یا نه.
3. روابط بین Entity ها رو مشخص کنید. کدوم Entity پیش نیاز کدومه.
4. حالا و فقط حالا سراغ Query Data برید و ببینید مردم درباره هر گره چی میپرسن. اگه گره ای هست که هیچ کس دربارش نمیپرسه، یادداشتش کنید ولی در اولویت آخر بذارید.
5. برای هر گره تصمیم بگیرید صفحه مستقل میخواد یا زیرمجموعه ای از صفحه دیگه است. این تصمیم رو بر اساس تفاوت Intent بگیرید، نه بر اساس حجم کلمه.

نقدی که به خوشه بندی مرکز و پیرامون وارد است

مدل رایج اینه که یه صفحه مادر بسازید و صفحات فرزند بهش لینک بدن. این مدل تو خیلی از موارد کار میکنه، اما دو ایراد داره که کمتر گفته میشه.

اول اینکه ساختار درختی رو بر واقعیتی تحمیل میکنه که اغلب شبکه است نه درخت. خیلی از مفاهیم به چند مفهوم دیگه مربوط ان، نه فقط به یه والد.

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

Internal Linking، دو کارکرد جدا

Internal Linking دو کار متفاوت میکنه و اینها رو نباید قاطی کرد. کارکرد اول انتقال اهمیته، شبیه منطق PageRank. صفحه ای که از صفحات مهم لینک میگیره، تو سنجه های اهمیت داخلی بالا میره. کارکرد دوم اعلام رابطه معناییه. Anchor Text و بافت اطراف لینک، به سیستم میگن این دو صفحه چه نسبتی دارن.

هماهنگی سیگنال ها

عنوان صفحه، سرتیتر اصلی، و Anchor Text هایی که به اون صفحه اشاره میکنن، باید یه حرف بزنن. این ساده ترین و کم هزینه ترین کاریه که میتونید بکنید و تو سایت های فارسی به شکل شگفت آوری نادیده گرفته میشه. صفحه ای دیده ام که عنوانش درباره آموزش بود، سرتیترش درباره خرید، و Anchor Text های داخلیش درباره قیمت.

تاکسونومی و ساختار آدرس و دسته بندی

Category، اعلام رسمی شما درباره ساختار موضوعی سایته. اگه Category تون با واقعیت محتوا جور نباشه، سیگنال متناقض میفرستید. به تجربه من، Category ای که فقط 2 یا 3 مطلب داره، بیشتر ضرر میزنه تا فایده. یا پرش کنید یا تو Category بزرگ تر ادغامش کنید.

ترتیب انتشار

سوالی که زیاد پرسیده میشه اینه که آیا مهمه از کدوم مقاله شروع کنیم. جواب صادقانه اینه که سند مستقیمی درباره ترتیب انتشار وجود نداره. چیزی که هست، این استدلال غیرمستقیمه.

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

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

صفحات پشتیبان در برابر صفحات پولساز

هر Topic Map دو نوع صفحه داره و خلط کردنشون یکی از پرهزینه ترین اشتباهاته. صفحه پولساز، صفحه ایه که مستقیم به درآمد وصله. صفحه محصول، صفحه خدمت، صفحه فرود کمپین.

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

آنچه قابل استناد است

تو مستندسازی لو رفته فیلدی به نام authorObfuscatedGaiaStr وجود داره که به یه Structured Author Identifier اشاره میکنه. یعنی سیستم نویسنده رو به عنوان یه Entity جدا از صفحه نگه میداره. این حداکثر چیزیه که میشه با اطمینان گفت. اینکه از این شناسه چه استفاده ای میشه و با چه وزنی، مستند نیست.

Site Credibility در برابر Author Credibility

این دو رو نباید یکی گرفت. سایت میتونه تو یه موضوع متمرکز باشه و نویسنده هاش هیچ سابقه قابل تشخیصی نداشته باشن. عکسش هم ممکنه.

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

خطای رایج

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

تا اینجا مفهوم بود. از اینجا ابزار است.

چه چیزی را نمیشود اندازه گرفت

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

سنجش Topical Focus با داده Google Search Console

ساده ترین روش و بدون نیاز به هیچ ابزاری. Query های 16 ماه اخیر رو خروجی بگیرید. با Query Clustering، دستی یا خودکار، به خوشه های موضوعی تقسیمشون کنید. حالا ببینید چند درصد از کل Impression شما تو بزرگ ترین خوشه است.

اگه این عدد در طول زمان پایین میاد، طبق این Metric خانگی، Topical Focus قابل مشاهده شما داره رقیق میشه، حتی اگه ترافیک کل ثابت باشه.

Impression Share در مجموعه Query های یک موضوع

Metric قبلی Focus کلی رو میداد. این یکی وضعیت شما رو تو یه موضوع مشخص میسنجه. فهرست Query های اون موضوع رو بسازید، از داده Query خودتون و از پژوهش کلمه. حالا دو عدد بگیرید. برای چند درصد از اون Query ها اصلا Impression میگیرید، و مجموع Impression شما تو اون مجموعه چقدره.

عدد اول Coverage شما رو نشون میده. عدد دوم قدرت شما رو. این دو با هم فرق دارن و باید جدا دیده بشن. اگه عدد اول بالا و عدد دوم پایین باشه، یعنی همه جا هستید ولی هیچ جا قوی نیستید. این دقیقا وضعیتیه که تو قسمت عمق در برابر گستره توضیح دادم و درمانش عمق بخشیدنه نه تولید بیشتر.

سنجش Semantic Distance صفحات از مرکز سایت

این کاریه که تقریبا هیچ کس تو فارسی انجام نداده و بیشترین ارزش رو داره. منطقش دقیقا همون منطق Radius است. متن هر صفحه رو به Vector تبدیل میکنیم، میانگین همه Vector ها رو به عنوان مرکز سایت میگیریم، و فاصله هر صفحه از اون مرکز رو حساب میکنیم.

#  pip install sentence-transformers trafilatura numpy requests

import numpy as np
import requests
import trafilatura
from sentence_transformers import SentenceTransformer

MODEL = "intfloat/multilingual-e5-large"
model = SentenceTransformer(MODEL)


def fetch_text(url: str, max_chars: int = 6000) -> str | None:
    try:
        html = requests.get(url, timeout=20).text
        text = trafilatura.extract(
            html, include_comments=False, include_tables=False
        )
        return text[:max_chars] if text else None
    except Exception:
        return None


def embed(texts: list[str]) -> np.ndarray:
    prefixed = [f"passage: {t}" for t in texts]
    return model.encode(prefixed, normalize_embeddings=True)


def analyse(urls: list[str]) -> list[dict]:
    pages = []
    for u in urls:
        t = fetch_text(u)
        if t and len(t) > 300:
            pages.append({"url": u, "text": t})

    vectors = embed([p["text"] for p in pages])

    centroid = vectors.mean(axis=0)
    centroid = centroid / np.linalg.norm(centroid)

    for page, vector in zip(pages, vectors):
        similarity = float(np.dot(vector, centroid))
        page["similarity"] = round(similarity, 4)
        page["radius"] = round(1 - similarity, 4)
        del page["text"]

    return sorted(pages, key=lambda p: p["radius"], reverse=True)


def focus_score(results: list[dict]) -> float:
    return round(float(np.mean([r["similarity"] for r in results])), 4)


if __name__ == "__main__":
    urls = [line.strip() for line in open("urls.txt") if line.strip()]
    results = analyse(urls)

    print(f"focus score: {focus_score(results)}")
    print("\noutliers:")
    for r in results[:20]:
        print(f"{r['radius']:.4f}  {r['url']}")

نسبت Publishing Velocity vs. Quality

معادل خانگی همون دو فیلدی که تو بحث Publishing Velocity گفتم. ساده است و به هیچ ابزاری نیاز نداره. برای هر ماه گذشته دو عدد بنویسید. تعداد آدرس های منتشرشده، و تعداد آدرس هایی که تو همون دوره حداقل یه معیار موفقیت رو رد کرده ان. معیار موفقیت رو خودتون تعریف کنید، مثلا صفحه ای که تو 3 ماه اول حداقل 100 Impression گرفته باشه.

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

شاخص های هشدار و نشانه های رقیق شدن موضوع

• سهم بزرگ ترین خوشه موضوعی در Impression کل، ماه به ماه کم میشه.
• تعداد Query های منحصربه فردی که Impression میگیرید بالا میره ولی مجموع کلیک ثابته. یعنی دارید در حاشیه دیده میشید نه در هسته.
• میانگین موقعیت در Query های هسته بدتر میشه در حالی که در Query های حاشیه ای بهتر میشه.
• نسبت صفحات ایندکس شده به صفحات دارای Impression، پایین میاد.

بازه زمانی واقع بینانه برای مشاهده اثر

اثر تغییرات ساختاری و موضوعی، ماه ها طول میکشه. به تجربه من، برای سایتی با چند صد صفحه، 6 ماه بازه معقولی برای قضاوته. برای سایت بزرگ تر، بیشتر. اگه کسی بهتون گفت تو 6 هفته Topical Authority میسازه، همونجا بحث رو تموم کنید.

• امتیازی به اسم Topical Authority وجود دارد و قابل اندازه گیری است

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

• نوشتن 100 مقاله در یک موضوع یعنی اتوریتی

  غلط. اگه اون 100 مقاله Information Gain نداشته باشن، صرفا شکاف بین حجم و کیفیت رو باز میکنن که خودش سیگنال منفیه.

• هر چه تخصصی تر بهتر

  غلط. تخصص در موضوعی که تقاضا نداره، Topical Focus کامل و ترافیک صفر میده.

• Topical Focus بالا یعنی سایت باکیفیت

  غلط. Topical Focus و Quality دو Metric جدا هستن.

• اسم فیلد یعنی عملکرد فیلد

  غلط و پرتکرارترین خطای تحلیلی این حوزه. نام گذاری داخلی مهندس ها، توضیح رسمی نیست.

• پتنت ثبت شده یعنی سیستم پیاده سازی شده

  غلط. حداکثر نشون میده این طرز فکر وجود داشته.

• کلمات LSI باید در متن باشند

  این مفهوم اصلا وجود نداره.

• اصطلاح ابزار شخص ثالث یعنی مفهوم گوگل

  غلط و خیلی پرتکرار. Metric هایی که ابزارهای تجاری میسازن، محصول همون شرکت ها هستن و هیچ نسبتی با سیستم های گوگل ندارن. وقتی ابزاری بهتون امتیازی برای Topical Authority نشون میده، اون عدد ساخت خودشه، نه خونده شده از جایی. استفاده از این اعداد برای مقایسه با رقبا اشکالی نداره. استناد بهشون به عنوان واقعیت الگوریتمی اشکال داره.

• استنباط تحلیلگر یعنی متن سند

  بیشتر چیزی که درباره لیک نوشته شده، تحلیل و استنباطه و نویسنده های معتبرش هم صراحتا این رو مینویسن. جدا نکردن این دو، منشا بیشتر ادعاهای غلط این حوزه است.

Audit وضعیت فعلی Topical Focus

1. اسکریپت رو روی همه آدرس های ایندکس شده اجرا کنید و فهرست Radius بگیرید.
2. خروجی Search Console رو خوشه بندی موضوعی کنید.
3. نسبت Publishing Velocity به Quality رو برای 12 ماه گذشته بسازید.

این سه خروجی، تصویر وضعیت شماست. قبل از داشتن این سه، هیچ تصمیمی نگیرید.

Topic Boundary بر اساس تقاضا و توان تولید

سه معیار رو همزمان ببینید. تقاضای واقعی، توان تولید تیم شما، و شدت رقابت. Topic Boundary درست، جاییه که هر سه قابل قبول باشن. اگه تقاضا بالا ولی توان تولید شما ماهی 3 مقاله است، مرز رو باریک تر کنید. باریک کردن مرز، عقب نشینی نیست، تمرکز منابعه.

Coverage Gap Prioritization

وقتی فهرست شکاف ها رو درآوردید، معمولا از توان تولیدتون بلندتره. ترتیب پر کردنشون تعیین میکنه 6 ماه بعد کجا ایستادید. سه معیار رو برای هر شکاف نمره بدید.

نزدیکی به مرکز موضوعی. شکافی که در هسته شماست، هم راحت تر رتبه میگیره هم Topical Focus رو تقویت میکنه. شکافی که در حاشیه است، هر دو رو برعکس میکنه.

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

هزینه تولید واقعی. مقاله ای که به مصاحبه با متخصص یا داده اولیه نیاز داره، گرونه. این رو در برآورد بیارید، نه فقط تعداد کلمه.

تصمیم گیری درباره Off-topic Content

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

تنظیم Publishing Velocity متناسب با ظرفیت Quality

ظرفیت Quality واقعی تیم رو اندازه بگیرید، نه ظرفیت آرزویی. بعد Publishing Velocity رو روی همون عدد قفل کنید. اگه مدیر یا مشتری اصرار بر حجم داره، شکل چهار رو نشونش بدید. این تنها استدلال مستندیه که تو این بحث در اختیار دارید.

برنامه بازبینی دوره ای

Review باید تقویم داشته باشه، وگرنه انجام نمیشه.

Checklist نهایی

• Topical Focus و فهرست Radius رو دوباره بگیرید و با فصل قبل مقایسه کنید.
• نسبت Publishing Velocity به Quality رو به روز کنید.
• Category هایی که کمتر از 5 مطلب دارن رو Review کنید، این آستانه Review است، نه حذف یا Merge خودکار.
• 20 صفحه پرت جدید رو از درخت تصمیم عبور بدید.
• سهم خوشه اصلی در Impression کل رو ثبت کنید.

اینو مینویسم چون هر متنی که ادعا کنه جای همه چیز رو میگیره، همونجا اعتبارش رو از دست میده.

این نوشته به شما میده. نقشه مفهومی حوزه، تفکیک مستند از ادعا، روش اندازه گیری قابل اجرا، و چارچوب تصمیم گیری.

این نوشته به شما نمیده. بازخورد روی پروژه خودتون. هیچ متنی نمیده. تشخیص اینکه سایت شما تو کدوم یکی از چهار وضعیت شکل سه است و چی براش اولویت داره، به نگاه کردن به داده خود شما نیاز داره.

و یه چیز دیگه که هیچ متن و هیچ دوره ای نمیده. صبر. اثر این کارها ماه ها طول میکشه و بیشتر شکست هایی که دیده ام، از بی صبری اومدن نه از ندونستن.

هر چیزی که تو این متن خوندید، از یکی از این دسته ها اومده. دسته آخر سند نیست و به همین عنوان علامت گذاری شده.

• سند دادگاهاسناد و شهادت های پرونده ضدانحصار وزارت دادگستری آمریکا علیه گوگل
• سند رسمیمستندات منتشرشده خود گوگل
• پتنتخانواده های پتنت که شماره هایشان پیش از استناد باید راستی آزمایی شوند
• تحلیل ثانویهتحلیل و استنباط، نه سند. برای فهمیدن نقشه راه مفیدند، برای استناد نه

اظهارات سخنگویان گوگل با تاریخ و پلتفرم، پیش از استناد باید تو منبع اصلی بررسی بشن. اظهارات نقل شده تو منابع ثانویه، منبع اولیه نیستن.

مقاله های دیگر همین مجموعه

تحقیق بر پایه مستندات. نوشته شهرام رهبری