ابزارهای رایگان سئو؛ از داده تا اقدام

اگر ابزار را پیش از سؤال انتخاب کنید، خیلی زود یک پوشه پر از Export و یک داشبورد سبز خواهید داشت—بی‌آنکه بدانید کدام صفحه را چرا باید تغییر دهید. ابزارهای رایگان سئو زمانی ارزش دارند که یک ابهام را کم کنند: آیا Google صفحه را دیده است؟ افت Click از Demand است یا از Index؟ مشکل سرعت در آزمایشگاه دیده می‌شود یا واقعاً به کاربران ایرانی می‌رسد؟ و آیا ترافیک Organic به Lead یا سفارش قابل‌قبول تبدیل شده است؟

این راهنما یک «لیست صدابردار» از نام ابزارها نیست. یک پشته کم‌هزینه و قابل‌ممیزی می‌سازد که در آن Search Console، GA4، Trends، PageSpeed Insights، Lighthouse، Screaming Frog، Rich Results Test، Schema Markup Validator و Ahrefs Free هرکدام کار مشخص، محدودیت مشخص و خروجی تصمیم‌پذیر دارند. قابلیت و سقف نسخه رایگان ممکن است تغییر کند؛ بنابراین تاریخ بررسی، مالک داده و محدودیت هر ابزار باید کنار نتیجه ثبت شود.

پاسخ کوتاه: پشته رایگان پیشنهادی چیست؟

برای سایت کوچک، همین پشته می‌تواند بیشتر سؤال‌های روزمره را پوشش دهد. اگر هنوز Baseline، مالک اقدام و Definition of Done ندارید، خرید ابزار بزرگ‌تر معمولاً فقط حجم Issueها را زیاد می‌کند. ابتدا با ممیزی سئو و Backlog اولویت‌دار مسئله‌ها را صورت‌بندی کنید؛ سپس ابزار را برای تولید Evidence همان مسئله به کار ببرید.

«رایگان» دقیقاً یعنی چه؟

صفر بودن مبلغ اشتراک با صفر بودن هزینه کل یکی نیست. Crawl به CPU و زمان، Analytics به پیاده‌سازی و Consent، Dashboard به نگهداری، Extension به سطح دسترسی و هر Export به تحلیل انسانی نیاز دارد. هزینه مهاجرت، خطای تصمیم و افشای داده نیز جزو TCO است.

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

قبل از ابزار، سؤال و واحد تصمیم را تعریف کنید

«سئو سایت را بررسی کن» سؤال قابل اجرا نیست. آن را به عبارت قابل آزمون تبدیل کنید: «آیا افت Click غیر‌برند موبایل ایران در سه Template دسته‌بندی، پس از Release پنجشنبه، از افت Impression آمده یا CTR؟» اکنون Dimension، بازه، Baseline و شاهد لازم روشن‌اند.

هر ابزار چه نوع شاهدی تولید می‌کند؟

عددها فقط به‌خاطر دقیق بودن ظاهری برابر نیستند. «Click ثبت‌شده در Google Search»، «Session اندازه‌گیری‌شده با JavaScript»، «URL کشف‌شده توسط Crawler» و «Traffic تخمینی رقیب» چهار واقعیت متفاوت‌اند.

قانون ساده: برای تصمیم پرریسک دست‌کم دو کلاس شاهد مستقل بخواهید. یک Crawler می‌تواند Canonical را در HTML ببیند، اما انتخاب Canonical توسط Google را URL Inspection نشان می‌دهد؛ Backend نیز نشان می‌دهد آیا Landingهای Organic واقعاً Lead قابل فروش ساخته‌اند.

Search Console: خط پایه دیدن Search، نه نسخه کامل واقعیت

Google Search Console برای Property تأییدشده معمولاً نخستین ابزار است: Performance برای Click/Impression/CTR/Position، Page Indexing برای وضعیت مجموعه URLها، URL Inspection برای یک URL، Sitemaps، Core Web Vitals و Links. این داده درباره Google Search و Property شماست؛ Rank tracker همه موتورهای جست‌وجو، Crawler کامل یا Analytics رفتار داخل سایت نیست.

Performance را چگونه بخوانیم؟

• Query، Page، Country، Device، Search appearance و Date را جداگانه بررسی کنید؛ میانگین کل می‌تواند تغییر Segment را پنهان کند.
• Click/Impression/CTR/Position را هم‌زمان ببینید. افت Click با Impression ثابت مسئله‌ای متفاوت از افت هم‌زمان Demand است.
• برند و غیر‌برند را با تعریف ثبت‌شده جدا کنید؛ Classification خودکار هم بی‌خطا نیست.
• روند را با تقویم Release، Migration، تعطیلات، فصل و Incident حاشیه‌نویسی کنید.

Search Console همه Queryها و همه Rowها را نشان نمی‌دهد؛ Queryهای کم‌حجم یا حساس ممکن است برای Privacy حذف شوند، Table به داده‌های مهم‌تر محدود است، داده معمولاً Lag دارد و روزها بر مبنای زمان California ثبت می‌شوند. همچنین Performance عمدتاً به Canonical نسبت داده می‌شود. بنابراین اختلاف با GA4 یا Log به‌تنهایی «خرابی Tracking» نیست.

Page Indexing و URL Inspection را خلط نکنید

Page Indexing نمای الگو و Reason را می‌دهد؛ فهرست نمونه‌ها همه URLهای شناخته‌شده نیست. URL Inspection وضعیت URL منفرد و اطلاعات نسخه Index‌شده یا Live test را می‌دهد. «URL is on Google» نیز تضمین Rank یا Traffic نیست. برای تشخیص مرحله‌ای، از راهنمای عیب‌یابی ایندکس استفاده کنید و Reason را به Discovery، Crawl، Render، Index یا Serving نگاشت دهید.

Workflow هفت‌مرحله‌ای GSC

GA4: آنچه بعد از Click رخ می‌دهد

GA4 جای Search Console را نمی‌گیرد. GSC Click از Search را در Scope خودش ثبت می‌کند؛ GA4 پس از Load و اجرای Measurement، User/Session/Event را می‌بیند. Consent، Ad blocker، JavaScript، Redirect، Cross-domain، UTM، Channel rule و Timezone می‌توانند اختلاف بسازند.

برای تحلیل Organic، «First user source/medium» را با «Session source/medium» یکی نگیرید: اولی Acquisition کاربر جدید و دومی Acquisition Session را پاسخ می‌دهد. Landing page، Device، Country و Content group را به Eventهای واقعی مانند generate_lead، purchase یا Result سرویس متصل کنید؛ Scroll و Engagement به‌تنهایی موفقیت کسب‌وکار نیستند.

برای معماری Event، Identity، Consent، Warehouse و Reconciliation به راهنمای تحلیل داده بازاریابی رجوع کنید. اگر ابزار Analytics از نظر قرارداد، دسترسی منطقه‌ای یا Privacy مناسب سازمان نیست، گزینه مالکیت‌پذیر دیگری انتخاب کنید؛ دورزدن محدودیت محصول راهکار Measurement نیست.

تحقیق کلمه کلیدی رایگان: یک عدد جادویی وجود ندارد

ابزار تحقیق باید سه سؤال متفاوت را جدا کند: مردم چه زبانی به کار می‌برند؟ تقاضا چه Pattern زمانی/مکانی دارد؟ سایت شما اکنون برای چه Queryهایی Impression می‌گیرد؟ GSC برای تقاضای فعلی Property، Trends برای علاقه نسبی و داده فروش/پشتیبانی برای Job واقعی مکمل یکدیگرند.

Google Trends را به‌عنوان حجم جست‌وجوی مطلق نخوانید

Trends نمونه‌ای Aggregated و ناشناس از Search است که بر زمان و مکان Normalized و سپس روی مقیاس ۰ تا ۱۰۰ Scale می‌شود. عدد ۱۰۰ یعنی نقطه اوج نسبی در مجموعه انتخاب‌شده، نه ۱۰۰ جست‌وجو. Query کم‌حجم ممکن است صفر یا Noise داشته باشد. Term با Topic، Persian با Finglish، بازه کوتاه با بلند و Iran با Worldwide نتیجه‌های متفاوت می‌سازند.

• برای واژه فارسی، شکل با/بدون نیم‌فاصله و Finglish را جدا آزمایش کنید.
• حداکثر پنج گروه را با Anchor نسبتاً پایدار مقایسه و Context انتخاب را ثبت کنید.
• Rising topic را با Sales/Support/GSC تأیید کنید؛ Spike لزوماً بازار پایدار نیست.
• بازه‌های کمتر از هفت روز و بیشتر از ۳۰ روز می‌توانند Timezone متفاوتی داشته باشند؛ Export و Timestamp را نگه دارید.

Keyword Planner برای کسب‌وکار ایرانی ابزار پایه نیست

Keyword Planner ابزار Google Ads برای طراحی Search campaign است و مستند جاری برای دسترسی پایه، تکمیل Account setup و Billing information را لازم می‌داند. هم‌زمان Google Ads رسماً برای Advertiser مستقر در ایران در دسترس نیست. پس این مقاله ساخت حساب، جعل مکان یا دورزدن محدودیت را توصیه نمی‌کند. اگر سازمان شما مستقلاً و قانوناً واجد شرایط است، داده آن را Estimate تبلیغاتی با Location/Network/Date مشخص بدانید؛ در غیر این صورت از GSC، Trends، Search suggestion با احتیاط، داده مشتری و تحقیق کیفی استفاده کنید.

Autocomplete و People also search را چگونه استفاده کنیم؟

آن‌ها برای کشف زبان و سؤال مفیدند، اما Sampling علمی یا تضمین Volume نیستند و با مکان، زبان، تاریخ و Policy تغییر می‌کنند. Queryها را به Intent/Job/Entity/Stage خوشه‌بندی کنید، نه اینکه هر Suggestion را یک صفحه تازه بسازید. برای هر Cluster یک Owner URL تعیین و پذیرش صفحه را با چک‌لیست سئو داخلی کنترل کنید.

Screaming Frog رایگان: Snapshot فنی، نه شبیه‌ساز کامل Google

SEO Spider برای دیدن Graph لینک داخلی، Status، Redirect، Canonical، Title، Meta، H1/H2، Pagination، hreflang و فایل‌های قابل کشف مفید است. نسخه رایگان جاری سقف ۵۰۰ URL در هر Crawl دارد و برخی Configurationها، ذخیره Crawl و قابلیت‌های پیشرفته محدودند. این سقف «۵۰۰ صفحه مهم» نیست؛ Image، Redirect، Parameter یا Resource نیز بسته به تنظیم و نسخه می‌تواند Budget Crawl را مصرف کند.

برای سایت بزرگ‌تر از ۵۰۰ URL چه کنیم؟

Seed، User-agent، robots behavior، Crawl time، Version و Scope را همراه Export ثبت کنید. Crawl خودتان فقط URLهایی را می‌بیند که از نقطه شروع و Configuration کشف می‌شوند؛ Google ممکن است URL را از Sitemap، Redirect، External link یا تاریخچه بشناسد. فهرست CMS، Sitemap، GSC، Log و Crawl را به‌صورت Set مقایسه کنید.

چه یافته‌ای Actionable است؟

«۳۰۰ Title کوتاه» Issue نیست تا وقتی Query، Template و Outcome روشن نشده باشد. در مقابل، Canonical تمام Productها به Category، زنجیره Redirect در Navigation یا لینک داخلی به URL پارامتری می‌تواند Mechanism مشخص داشته باشد. هر Rule باید شامل Evidence URL، Impact scope، Confidence، Owner، Fix، Acceptance test و Rollback باشد.

Crawler را با نرخ معقول روی دارایی تحت مالکیت یا با مجوز اجرا کنید. اسکن سنگین سایت رقیب یا Endpoint حساس می‌تواند بار و ریسک حقوقی/عملیاتی بسازد. برای Crawl policy، Facet و تفاوت Disallow با Index از راهنمای robots.txt استفاده کنید.

HTTP و HTML را با ابزارهای ساده ببینید

بسیاری از خطاها پیش از داشبورد با Header و Source روشن می‌شوند. مرورگر، DevTools و ابزار خط فرمان قابل اعتمادند—به شرط آنکه Request و Response ثبت شود.

Redirect را با حالت بدون Follow آزمایش کنید تا Hop پنهان نشود. Canonical را هم در Source، هم Rendered DOM، هم Header و هم URL Inspection مقایسه کنید. Screenshot بدون URL، زمان، Viewport و State شاهد قابل بازتولید نیست.

PageSpeed Insights، CrUX و Lighthouse: Field را از Lab جدا کنید

PageSpeed Insights دو خانواده داده دارد: Field data از Chrome UX Report برای تجربه واقعی واجد شرایط در پنجره ۲۸روزه، و Lab data از اجرای Lighthouse در محیط شبیه‌سازی‌شده. Field برای «کاربران واقعاً چه دیدند» و Lab برای «کدام Mechanism را می‌توان بازتولید کرد» مناسب است. نمره Performance همان Core Web Vitals واقعی نیست.

اگر URL کم‌ترافیک Field data ندارد، آن را «سریع» فرض نکنید؛ Origin/Template، Lab کنترل‌شده و RUM را ترکیب کنید. چند اجرای Lab با Median، Version، Location، Cache state و Device ثبت کنید. تغییر Score بدون تغییر Metric/Outcome کافی نیست. برای ساخت Baseline و اتصال Performance به کسب‌وکار، راهنمای سرعت سایت و Core Web Vitals را ببینید.

Mobile-Friendly Test دیگر ابزار جاری نیست

Google در ۱ دسامبر ۲۰۲۳ Mobile-Friendly Test و گزارش Mobile Usability را بازنشسته کرد. پس لینک یا Screenshot قدیمی آن نباید در Runbook بماند. جایگزین یک دکمه واحد نیست: Lighthouse accessibility/best-practices، DevTools Device Mode، تست Keyboard/Zoom/Reflow، دستگاه واقعی و آزمون Taskمحور را کنار هم بگذارید. Responsive بودن Screenshot، دسترس‌پذیری یا موفقیت Journey را تضمین نمی‌کند.

Lighthouse: Rule detector، نه گواهی کیفیت

Lighthouse ابزار Open-source و خودکار Chrome برای Performance، Accessibility، Best Practices و SEO است و از DevTools، Command line یا Node قابل اجراست. مزیت آن Repeatability و امکان CI است؛ محدودیت آن نیز همین Rule set و Environment است.

• SEO score همه Requirements جست‌وجو یا کیفیت محتوا را پوشش نمی‌دهد.
• Accessibility score فقط بخشی از WCAG را خودکار می‌سنجد؛ Keyboard، Screen reader، زبان و محتوای فارسی نیازمند تست انسانی‌اند.
• Performance run نوسان دارد؛ یک Run سبز Acceptance پایدار نیست.
• صفحه Authenticated را می‌توان محلی آزمود، اما داده حساس نباید در Report عمومی یا سرویس ثالث آپلود شود.

Ruleهای بحرانی را به Lighthouse CI و Release gate تبدیل کنید، اما Budgetها را بر Baseline خودتان تنظیم کنید. Fail باید Owner، لینک Evidence و سیاست Exception داشته باشد؛ وگرنه تیم خیلی زود Gate را خاموش می‌کند.

Rich Results Test و Schema Markup Validator یک کار نمی‌کنند

Rich Results Test می‌پرسد Markup صفحه برای کدام Rich resultهای پشتیبانی‌شده Google واجد شرایط است و چه Error/Warningی دارد. Schema Markup Validator Syntax و Vocabulary عمومی Schema.org را می‌سنجد، نه Eligibility ویژگی Google. Valid بودن نیز نمایش Rich result یا Rank را تضمین نمی‌کند.

Markup تولیدشده توسط Plugin را کورکورانه معتبر فرض نکنید. Page/Schema/Feed/Backend باید در Price، Availability، Author، Date و Identity هم‌راستا باشند. Workflow کامل را در راهنمای اسکیما و JSON-LD اجرا کنید.

ابزارهای رایگان Backlink: برای کشف، نه حکم قطعی

گزارش Links در Search Console، Indexهای Ahrefs/Moz و Referralهای Analytics هرکدام Coverage متفاوتی دارند. نبود Link در یک ابزار به معنی نبود آن در Web یا نادیده‌گرفتن آن توسط Google نیست. DR، DA، UR و PA معیار اختصاصی شرکت‌ها هستند؛ Google score رسمی یا هدف کسب‌وکار نیستند.

Ahrefs Free در نسخه جاری برای سایت‌های تأییدشده، Site Audit، Site Explorer و Web Analytics با سقف‌های مشخص ارائه می‌کند؛ ابزارهای مستقل آن برای هر دامنه محدودترند. Verify کردن Property، دسترسی دادن به GSC یا نصب Script تصمیم Privacy/Access است، نه فقط کلیک روی Sign up. Plan و سقف را در تاریخ استفاده از صفحه رسمی بخوانید.

Backlink را با چه سؤال‌هایی ارزیابی کنیم؟

• Source page واقعی، Indexable و مرتبط است یا صفحه ساخته‌شده برای Link؟
• Link در Main content است یا Footer/Widget/UGC/Ad؟
• rel و Disclosure با رابطه تجاری هم‌خوان است؟
• Referral واجد شرایط یا Brand discovery ساخته است؟
• الگوی Anchor/Domain در زمان طبیعی است یا نشانه Manipulation؟
• Risk اقدام بیشتر است یا رها کردن؟ Disavow ابزار روتین پاک‌سازی هر Link ضعیف نیست.

برای مقایسه رقیب، یک Metric را رتبه‌بندی نکنید؛ Competitor را در سطح Query cluster انتخاب و Content/Link/Technical/Brand evidence را کنار هم ببینید. چارچوب تحلیل رقبا در سئو این داده‌های تخمینی را به Backlog قابل دفاع تبدیل می‌کند.

Browser Extension رایگان: راحتی در برابر سطح دسترسی

Extension می‌تواند Title، Canonical، Heading، hreflang، Status و Link را سریع نشان دهد، اما برای کارکردن ممکن است اجازه خواندن و تغییر داده صفحات بازشده را بخواهد. روی Admin، CRM، بانک، ایمیل یا صفحه حاوی داده مشتری، این مجوز ریسک واقعی است.

برای کار حساس از Profile جدا، حداقل Extension و Permission محدود استفاده کنید. خروجی Extension را با Source/DevTools تأیید کنید؛ UI زیبا مالک حقیقت نیست.

ابزار را با Scorecard انتخاب کنید

وزن‌ها را بر ریسک خودتان تنظیم کنید. ابزار با Feature بیشتر ممکن است برای سؤال محدود امتیاز کمتری بگیرد. Threshold انتخاب، Reviewer و تاریخ بازبینی را ثبت کنید؛ Free plan و Availability بخشی از Configuration هستند.

رجیستری ابزار و قرارداد داده بسازید

وقتی یک عدد در جلسه تصمیم‌گیری نمایش داده می‌شود، باید بتوانید منشأ آن را بازسازی کنید. یک Sheet ساده از Dashboard بزرگ مفیدتر است اگر ستون‌های زیر را داشته باشد:

از Issue خام تا اقدام؛ Workflow قابل‌ممیزی

ابزار معمولاً Observation می‌سازد، نه Root cause. «Meta description missing» یا «LCP poor» باید از قیف زیر عبور کند:

1. Observe: خروجی خام با URL، Timestamp، Scope و Version ثبت شود.
2. Validate: با ابزار یا منبع دوم تأیید و False positive حذف شود.
3. Cluster: Issue در سطح Template/Folder/Component/Release گروه‌بندی شود.
4. Explain: Mechanism و Hypothesis نوشته شود؛ هم‌بستگی به‌جای علت ننشیند.
5. Prioritize: Impact، Scope، Confidence، Effort، Risk و Dependency سنجیده شود.
6. Assign: Owner، Due date، Acceptance و Rollback تعیین شود.
7. Change: Fix کوچک و قابل مشاهده روی Pilot یا Release کنترل‌شده اجرا شود.
8. Verify: Technical acceptance فوری و Outcome با Lag مناسب بررسی شود.
9. Learn: نتیجه، استثنا و Rule جدید در Runbook ثبت شود.

ضرب مکانیکی امتیازها می‌تواند دقت کاذب بسازد. یک noindex تصادفی روی صفحه درآمدی، با وجود Scope کوچک، Incident فوری است؛ در حالی که صدها Warning کم‌اثر ممکن است منتظر بمانند. Severity و Priority را جدا نگه دارید.

Evidence bundle حداقلی

• یک URL نمونه و یک URL کنترل؛
• زمان، Environment، Device/User-agent و Version؛
• Request/Response یا Export خام؛
• Screenshot فقط به‌عنوان مکمل؛
• Expected در برابر Actual؛
• Scope تخمینی و روش محاسبه؛
• Hypothesis و شواهد مخالف؛
• Owner، Fix، Acceptance test و Rollback.

Cadence را بر Signal تنظیم کنید، نه عادت

بررسی روزانه GA4 توسط انسان معمولاً Noise و واکنش عجولانه می‌سازد. Alert را بر Baseline، Seasonality، حداقل حجم و Severity تنظیم کنید. «افت ۲۰٪» بدون بازه، حجم و Segment قانون هشدار خوبی نیست.

ملاحظات ویژه برای سایت و تیم ایرانی

• Eligibility: دسترسی محصول و Terms را تاریخ‌دار بررسی کنید. Google Ads و در نتیجه اتکای عملی به Keyword Planner برای کسب‌وکار مستقر در ایران محدود است؛ دورزدن، حساب اجاره‌ای یا اطلاعات نادرست توصیه نمی‌شود.
• زبان: فارسی، عربی، Finglish، فاصله/نیم‌فاصله، شکل ی/ک، عدد فارسی/لاتین و غلط رایج را در Query normalization نگه دارید؛ Merge کور می‌تواند Intent را پاک کند.
• مکان و زمان: Country=Iran، شهر، تقویم شمسی/میلادی، تعطیلات و اختلاف ساعت Tehran/California/UTC را در تحلیل ثبت کنید.
• شبکه و دستگاه: Lab خارج از ایران نماینده Latency، DNS، CDN، ISP و گوشی کاربران شما نیست. RUM و تست Device/Network واقعی لازم است.
• دسترسی ناپایدار: Export دوره‌ای، مالک داخلی، Runbook آفلاین و جایگزین محلی داشته باشید؛ Dashboard خارجی تنها نسخه داده نباشد.
• Privacy: URL می‌تواند Query شخصی، شماره سفارش یا Token داشته باشد. آن را به ابزار عمومی، Extension یا Report اشتراکی نفرستید.
• واحد کسب‌وکار: تومان/ریال، Lead تکراری، تماس ناموفق، لغو و مرجوعی را در Backend تعریف کنید؛ GA4 به‌تنهایی کیفیت Outcome را نمی‌داند.

مثال فرضی: افت Lead ارگانیک یک سرویس تعمیرات

فرض کنید سامانه‌ای فارسی برای رزرو تعمیر پکیج در تهران و کرج، سه روز پس از تغییر Template صفحات محله، افت ۳۵درصدی Lead Organic می‌بیند. رویکرد نادرست این است که با یک SEO score پایین، ده‌ها تصویر را Compress کنیم. رویکرد قابل دفاع چنین است:

تیم ابتدا Component را روی Staging اصلاح، Unit/HTML test و Crawl نمونه را Pass می‌کند؛ سپس Deploy محدود، Cache purge و URL Inspection چند نمونه را انجام می‌دهد. Technical acceptance فوری است، اما بازگشت GSC/Lead با Lag و Baseline هم‌فصل بررسی می‌شود. این مثال نشان می‌دهد ابزار بیشتر لازم نبود؛ ترتیب Evidence درست لازم بود.

خطاهای رایج در استفاده از ابزارهای رایگان سئو

برنامه ۳۰/۶۰/۹۰روزه برای پشته رایگان

روز ۱ تا ۳۰: حقیقت و دسترسی

• Propertyها، Ownerها، Access و Recovery را ثبت کنید.
• تعریف Query cluster، Landing، Lead و Outcome را یکسان کنید.
• GSC، Analytics/Backend و Release calendar را Baseline بگیرید.
• ۲۰ URL بحرانی از همه Template/Stateها بسازید.
• Tool registry و Data contract اولیه را تکمیل کنید.

روز ۳۱ تا ۶۰: QA و Backlog

• Crawl طبقه‌بندی‌شده و تست HTTP/Render/Schema/Performance اجرا کنید.
• Issueها را Validate، Cluster و به Owner وصل کنید.
• سه Fix با Impact/Confidence بالا را Pilot کنید.
• Release checklist و Evidence bundle را استاندارد کنید.
• Alertهای کم‌Noise برای 5xx، robots و Template بحرانی بسازید.

روز ۶۱ تا ۹۰: سنجش و خودکارسازی

• Technical acceptance را از Outcome lag جدا گزارش کنید.
• Lighthouse/Schema/Metadata contract مناسب را وارد CI کنید.
• GSC/GA4/Backend reconciliation و Annotation را تکرارپذیر کنید.
• Toolهای بدون Owner، استفاده یا Exit plan را حذف کنید.
• نتایج Pilot را به Scale/Iterate/Stop تبدیل و Runbook را به‌روز کنید.

چک‌لیست کیفیت قبل از تصمیم

• سؤال و Decision بعدی یک جمله روشن دارند.
• Metric، Scope، Segment، Date، Timezone و Baseline ثبت شده‌اند.
• نوع داده First-party/Owned/Lab/Estimate مشخص است.
• Plan، Limit، Version و Freshness ابزار تاریخ‌دارند.
• Observation از Interpretation و Hypothesis جداست.
• حداقل یک شاهد مستقل یافته پرریسک را تأیید می‌کند.
• URL نمونه و کنترل و Evidence خام قابل بازتولیدند.
• Impact، Scope، Confidence، Effort، Risk و Dependency دیده شده‌اند.
• Owner، Deadline، Acceptance، Guardrail و Rollback وجود دارند.
• PII، Secret، Permission، Retention و Eligibility بررسی شده‌اند.
• اثر تا Outcome کسب‌وکار دنبال می‌شود، نه فقط Score.
• نتیجه و استثنا در Runbook و Tool registry ثبت می‌شوند.

پرسش‌های متداول ابزارهای رایگان سئو

بهترین ابزار رایگان سئو برای شروع چیست؟

برای سایت تأییدشده معمولاً Search Console بهترین نقطه شروعِ دید Search است، اما «بهترین» بدون سؤال معنا ندارد. برای رفتار پس از ورود Analytics/Backend، برای Diagnostic صفحه Lighthouse/DevTools و برای Crawl نمونه Screaming Frog مناسب‌ترند. ابتدا Decision را تعریف کنید.

آیا می‌توان فقط با ابزارهای رایگان سئو کرد؟

برای بسیاری از سایت‌های کوچک و متوسط، بله—اگر تیم بتواند Scope را محدود، داده را تفسیر و اقدام را اجرا کند. نقطه خرید زمانی است که Coverage، Automation، Collaboration یا زمان صرفه‌جویی‌شده از TCO اشتراک ارزشمندتر شود؛ ابزار پولی جای Strategy و QA را نمی‌گیرد.

آیا Keyword Planner برای کاربر داخل ایران قابل اتکاست؟

به‌عنوان ابزار پایه نه. مستند جاری برای دسترسی، تکمیل حساب و Billing می‌خواهد و Google Ads برای Advertiser مستقر در ایران در دسترس نیست. این راهنما دورزدن را توصیه نمی‌کند. GSC، Trends، داده فروش/پشتیبانی و تحقیق کیفی را مثلث‌سازی کنید.

چرا عدد Organic در Search Console و GA4 برابر نیست؟

چون واحد و سازوکار ثبت متفاوت‌اند: GSC Click در Google Search و GA4 Session/Event پس از اجرا و Consent را می‌سنجد. Canonical aggregation، Privacy، Timezone، Redirect، JS، Ad blocker و Channel rules نیز اختلاف می‌سازند. اول Definitionها را هم‌سطح کنید.

آیا نمره ۱۰۰ Lighthouse یا نبود Error تضمین رتبه است؟

خیر. Lighthouse مجموعه‌ای از Auditهای خودکار در Environment مشخص است. نمره خوب می‌تواند QA فنی مفیدی باشد، اما Demand، کیفیت محتوا، Index decision، Link، تجربه واقعی و Outcome را کامل نمی‌سنجد. آن را Diagnostic و Regression gate بدانید، نه گواهی رتبه.

جمع‌بندی: کمترین پشته‌ای که تصمیم درست می‌سازد

پشته مناسب از سؤال شروع می‌شود: Search Console برای دیده‌شدن در Google، GA4 و Backend برای Journey/Outcome، Trends برای علاقه نسبی، Spider برای Snapshot فنی، PSI/CrUX برای Field، Lighthouse برای Lab، Validatorها برای Schema و Index شخص ثالث برای Discovery. هیچ‌کدام به‌تنهایی حقیقت کامل نیستند.

یک Property، یک Segment و یک Decision را انتخاب کنید. Source/Scope/Limit را ثبت، شاهد دوم را اضافه، Fix کوچک را با Acceptance و Rollback اجرا و نتیجه را تا Outcome دنبال کنید. اگر ابزار رایگان این حلقه را می‌بندد، کافی است؛ اگر مانع Coverage یا تکرارپذیری می‌شود، آنگاه خرید یا ساخت ابزار مسئله‌ای روشن برای حل دارد.

منابع رسمی و صفحات محصول

• Google Search Console: Scope، پوشش، Privacy، Lag و اختلاف داده
• Google Search Console: URL Inspection Tool
• Google Analytics: تفاوت User acquisition و Traffic acquisition
• Google Trends: Sampling، Normalization و محدودیت داده
• PageSpeed Insights: Field data و Lab data
• Chrome Developers: Lighthouse
• Google Search Central: بازنشستگی Mobile-Friendly Test
• Google Search Central: Rich Results Test و Schema Markup Validator
• Google Ads: دسترسی و کاربرد Keyword Planner
• Google Ads: محدودیت رسمی کشورها و ایران
• Screaming Frog: محدودیت نسخه رایگان SEO Spider
• Ahrefs Free: قابلیت‌ها و سقف سایت‌های تأییدشده