یک پروفایل نویسنده شیک نمیتواند ادعای اشتباه را معتبر کند. افزودن چند مدرک، لوگوی مشتری یا کد Schema هم اگر روش تحقیق، منبع و مسئول پاسخگویی روشن نباشد، اعتماد نمیسازد. مسئله اصلی E‑E‑A‑T این نیست که «چه سیگنالی به گوگل بفرستیم»؛ مسئله این است که کاربر بتواند مسیر هر ادعا را از نویسنده و تجربه او تا شاهد، بازبینی و اصلاح دنبال کند.
این راهنما E‑E‑A‑T را به یک فرایند تحریریه قابل اجرا برای سایت فارسی تبدیل میکند. وضعیت اسناد و توصیهها در ۶ اوت ۲۰۲۶ (۱۵ مرداد ۱۴۰۵) بررسی شده است. هرجا از گوگل حرف میزنیم، میان گفته رسمی، برداشت تحلیلی و آزمون داخلی تفاوت میگذاریم.
E‑E‑A‑T چیست و چه چیزی نیست؟
E‑E‑A‑T یک لنز برای سنجش کیفیت و اعتماد است، نه افزونه، نمره دامنه یا دستور آماده. ارزیابان انسانی کیفیت از این مفهوم برای ارزیابی نمونه نتایج استفاده میکنند؛ آنها رتبه یک صفحه را مستقیم تغییر نمیدهند. سامانههای خودکار گوگل نیز مجموعهای از عوامل را بررسی میکنند که میتواند با تجربه، تخصص، مرجعیت و اعتماد همراستا باشد.
| برداشت رایج | واقعیت عملی | تصمیم درست |
|---|---|---|
| «E‑E‑A‑T یک فاکتور رتبهبندی است» | خود این عبارت یک سیگنال منفرد و قابل اندازهگیری نیست | روی کیفیت، منبع، شهرت، شفافیت و رضایت کاربر کار کنید |
| «افزونه به ما امتیاز E‑E‑A‑T میدهد» | ابزار ثالث فقط Proxy یا چکلیست خودش را گزارش میکند | تعریف امتیاز، داده ورودی و محدودیت ابزار را بخوانید |
| «Schema باعث افزایش E‑E‑A‑T میشود» | داده ساختاریافته موجودیت و محتوای قابل مشاهده را توصیف میکند | Markup را با صفحه واقعی، نام نویسنده و URL پروفایل منطبق کنید |
| «بیوگرافی بلند نویسنده کافی است» | اعتبار باید به موضوع و ادعای همان صفحه مرتبط باشد | شاهد تجربه، منبع و بازبینی را کنار ادعای حساس قرار دهید |
| «هرچه لینک منبع بیشتر، بهتر» | تعداد منبع جای ارتباط دقیق Claim و Evidence را نمیگیرد | منبع اولیه، بهروز و دقیقاً پشتیبان ادعا را انتخاب کنید |
در راهنمای رسمی محتوای مفید و قابل اعتماد گوگل تصریح شده که E‑E‑A‑T یک فاکتور مشخص رتبهبندی نیست و «Trust» مهمترین جزء است. بنابراین وعدههایی مانند «افزایش امتیاز E‑E‑A‑T در ۳۰ روز» از چیزی حرف میزنند که معیار رسمی و قابل مشاهدهای ندارد.
چهار جزء E‑E‑A‑T چگونه به اعتماد میرسند؟
| جزء | پرسش کاربر | شاهد قوی | شاهد ضعیف |
|---|---|---|---|
| Experience؛ تجربه | آیا سازنده واقعاً این کار را انجام داده یا محصول را آزموده است؟ | روش، محیط، تصویر یا داده خام، محدودیت و نتیجه قابل تکرار | داستان مبهم و بدون زمان، جزئیات یا مدرک |
| Expertise؛ تخصص | آیا دانش لازم برای این ادعا وجود دارد؟ | تحصیلات یا سابقه مرتبط، استدلال درست، منبع اولیه و بازبین مناسب | عنوان شغلی پرطمطراق و نامرتبط |
| Authoritativeness؛ مرجعیت | آیا دیگران این فرد یا سازمان را در این موضوع میشناسند؟ | ارجاع مستقل و مرتبط، مشارکت حرفهای، آثار و سابقه قابل بررسی | لوگوی بدون اجازه یا نقلقول ساختگی |
| Trustworthiness؛ اعتماد | آیا میتوان به صفحه، سازنده و کسبوکار تکیه کرد؟ | ادعای دقیق، منبع، مالکیت روشن، تضاد منافع، امنیت و اصلاح خطا | HTTPS یا امتیاز Review بدون صحت محتوای اصلی |
این چهار جزء همیشه وزن یکسان ندارند. برای آموزش تعمیر یک دستگاه، تجربه دستاول ممکن است از مدرک دانشگاهی مهمتر باشد. برای تعیین دوز دارو، تخصص بالینی و منبع پزشکی معتبر حیاتی است. یک نویسنده میتواند تجربه واقعی داشته باشد اما نتیجهگیری نادرست کند؛ یا متخصص باشد اما وابستگی مالی خود را پنهان کند. در هر دو حالت اعتماد آسیب میبیند.
ابتدا هدف صفحه و سطح آسیب را مشخص کنید
کیفیت را نمیتوان جدا از Purpose سنجید. صفحه طنز، آموزش فنی، مقایسه بیمه و توصیه درمانی به یک سطح مدرک نیاز ندارند. پیش از تولید، یک جمله بنویسید: «این صفحه به چه کسی کمک میکند چه تصمیمی بگیرد؟» سپس بدترین پیامد یک اشتباه را برآورد کنید.
| سطح ریسک | نمونه | حداقل کنترل | مالک انتشار |
|---|---|---|---|
| کم | ایده دکور، سرگرمی، نظر شخصی کمخطر | ویرایش، اصالت و تفکیک نظر از واقعیت | نویسنده/ویراستار |
| متوسط | آموزش نرمافزار، نقد محصول، توصیه بازاریابی | نسخه و تاریخ، روش آزمون، شاهد تجربه، منبع و محدودیت | ویراستار موضوعی |
| زیاد | سلامت، سرمایهگذاری، حقوق، ایمنی، اطلاعات مدنی | منبع اولیه جاری، متخصص واجد صلاحیت، Fact-check و بازبینی دورهای | متخصص و مسئول تحریریه |
| بحرانی | دستور اقدام فوری پزشکی/امنیتی یا تصمیم مالی بزرگ | پروتکل رسمی، هشدار و Escalation، بازبینی پیش از انتشار و Change log | مسئول دارای اختیار و صلاحیت |
YMYL یک برچسب دودویی برای کل صنعت نیست. این مفهوم به موضوعاتی اشاره دارد که خطا در آنها میتواند بر سلامت، ثبات مالی، ایمنی افراد یا رفاه جامعه اثر چشمگیر بگذارد. حتی در یک سایت واحد، مقاله «تغییر رنگ دکمه» کمخطر است اما راهنمای «حذف لاگهای امنیتی بانک» میتواند پرخطر باشد. محتوای سئو نیز ذاتاً و یکسره YMYL نیست؛ توصیهای که سرمایه قابل توجه یک کسبوکار را در معرض خطر میگذارد به کنترل قویتری از تعریف ساده یک اصطلاح نیاز دارد. برای متن کامل معیارها، دستورالعمل رسمی ارزیابان کیفیت جستجو را ببینید.
مدل اجرایی: Claim ← Risk ← Evidence ← Review
بهجای آنکه پس از نوشتن متن چند «سیگنال اعتماد» تزئینی اضافه کنید، واحد کار را ادعا قرار دهید. هر ادعای مهم باید صاحب، سطح ریسک، نوع شاهد و تاریخ بازبینی داشته باشد.
- Claim: دقیقاً چه میگوییم؟ عدد، توصیه، مقایسه و حکم علّی را جدا کنید.
- Risk: اگر ادعا غلط یا قدیمی باشد، چه کسی و چقدر آسیب میبیند؟
- Evidence: کدام داده، تجربه یا منبع اولیه آن را پشتیبانی میکند؟
- Review: چه کسی با چه صلاحیتی آن را بررسی کرده است؟
- Accountability: مسئول اصلاح کیست و خواننده چگونه خطا را گزارش میکند؟
مثلاً گزاره «CDN همیشه رتبه را افزایش میدهد» هم مطلق و هم بدون شاهد است. نسخه قابل دفاع چنین است: «CDN ممکن است زمان تحویل را برای بخشی از کاربران کاهش دهد؛ اثر آن به Cache hit، مسیر شبکه، Origin و پیکربندی بستگی دارد. قبل و بعد، LCP و TTFB را برای کاربران هدف اندازه بگیرید.» در نسخه دوم، مرز ادعا، شرطها و روش آزمون روشن است.
Who، How و Why؛ سه سؤال قبل از انتشار
گوگل در خودارزیابی محتوای مفید پیشنهاد میکند «چه کسی، چگونه و چرا» را روشن کنیم. این سه سؤال یک قالب مناسب برای Brief و QA هستند، نه مجموعه کلمات کلیدی.
Who: چه کسی نوشته و چه کسی بازبینی کرده است؟
نام واقعی یا نام معتبر سازمان، نقش دقیق، حوزه تخصص مرتبط و لینک پروفایل باید قابل مشاهده باشد. اگر نویسنده پژوهشگر عمومی است و متخصص موضوع متن را بازبینی کرده، این دو نقش را جدا نشان دهید. عبارت «تأییدشده توسط تیم علمی» بدون نام، صلاحیت و دامنه بازبینی، پاسخگویی ایجاد نمیکند.
How: محتوا چگونه ساخته شده است؟
برای Review بنویسید چند محصول، در چه مدت و با چه معیارهایی آزموده شد. برای آموزش فنی، نسخه نرمافزار، سیستمعامل، داده آزمایشی و دستور تکرار را بدهید. برای پژوهش، نمونه، منبع داده، روش تحلیل و محدودیت را ثبت کنید. اگر اتوماسیون یا هوش مصنوعی نقش معناداری داشته و کاربر منطقی میپرسد «این چگونه ساخته شد؟»، روش استفاده و کنترل انسانی را توضیح دهید.
Why: چرا این صفحه وجود دارد؟
هدف باید حل مسئله مخاطب باشد، نه پرکردن یک Keyword gap به هر قیمت. صفحهای که پاسخ را عقب میاندازد، تعریفهای بدیهی را تکرار میکند یا برای رسیدن به تعداد کلمه دلخواه کش میآید، با نیت People-first همراستا نیست. پیش از سفارش محتوا، مشخص کنید چه تصمیمی بعد از خواندن آسانتر میشود و چه ارزش اصیلی اضافه میکنید.
ماتریس شواهد برای انواع محتوا
| نوع صفحه | شاهد تجربه/تخصص | شفافیت ضروری | خط قرمز |
|---|---|---|---|
| نقد محصول | عکس اصیل، سناریوی تست، نسخه، مدت استفاده، نتیجه و Trade-off | نمونه هدیه، افیلیت، معیار امتیازدهی | ادعای «تستشده» بدون دسترسی واقعی |
| آموزش فنی | محیط اجرا، کد/فرمان، خروجی، خطاها و راه بازگشت | نسخه، پیشنیاز، اثر جانبی و سطح دسترسی | دستور مخرب بدون Backup و هشدار |
| پزشکی/مالی/حقوقی | منبع رسمی جاری و بازبین واجد صلاحیت در همان حوزه | حوزه قضایی، تاریخ، محدودیت و زمان مراجعه به متخصص | تضمین نتیجه یا نسخه شخصیسازیشده بدون ارزیابی |
| خبر | منبع اولیه، گزارش میدانی یا سند | زمان انتشار/بهروزرسانی، اصلاحیه، نظر در برابر خبر | تیتر قطعی بر اساس شایعه |
| خدمت محلی در ایران | فرایند واقعی، نمونه کار قابل اجازه و شرایط خدمت | محدوده شهر، قیمت/مالیات با تاریخ، پشتیبانی و قرارداد | آدرس، مجوز یا نظر مشتری ساختگی |
| مطالعه موردی | Baseline، بازه، مداخله، داده و عوامل مزاحم | اجازه مشتری، داده حذفشده و محدودیت تعمیم | نسبتدادن همبستگی به علت |
پروفایل نویسنده باید چه چیزی را اثبات کند؟
صفحه نویسنده باید به کاربر کمک کند بفهمد چرا این شخص برای این موضوع مناسب است. یک الگوی حداقلی شامل نام، عکس واقعی در صورت رضایت، حوزههای پوشش، تجربه یا صلاحیت قابل بررسی، آثار منتخب، سیاست تضاد منافع، راه ارتباط حرفهای و تاریخ بازبینی پروفایل است. شماره مدرک یا عضویت را فقط وقتی منتشر کنید که قانونی، لازم و قابل راستیآزمایی باشد.
صلاحیت را به Scope محدود کنید. «پزشک» بودن بهتنهایی صلاحیت تحلیل همه تخصصهای پزشکی را نمیدهد؛ «توسعهدهنده» بودن نیز اثباتکننده تجربه امنیت، دسترسپذیری و زیرساخت نیست. اگر بخشی از محتوا خارج از حوزه نویسنده است، بازبین تخصصی یا منبع قویتر لازم میشود.
Reviewer تزئینی نباشد
بازبینی باید دامنه و اثر مشخص داشته باشد. کنار نام بازبین میتوان نوشت: «دقت ادعاهای حقوقی و منابع تا تاریخ X بررسی شد؛ توصیه محصول و نگارش نهایی متعلق به تحریریه است.» Reviewer باید بتواند تغییر بخواهد، انتشار را متوقف کند و پس از تغییر اساسی دوباره متن را ببیند.
| نقش | مسئولیت | شاهد ثبتشده |
|---|---|---|
| نویسنده | ادعا، استدلال، تجربه و منبع اولیه | Brief، یادداشت پژوهش و نسخه پیشنویس |
| Fact-checker | نامها، اعداد، تاریخها و ارتباط منبع با Claim | Claim ledger و لینک/نسخه منبع |
| بازبین تخصصی | صحت فنی و سطح خطر | کامنت و تأیید دامنهدار |
| ویراستار | نیت، وضوح، توازن و عدم اغراق | چکلیست انتشار |
| مالک محتوا | بهروزرسانی، اصلاح و حذف در زمان لازم | Review date، Change log و SLA |
منبعدهی خوب یعنی اتصال دقیق ادعا به شاهد
منبع را کنار همان ادعا قرار دهید، نه در فهرستی دور از متن. برای قانون ایران سراغ متن قانون، آییننامه یا نهاد رسمی بروید؛ برای قابلیت نرمافزار مستندات نسخه جاری؛ برای عدد بازار گزارش دارای روششناسی و Scope. مقالهای که گزارش دیگری را خلاصه کرده، معمولاً منبع اولیه نیست.
هنگام ارزیابی هر منبع این پنج مورد را ثبت کنید: ناشر و نویسنده، تاریخ و نسخه، روش تولید داده، دامنهای که واقعاً پوشش میدهد، و تضاد منافع. منبع قدیمی لزوماً بد نیست؛ اما نباید وضعیت امروز را بدون کنترل نسخه اثبات کند. برای صفحات حساس، یک Snapshot یا شناسه سند نگه دارید تا اگر URL تغییر کرد بتوان سابقه تصمیم را بازسازی کرد.
تجربه دستاول را جعل نکنید
تصویر Stock، مثال ساختگی یا جمله «در پروژههای متعدد دیدهایم» شاهد تجربه نیست. اگر تجربه واقعی ندارید، صادقانه نوع محتوا را «مرور مستندات»، «تحلیل داده عمومی» یا «مصاحبه با متخصص» بنامید. تجربه و تخصص جای هم را نمیگیرند: کاربری که ده سال با یک بیماری زندگی کرده، تجربه ارزشمندی دارد؛ تشخیص پزشکی همچنان به متخصص مناسب نیاز دارد.
برای آموزش فنی، یک Evidence box کوتاه مفید است: محیط تست، تاریخ، نسخهها، ورودی، نتیجه، شکستها و آنچه تعمیمپذیر نیست. برای مطالعه موردی، اعداد قبل و بعد بدون حجم نمونه، تغییرات همزمان و بازه اندازهگیری میتوانند گمراهکننده باشند.
Authoritativeness را نمیتوان سفارش داد
مرجعیت نتیجه شناختهشدن مرتبط در طول زمان است. لینک و اشاره مستقل، استناد دانشگاهی یا حرفهای، سخنرانی تخصصی، مشارکت در استاندارد یا ابزار و رضایت واقعی مشتری میتواند شاهد باشد؛ اما ارزش آن به ارتباط موضوعی و استقلال منبع بستگی دارد. انتشار رپورتاژ یا تبادل لوگو بهتنهایی شهرت معتبر نمیسازد.
یک خوشه موضوعی و مرجعیت محتوایی زمانی مفید است که پوشش منسجم و مرتبط، مالکیت تخصص و مسیر یادگیری بسازد؛ تولید انبوه صفحات همپوشان فقط برای اشغال SERP، اعتماد را افزایش نمیدهد.
اعتماد در سطح صفحه، نویسنده و سازمان
| سطح | نشانههای قابل مشاهده | کنترل عملی |
|---|---|---|
| صفحه | عنوان دقیق، تاریخ معنادار، منبع، روش، محدودیت و اصلاحیه | QA ادعا و Review schedule |
| نویسنده | نام، Scope تخصص، آثار، تضاد منافع و راه ارتباط | پروفایل واحد و بازبینی سالانه |
| سازمان | درباره ما، مالکیت، تماس، سیاست تحریریه و شکایت | مالک سیاست و SLA پاسخ |
| تراکنش | قیمت نهایی، شرایط لغو/مرجوعی، حریم خصوصی و امنیت | تست Checkout و تطابق قول با قرارداد |
| اکوسیستم | شهرت مستقل، ارجاع مرتبط و سابقه اصلاح | پایش Mention و پاسخ مستند، نه سرکوب نقد |
اگر طراحی صفحه کاربر را با شمارش معکوس جعلی، رضایت از پیش انتخابشده یا هزینه پنهان هل میدهد، بیوگرافی نویسنده جبرانش نمیکند. برای تشخیص این الگوها، راهنمای طراحی اخلاقی و Dark Pattern را ببینید.
سیاستهای سازمانی که باید قابل مشاهده باشند
- درباره ما: مالکیت، مأموریت، تیم واقعی و حوزه کاری؛
- سیاست تحریریه: انتخاب موضوع، منبع، بازبینی، AI و استقلال تجاری؛
- اصلاحات: راه گزارش خطا، زمان پاسخ و نحوه نمایش اصلاح مهم؛
- تبلیغات و افیلیت: تفکیک محتوا از تبلیغ و افشای رابطه مالی؛
- حریم خصوصی و امنیت: داده جمعآوریشده، هدف، نگهداری و حقوق کاربر؛
- فروش و خدمت: قیمت، شرایط، مرجوعی، لغو و پشتیبانی واقعی.
یک ایمیل عمومی در Footer کافی نیست. کانال گزارش خطای محتوایی باید به مالک مشخص برسد و رویداد قابل پیگیری بسازد. برای خطای پرخطر، SLA کوتاهتر و امکان Unpublish موقت لازم است.
تاریخ انتشار را بدون تغییر واقعی تازه نکنید
«بهروزرسانی شد» باید معنای قابل دفاع داشته باشد. اصلاح نگارشی، بازنگری منابع، تغییر توصیه و بازنویسی کامل را از هم جدا کنید. Change log کوتاه میتواند بنویسد: «مرداد ۱۴۰۵: تعریف YMYL اصلاح شد، منابع رسمی و گردش کار AI اضافه شد.» تغییر خودکار تاریخ همه صفحات برای نمایش تازگی، نه به کاربر کمک میکند و نه شاهد نگهداری محتواست.
داده ساختاریافته E‑E‑A‑T تولید نمیکند
Article Schema میتواند به موتور جستجو کمک کند نویسنده و مشخصات مقاله را بهتر بفهمد؛ اما واقعیتی را که در صفحه وجود ندارد ایجاد نمیکند. در مستند رسمی Article structured data، گوگل برای Author استفاده از نوع درست Person یا Organization و URL یا sameAs معتبر را توصیه میکند.
- همه نویسندگان قابل مشاهده را جداگانه در Markup بیاورید؛
author.nameفقط نام باشد، نه عنوان شغلی یا نام ناشر؛author.urlبه صفحهای یکتا و واقعی درباره همان نویسنده برسد؛datePublishedوdateModifiedبا صفحه و منطقه زمانی هماهنگ باشند؛- ناشر را در
publisherبگذارید و داده جعلی یا پنهان نسازید؛ - اعتبار Syntax را با Rich Results Test و انطباق محتوا را دستی کنترل کنید.
FAQ نیز باید برای کاربر روی صفحه دیده شود. حتی Markup معتبر نمایش Rich result را تضمین نمیکند. Schema لایه توصیف است، نه میانبری برای اعتبار.
هوش مصنوعی و E‑E‑A‑T؛ مسئله ابزار نیست، پاسخگویی است
گوگل استفاده مناسب از AI را ذاتاً خلاف راهنما نمیداند؛ مشکل، تولید انبوه کمارزش با هدف دستکاری رتبه است. راهنمای جاری گوگل درباره استفاده از محتوای مولد در وبسایت بر ارزش افزوده، اصالت و رعایت سیاستهای Spam تأکید میکند.
گردش کار امن را بر اساس ریسک بسازید:
- ورودی مدل را از داده شخصی، محرمانه و دارای حق نشر پاک کنید؛
- AI را برای ساختاردهی یا ایدهپردازی بهکار ببرید، نه جعل تجربه و منبع؛
- هر نام، عدد، نقلقول، URL و ادعای جاری را با منبع اصلی بررسی کنید؛
- نویسنده انسانی مسئول، ارزش اصیل و محدودیتها را اضافه کند؛
- در موضوع پرخطر، بازبین واجد صلاحیت خروجی نهایی را تأیید کند؛
- اگر کاربر منطقی انتظار توضیح «چگونه ساخته شد» دارد، نقش AI را شفاف کنید؛
- نسخه مدل، تاریخ و مراحل Review را داخلی ثبت کنید تا Incident قابل بررسی باشد.
AI را بهعنوان نویسنده پاسخگو معرفی نکنید. یک مدل نمیتواند تضاد منافع را اعلام، اصلاحیه را مالک یا در برابر پیامد توصیه پاسخگو باشد. راهنمای کاملتر را در گردش کار تحریریه برای محتوای AI بخوانید.
Review محصول و محتوای افیلیت
اگر محصول را در اختیار نداشتهاید، از فعل «آزمایش کردیم» استفاده نکنید. نوع دسترسی، مدت تست، نسخه یا مدل، شرایط شبکه و معیار امتیازدهی را بنویسید. مزیت باید همراه Trade-off و جایگزین مناسب باشد. در ایران، تفاوت گارانتی، رجیستری، قیمت متغیر، موجودی و محدودیت پرداخت میتواند نتیجه Review خارجی را تغییر دهد.
لینک افیلیت را نزدیک تصمیم خرید افشا کنید؛ یک صفحه حقوقی دور از دید کافی نیست. پرداخت فروشنده نباید اجازه حذف عیب، تغییر امتیاز یا پیشنمایش نتیجه را بدهد. اگر نمونه رایگان بوده، این رابطه را شفاف کنید؛ رایگانبودن بهخودیخود نتیجه را باطل نمیکند، پنهانکردنش اعتماد را مخدوش میکند.
محتوای YMYL به کنترل متناسب نیاز دارد
برای ادعای سلامت، مالی، حقوقی، ایمنی یا مدنی، «این مطلب جایگزین نظر متخصص نیست» مفید است اما خطای محتوایی را خنثی نمیکند. منبع باید جاری و مناسب حوزه قضایی باشد؛ بازبین باید دقیقاً برای موضوع صلاحیت داشته باشد؛ و صفحه باید بگوید چه زمانی کاربر اقدام را متوقف و به مرجع یا متخصص مراجعه کند.
| کنترل YMYL | سؤال پذیرش | شاهد |
|---|---|---|
| Scope | آیا کشور، جمعیت و شرایط استثنا روشن است؟ | یادداشت دامنه کنار توصیه |
| صلاحیت | آیا تخصص بازبین با Claim حساس همپوشانی دارد؟ | پروفایل و دامنه Review |
| منبع | آیا سند اولیه، جاری و واقعاً مؤید ادعاست؟ | Claim ledger با تاریخ دسترسی |
| ایمنی | آیا استثنا، خطر و Escalation توضیح داده شده؟ | هشدار نزدیک اقدام |
| نگهداری | آیا تغییر قانون/راهنما صفحه را Trigger میکند؟ | Alert و Review owner |
بومیسازی برای کاربر ایرانی، ترجمه کلمهبهکلمه نیست
منبع خارجی ممکن است درباره قانون، قیمت، دسترسی، پرداخت یا استانداردی حرف بزند که در ایران قابل تعمیم نیست. واحد پول را دقیق بنویسید و تومان را با ریال مخلوط نکنید؛ تاریخ شمسی و میلادی را در ادعای زمانحساس مشخص کنید؛ و اگر داده ملی ندارید، محدودیت را اعلام کنید.
برای قوانین و خدمات عمومی از مرجع رسمی ایرانی استفاده کنید و شماره/تاریخ مصوبه را ثبت کنید. دسترسی ناپایدار، تحریم سرویس، CDN و مسیر شبکه، درگاه پرداخت، گارانتی و پشتیبانی فارسی میتوانند معیار انتخاب را تغییر دهند. مثال بومی باید واقعی و قابل دفاع باشد، نه اینکه صرفاً نام تهران یا تومان به متن ترجمهشده اضافه شود.
سئو داخلی لازم است، اما جای کیفیت را نمیگیرد
عنوان روشن، پاسخ سریع، ساختار H2/H3، لینک داخلی و توضیحات متا به کشف و استفاده بهتر کمک میکنند. این موارد را با چکلیست سئو داخلی کنترل کنید؛ اما تکرار عبارت «E‑E‑A‑T چیست» یا طول بیشتر، اعتبار ایجاد نمیکند. اگر دو صفحه یک نیت دارند، ادغام یا مرزبندی آنها از تولید نسخه سوم بهتر است.
لینک داخلی باید رابطه واقعی بسازد: تعریف به راهنمای عمیقتر، ادعا به روش، و تصمیم به اقدام. برای بررسی Cannibalization، Indexability و سلامت کل سایت از چکلیست ممیزی سئو استفاده کنید. در جستجوی کلاسیک و تجربههای AI نیز محتوای منحصربهفرد و قابل استناد ارزشمندتر از بازنویسی کالایی است؛ جزئیات در راهنمای سئو برای جستجوی مبتنی بر هوش مصنوعی آمده است.
امتیازدهی داخلی؛ ابزار مدیریت، نه «نمره گوگل»
تیم میتواند برای کنترل عملیات Scorecard بسازد، به شرط آنکه آن را امتیاز گوگل ننامد. هر معیار را ۰، ۱ یا ۲ بدهید: صفر یعنی غایب؛ یک یعنی ناقص؛ دو یعنی کامل و قابل راستیآزمایی.
| معیار | ۰ | ۱ | ۲ |
|---|---|---|---|
| هدف و نیت | نامشخص | تعریف شده اما پاسخ دیرهنگام | کاربر، تصمیم و پاسخ سریع روشن |
| مالکیت | بینام | نام بدون Scope | نویسنده/بازبین مرتبط و پروفایل معتبر |
| شواهد | بدون منبع | منابع عمومی یا دور از Claim | اولیه، دقیق، جاری و کنار ادعا |
| تجربه/روش | ادعای مبهم | روش ناقص | محیط، فرایند، داده و محدودیت |
| تضاد منافع | پنهان | افشای دور از تصمیم | شفاف و نزدیک توصیه |
| نگهداری | بدون مالک | تاریخ مرور ثابت | Trigger، SLA، Change log و اصلاح |
| ایمنی | ریسک نادیده | Disclaimer عمومی | Scope، استثنا و Escalation متناسب |
| سازمان | هویت مبهم | صفحات سیاست ناقص | مالکیت، تماس و سیاستهای قابل اجرا |
برای صفحه پرریسک، میانگین بالا نباید «شواهد صفر» را جبران کند. Gate بگذارید: نبود منبع اولیه یا بازبین مناسب، مانع انتشار است. آستانهها را پس از چند دوره با خطاهای واقعی و بازخورد کاربران تنظیم کنید.
شاخصهایی که واقعاً میتوان پایش کرد
- درصد صفحات دارای نویسنده، بازبین و Scope روشن؛
- درصد ادعاهای پرخطر متصل به منبع اولیه و جاری؛
- نرخ لینک منبع خراب یا سند منقضی؛
- تعداد و زمان رفع اصلاحیهها، تفکیکشده بر شدت؛
- درصد صفحات عبورکرده از موعد Review؛
- پوشش افشای تبلیغ، افیلیت و استفاده معنادار از AI؛
- بازخورد «این بخش به تصمیم من کمک کرد/نکرد» همراه دلیل؛
- تعداد Citation و Mention مستقل مرتبط، با بررسی کیفی.
Bounce rate یا زمان حضور بهتنهایی شاخص اعتماد نیست: کاربر ممکن است پاسخ کوتاه را سریع بگیرد یا صفحه ضعیف را باز نگه دارد. داده رفتاری را با نوع نیت، Scroll، تکمیل وظیفه و بازخورد کیفی تفسیر کنید.
ممیزی E‑E‑A‑T در هفت گام
- Inventory: URL، نیت، موضوع، ترافیک، درآمد، نویسنده، آخرین Review و سطح خطر را فهرست کنید.
- Prioritize: صفحات پرخطر، پرترافیک، درآمدزا و دارای افت/شکایت را جلو بیندازید.
- Claim audit: اعداد، توصیهها، Superlativeها و ادعاهای زمانحساس را استخراج کنید.
- Evidence audit: ارتباط، اصالت، تاریخ و Scope هر منبع یا تجربه را بسنجید.
- Entity audit: نویسنده، بازبین، ناشر، About، Contact و سیاستها را تطبیق دهید.
- Page audit: پاسخ، عنوان، UX، تبلیغ، تاریخ، Schema و لینکها را کنترل کنید.
- Action: Keep، Update، Merge، Redirect، Noindex یا Remove را با مالک و موعد ثبت کنید.
در حذف یا ادغام محتوا، اثر لینکهای ورودی و نیاز کاربر را بررسی کنید. صفحه مفید قدیمی را صرفاً برای «تازه نشان دادن سایت» حذف نکنید. اگر ادعا قابل نجات نیست یا خطر فوری دارد، موقتاً از انتشار خارجکردن میتواند از انتظار برای بازنویسی کامل امنتر باشد.
برنامه ۳۰ روزه برای تحریریه کوچک
| بازه | کار | خروجی قابل تحویل |
|---|---|---|
| روز ۱ تا ۵ | تعریف Risk tier، نقشها و Gate | سیاست یکصفحهای و RACI |
| روز ۶ تا ۱۰ | ساخت Inventory و انتخاب ۲۰ صفحه اول | Backlog اولویتدار با Owner |
| روز ۱۱ تا ۱۵ | ساخت Author/Reviewer profile و Claim ledger | قالبها و سه نمونه تکمیلشده |
| روز ۱۶ تا ۲۲ | بازنویسی و بازبینی پنج صفحه پرخطر | نسخه جدید، Change log و شواهد |
| روز ۲۳ تا ۲۶ | اصلاح About، Editorial، Correction و Disclosure | سیاستهای عمومی با مسئول پاسخ |
| روز ۲۷ تا ۳۰ | QA فنی، Baseline و Retro | Dashboard اولیه و برنامه ۹۰روزه |
اشتباههای رایج که باید متوقف شوند
- خرید «بسته E‑E‑A‑T» شامل چند لینک و پروفایل جعلی؛
- معرفی هر موضوع سئو یا تجارت الکترونیک بهعنوان YMYL قطعی؛
- استفاده از مدرک نامرتبط برای مشروعکردن ادعای تخصصی؛
- قرار دادن Reviewer بدون دامنه Review یا اختیار اصلاح؛
- ساخت Review، نقلقول، تجربه و عکس مصنوعی بدون افشا؛
- ارجاع به صفحه اصلی یک سازمان بهجای سند مؤید ادعا؛
- تغییر تاریخ بدون تغییر معنادار محتوا؛
- فرض اینکه HTTPS، Schema یا سرعت خوب، صحت ادعا را ثابت میکند؛
- محاسبه نمره داخلی و معرفی آن بهعنوان امتیاز گوگل؛
- انتظار رشد تضمینی رتبه یا تعیین زمان ثابت برای نتیجه.
چکلیست نهایی قبل از انتشار
- هدف، مخاطب، تصمیم و سطح آسیب صفحه ثبت شده است.
- پاسخ اصلی زود و بدون اغراق ارائه میشود.
- نویسنده و بازبین با Scope مرتبط و صفحه پروفایل مشخصاند.
- ادعاهای عددی، علّی، مقایسهای و زمانحساس شاهد مناسب دارند.
- تجربه واقعی از تحلیل منابع و نظر شخصی تفکیک شده است.
- روش، نسخه، تاریخ، محدودیت و عوامل مزاحم بیان شدهاند.
- تبلیغ، نمونه رایگان، افیلیت و تضاد منافع نزدیک تصمیم افشا شدهاند.
- برای YMYL، منبع اولیه، Reviewer واجد صلاحیت و Escalation وجود دارد.
- نقش معنادار AI و کنترل انسانی در جای لازم توضیح داده شده است.
- عنوان، تاریخ، Schema، نویسنده و ناشر با محتوای قابل مشاهده منطبقاند.
- راه گزارش خطا، مالک اصلاح و موعد Review وجود دارد.
- لینکهای داخلی و خارجی مستقیم، سالم و مرتبطاند.
جمعبندی؛ E‑E‑A‑T خروجی سیستم اعتماد است
E‑E‑A‑T را نمیتوان با یک Author box، Schema یا تعداد مشخص منبع «اضافه» کرد. نتیجه پایدار زمانی ساخته میشود که هر صفحه هدف روشن، ادعای محدود، تجربه یا تخصص مرتبط، شاهد دقیق، بازبینی متناسب و مسئول اصلاح داشته باشد. برای سایت ایرانی، این یعنی منبع و قانون بومی، واحد پول و تاریخ دقیق، بیان محدودیت دسترسی و پرهیز از ترجمه کور نمونههای خارجی.
از صفحات پرخطر و پراثر شروع کنید، نه از سادهترین صفحات. یک Claim ledger کوچک و فرایند اصلاح واقعی از دهها Badge اعتماد ارزشمندتر است. اگر برای طراحی Risk tier، ممیزی محتوا یا تبدیل این مدل به گردش کار تیم نیاز به همراهی دارید، درخواست مشاوره Mindio را ثبت کنید.
سؤالات متداول E‑E‑A‑T
آیا E‑E‑A‑T فاکتور مستقیم رتبهبندی گوگل است؟
خیر. طبق توضیح رسمی گوگل، خود E‑E‑A‑T یک فاکتور مشخص رتبهبندی نیست. سامانههای گوگل از ترکیبی از عوامل برای شناسایی محتوایی استفاده میکنند که جنبههای تجربه، تخصص، مرجعیت و اعتماد را نشان میدهد. هیچ نمره عمومی E‑E‑A‑T در Search Console وجود ندارد.
آیا افزودن بیوگرافی نویسنده رتبه را بهتر میکند؟
هیچ تضمینی وجود ندارد. معرفی دقیق نویسنده به کاربر و موتور جستجو در فهم مسئول محتوا کمک میکند، اما بیوگرافی نمیتواند ادعای غلط، منبع ضعیف یا تجربه جعلی را جبران کند. ارتباط صلاحیت نویسنده با موضوع و شواهد خود صفحه مهم است.
آیا E‑E‑A‑T فقط برای موضوعات YMYL مهم است؟
خیر؛ اعتماد و محتوای مفید برای همه صفحات ارزش دارد. بااینحال گوگل برای موضوعاتی که میتواند اثر چشمگیری بر سلامت، ثبات مالی، ایمنی یا رفاه جامعه بگذارد، بر سیگنالهای همراستا با E‑E‑A‑T تأکید بیشتری دارد. سطح کنترل باید با ریسک همان صفحه متناسب باشد.
آیا محتوای تولیدشده با هوش مصنوعی E‑E‑A‑T را خراب میکند؟
صرف استفاده از AI معیار رد یا قبول نیست. تولید انبوه کمارزش برای دستکاری رتبه میتواند خلاف سیاستهای Spam باشد. محتوا باید اصیل، مفید، راستیآزماییشده و دارای مسئول انسانی باشد؛ نقش AI را جایی توضیح دهید که کاربر منطقی انتظار دانستن روش تولید را دارد.
بهبود E‑E‑A‑T چقدر زمان میبرد؟
زمان ثابت و تضمینشدهای وجود ندارد، چون «امتیاز E‑E‑A‑T» یا آزمون قبولی واحدی وجود ندارد. اصلاح ادعا و منبع میتواند فوری انجام شود؛ ساخت شهرت مستقل و سابقه اعتماد زمانبر است. پیشرفت را با پوشش منبع، زمان اصلاح، تازگی Review و بازخورد کاربر بسنجید، نه وعده رتبه در تعداد روز مشخص.






