چک‌لیست سئو طراحی سایت؛ از Staging تا انتشار

سایت جدید ساعت ۲ بامداد منتشر می‌شود. طراحی چشم‌نواز است، فرم‌ها کار می‌کنند و تیم جشن می‌گیرد؛ اما صبح مشخص می‌شود noindex محیط آزمایشی روی Production مانده، بخشی از لینک‌ها فقط با JavaScript ساخته می‌شوند، URLهای قدیمی به صفحه اصلی می‌روند و رویدادهای Analytics دوبار ثبت می‌شوند. این‌ها «کارهای بعدی سئو» نیستند؛ نقص Release هستند.

چک‌لیست سئو هنگام طراحی سایت باید تصمیم‌های محتوا، معماری، رندر، URL، Crawl، Index، سرعت، داده ساختاریافته، مهاجرت و سنجش را پیش از انتشار به معیار پذیرش تبدیل کند. این راهنما برای سایت تازه، بازطراحی، تعویض CMS و مهاجرت دامنه نوشته شده و از Discovery تا پایش پس از انتشار را پوشش می‌دهد.

این چک‌لیست برای چه نوع پروژه‌ای است؟

ریسک SEO در یک سایت کاملاً تازه با بازطراحی سایتی که هزاران URL و سابقه جست‌وجو دارد یکسان نیست. ابتدا نوع تغییر را مشخص کنید؛ چون Baseline، Rollback و تست‌های لازم از آن می‌آیند.

این مقاله مالک آمادگی SEO برای Release است. برای ممیزی دوره‌ای کل سایت، راهنمای چک‌لیست ممیزی کامل سئو و برای بهینه‌سازی یک URL، چک‌لیست سئو داخلی صفحه را ببینید.

Release gate سئو؛ چه کسی اجازه انتشار می‌دهد؟

SEO نباید آخرین ستون Trello باشد که یک نفر شب انتشار بررسی کند. تصمیم‌ها بین Product، Content، Design، Front-end، Back-end، DevOps، Analytics و SEO توزیع شده‌اند. یک نفر باید مالک نهایی Gate باشد، ولی هر کنترل مالک اجرایی خودش را دارد.

Gateها را به Critical، High و Advisory تقسیم کنید. noindex روی صفحه عمومی، خرابی Checkout و Redirect loop مانع انتشارند؛ Meta Description یک صفحه کم‌اهمیت می‌تواند در Backlog بماند. همه هشدارها ارزش توقف یکسان ندارند.

Baseline پیش از طراحی یا مهاجرت

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

نسخه Crawl، Exportها، تاریخ و فیلترها را نگه دارید. Screenshot بدون Query و Date range برای مقایسه بعدی ضعیف است.

نقشه Intent و صفحه؛ پیش از Wireframe

طراحی صفحه وقتی شروع می‌شود که Job کاربر، Intent، نوع صفحه و Owner روشن باشد. ساخت سه Landing هم‌معنا با متن متفاوت، معماری را از روز اول وارد Cannibalization و نگهداری تکراری می‌کند.

کلمه کلیدی فقط یکی از شواهد است. SERP، مصاحبه فروش، Search داخلی، تیکت پشتیبانی و داده محصول کمک می‌کنند Job واقعی را بفهمید. صفحه باید پاسخ متمایز و قابل‌اثبات داشته باشد؛ صرف تغییر Title برای جداکردن دو صفحه هم‌نیت کافی نیست.

معماری اطلاعات، Taxonomy و لینک داخلی

Navigation باید Taskهای اصلی را پشتیبانی کند و لینک‌های HTML واقعی، مقصدهای مهم را به هم متصل کنند. عمق کلیک یک قانون ثابت ندارد؛ معیار بهتر، موفقیت Task، First click، Backtrack و فاصله واقعی در Link graph است.

• Category، Tag و Facet فقط با تعریف، Owner، موجودی کافی و سیاست Index ساخته شوند.
• صفحه مهم از Hub مرتبط و محتوای زمینه‌دار لینک بگیرد؛ فقط Sitemap یا منو کافی نیست.
• Anchor باید موضوع مقصد را طبیعی توضیح دهد، نه اینکه همه لینک‌ها «اینجا کلیک کنید» یا Keyword تکراری باشند.
• Breadcrumb با مسیر معمول کاربر و Canonical سازگار باشد.
• Orphan، Dead end و Pagination شکسته پیش از Release از Crawl export حذف شوند.

برای طراحی Content model، Taxonomy، Navigation، Facet و Link graph، راهنمای ساختار سایت و معماری اطلاعات را ببینید.

Content inventory؛ متن نهایی را با Lorem Ipsum تست نکنید

محتوای واقعی طول Title، شکستن Layout، ارتفاع Card، وضعیت بدون تصویر و رفتار RTL را تعیین می‌کند. Template باید با داده کوتاه، بلند، خالی، خطا و زبان ترکیبی آزمایش شود.

قرارداد URL؛ پیش از نوشتن Route

URL یک شناسه پایدار است، نه آینه‌ای که با هر تغییر Navigation جابه‌جا شود. قرارداد باید Scheme، Host، Slash، Case، Unicode/ASCII، Query parameter، Pagination و Trailing slash را تعیین کند.

تغییر URL فقط برای قراردادن Keyword یا کوتاه‌ترشدن ظاهری، هزینه Migration می‌سازد. اگر URL سالم و جاافتاده است، حفظ آن معمولاً تصمیم کم‌ریسک‌تری است.

HTTP، HTTPS و پاسخ واقعی سرور

Browser ممکن است یک صفحه خطای زیبا نشان دهد، اما Crawler به Status code و Header نیز نگاه می‌کند. یک Template ۴۰۴ که 200 می‌دهد، Soft ۴۰۴ می‌سازد؛ صفحه سالمی که CDN گاهی 5xx می‌دهد، قابل‌اعتماد نیست.

TLS معتبر، Mixed content، HSTS، Compression، Cache header و دسترسی CSS/JS حیاتی را نیز تست کنید. robots.txt ابزار امنیت نیست؛ داده محرمانه باید پشت Authentication/Authorization باشد.

Staging را چگونه از Index دور نگه داریم؟

راه ترجیحی برای محیط آزمایشی، Authentication یا محدودیت شبکه است. noindex می‌تواند لایه دوم باشد، اما اگر همان Config به Production برود فاجعه می‌سازد. مسدودکردن Staging فقط با robots.txt، URL را محرمانه نمی‌کند و ممکن است Crawler نتواند noindex داخل صفحه را ببیند.

برای مرز Crawl/Render/Index و رفتار Statusهای robots.txt، راهنمای robots.txt، تست و عیب‌یابی Crawl را بخوانید.

Robots Meta و X-Robots-Tag

HTML می‌تواند از Robots Meta و فایل‌های PDF/ویدئو از X-Robots-Tag استفاده کنند. قوانین باید بر اساس Page type و Environment در یک ماتریس باشند؛ نه اینکه Plugin و CDN جداگانه Ruleهای متناقض بسازند. Google توضیح می‌دهد Ruleهای Index فقط وقتی قابل‌خواندن‌اند که Crawler بتواند URL را ببیند: Robots Meta و X-Robots-Tag.

HTTP/1.1 200 OK
Content-Type: application/pdf
X-Robots-Tag: noindex

در Gate انتشار، Header و HTML نهایی را از بیرون شبکه و با User-Agentهای عادی و Bot-like مقایسه کنید تا CDN یا Middleware پاسخ متفاوت ناخواسته ندهد.

Canonical؛ ترجیح است، نه فرمان قطعی

Canonical برای تجمیع URLهای تکراری یا بسیار مشابه است. صفحه یکتا را به صفحه دیگری Canonical نکنید تا «قدرت منتقل شود». Google ممکن است Canonical دیگری انتخاب کند؛ بنابراین Redirect، لینک داخلی، Sitemap، hreflang و Canonical باید سیگنال هم‌سو بدهند. منبع رسمی: روش‌های تعیین Canonical.

Sitemap؛ فهرست ترجیحی، نه تضمین Index

Sitemap فقط URLهای Absolute، Canonical، قابل‌Index و دارای 200 را فهرست کند. Draft، Redirect، ۴۰۴، noindex و URL پارامتری بی‌ارزش را وارد نکنید. Google تصریح می‌کند ارسال Sitemap یک Hint است و تضمین Crawl یا Index نیست: ساخت و ارسال Sitemap.

• Sitemap را بر نوع محتوا یا بخش عملیاتی تقسیم کنید تا Monitoring دقیق‌تر شود.
• lastmod فقط هنگام تغییر معنادار محتوای صفحه به‌روز شود، نه در هر Request.
• Image/Video/News extension فقط در صورت نیاز و داده معتبر افزوده شود.
• تعداد URL در Inventory، Sitemap، Crawl و CMS را Reconcile کنید.

JavaScript SEO؛ Source، DOM و Rendered HTML را جدا ببینید

صفحه‌ای که در مرورگر شما دیده می‌شود ممکن است در HTML اولیه محتوای اصلی، Link، Canonical یا Meta نداشته باشد. Google JavaScript را پردازش می‌کند، اما طراحی باید Crawl، Render و Index را تحمل کند؛ نه اینکه فقط پس از کلیک، Scroll یا Login محتوا ساخته شود.

Google می‌گوید لینک قابل‌کشف باید عنصر <a> با href باشد و محتوای ناموجود در Rendered HTML قابل Index نیست. راهنمای رسمی: JavaScript SEO basics.

معیار پذیرش SPA و Headless

• هر View مهم URL مستقل، History و Deep link سالم دارد.
• Title، Description، Canonical و Structured data به Route درست وابسته‌اند.
• Refresh مستقیم Route، Status و محتوای همان صفحه را می‌دهد.
• لینک‌ها در HTML/Rendered DOM دارای href واقعی‌اند.
• Error، Empty و Loading state به Soft ۴۰۴ یا Infinite spinner تبدیل نمی‌شوند.
• Source و Rendered content برای موبایل و دسکتاپ محتوای اصلی هم‌ارز دارند.

Template contract؛ Title، Heading و Meta

Template باید برای هر نوع صفحه قواعد تولید و Escape داده را مشخص کند. Google ممکن است Title link یا Snippet را از منابع مختلف بسازد؛ Title و Meta Description ورودی مفیدند، نه کنترل قطعی نمایش.

Google عمدتاً Snippet را از محتوای صفحه می‌سازد و گاهی Meta Description را اگر توصیف دقیق‌تری باشد به کار می‌گیرد؛ طول ثابت تضمینی ندارد و نمایش با عرض دستگاه تنظیم می‌شود. منبع: راهنمای Snippet و Meta Description.

Structured Data؛ از Source of truth تا Rich Result

Schema باید بازتاب محتوای قابل‌مشاهده و داده واقعی باشد. Markup معتبر فقط Eligibility می‌سازد و نمایش Rich result یا افزایش رتبه را تضمین نمی‌کند. Google این مرز را صریح بیان می‌کند: راهنمای عمومی داده ساختاریافته.

جزئیات Entity graph، JSON-LD، Product/Article/Organization و Governance در راهنمای اسکیما مارکاپ و Rich Results آمده است.

تصویر، ویدئو و فایل؛ دارایی‌های فراموش‌شده مهاجرت

• URL تصویر و PDF پرترافیک را در Inventory و Redirect map وارد کنید.
• تصویر اندازه صریح، نسبت درست، فرمت مناسب و Alt متناسب با کارکرد داشته باشد؛ Alt محل تکرار Keyword نیست.
• Lazy loading نباید تصویر LCP یا محتوای فقط-با-Scroll را پنهان کند.
• Thumbnail و OG image باید مستقیم ۲۰۰، قابل Crawl و با ابعاد مناسب باشند.
• PDF دارای Title، متن قابل‌خواندن و در صورت نیاز X-Robots-Tag درست باشد.
• CDN/Media host باید TLS، CORS و Cache invalidation سازگار داشته باشد.

Mobile-first؛ محتوا و قابلیت را قربانی نسخه موبایل نکنید

نسخه موبایل باید محتوای اصلی، Heading، Alt، Structured data و Linkهای مهم هم‌ارز داشته باشد. پنهان‌کردن متن حیاتی یا Linkها برای «تمیزی موبایل» می‌تواند Discovery و تجربه را آسیب بزند.

مستندات Google درباره Mobile-first indexing بر برابری محتوا و Metadata تأکید دارد. دستگاه واقعی داخل ایران را کنار Emulator و Bot test به کار ببرید.

دسترس‌پذیری در Definition of Done

Accessibility فقط «Alt تصاویر» نیست. صفحه باید با Keyboard، Focus، Screen reader، Zoom و ورودی‌های متفاوت قابل استفاده باشد. تست خودکار بخشی از پوشش است و جای آزمون Keyboard و انسان را نمی‌گیرد.

• Landmark، Label، Heading و Name/Role/Value Componentها درست باشد.
• Focus visible و ترتیب آن منطقی باشد؛ Modal Focus trap و بازگشت Focus را مدیریت کند.
• Error summary و پیام Field مشخص، قابل‌فهم و متصل به کنترل باشد.
• رنگ تنها حامل معنا نباشد و Contrast در Stateهای Hover/Focus/Disabled سنجیده شود.
• RTL/Bidi برای URL، ایمیل، شماره پیگیری، مبلغ و متن ترکیبی تست شود.

چک مقدماتی W3C/WAI برای Keyboard، Focus، Heading، Form و تصویر نقطه شروع مفیدی است: Easy Checks for Web Accessibility.

Core Web Vitals و Performance budget

امتیاز یک تست Lab مترادف تجربه همه کاربران نیست. Lab برای Debug و Regression سریع مفید است؛ Field/RUM تجربه واقعی Device، شبکه و جغرافیا را نشان می‌دهد. بودجه را در سطح Template و Journey تعریف کنید.

Core Web Vitals جاری شامل LCP، INP و CLS است و ارزیابی توصیه‌شده در صدک ۷۵، جدا برای موبایل و دسکتاپ انجام می‌شود؛ منبع: Web Vitals. برای پیوند سرمایه‌گذاری فنی با Outcome، راهنمای سرعت سایت، UX، سئو و تبدیل را ببینید.

فروشگاه و Facet؛ از انفجار URL جلوگیری کنید

Sort، Filter، Search، Campaign parameter، Variant و Session می‌توانند فضای URL تقریباً بی‌نهایت بسازند. هر State را در ماتریس User/Crawl/Index/Canonical/Link/Sitemap تعریف کنید.

State محصول ناموجود را هم تعریف کنید: بازگشت محتمل موجودی، جایگزین مرتبط، توقف دائم و حذف Category رفتار یکسان ندارند. UI، Status، Canonical، Schema availability و Sitemap باید با Source of truth هماهنگ باشند.

امنیت، حریم خصوصی و SEO

• صفحه محرمانه را با robots.txt پنهان نکنید؛ Authentication و Authorization لازم است.
• پارامتر Preview و Draft نباید بدون Token، تاریخ انقضا و noindex مناسب عمومی شود.
• لاگ Crawl/Analytics نباید شماره موبایل، کد ملی یا Token را در URL ثبت کند.
• Consent نباید محتوای اصلی یا Navigation را برای Bot/User مختل کند.
• CSP، WAF یا Bot protection نباید Googlebot واقعی یا منابع رندر را تصادفی مسدود کند.
• صفحه Hack/Spam و خطای امنیتی باید Incident و Recovery plan داشته باشد.

Analytics و Measurement قبل از انتشار

تعویض DOM، Route و Form می‌تواند Tracking را بشکند حتی وقتی ظاهر درست است. Event dictionary باید نام، Trigger، پارامتر، PII policy، Owner و مقصد را مشخص کند.

Search outcome را با Impression/Click/Query/Page بسنجید و Business outcome را با Lead/Order/Revenue؛ یکی جانشین دیگری نیست.

آیا URLها باید تغییر کنند؟

قبل از ساخت Map، دلیل تغییر را Gate کنید. تعویض CMS به‌تنهایی الزام تغییر URL نیست. تغییر برای رفع شناسه ناپایدار، ادغام منطقی، ساختار غیرقابل‌نگهداری یا دامنه جدید ممکن است توجیه داشته باشد؛ تغییر برای «SEO-friendly شدن» بدون اثر قابل‌سنجش معمولاً ریسک اضافی است.

URL Map؛ هر قدیمی دقیقاً به کجا می‌رود؟

Inventory را از CMS، Sitemap، Analytics، Search Console، Server log و Backlinkها ادغام کنید. هر URL قدیمی یکی از این تصمیم‌ها را می‌گیرد: Keep، Move، Merge، Remove یا Investigate.

Google توصیه می‌کند Mapping بسازید، Redirect دائمی Server-side به مقصد مرتبط بدهید، لینک داخلی و Sitemap را به URL جدید تغییر دهید و از زنجیره پرهیز کنید. همچنین تغییرات بزرگ را تا حد امکان هم‌زمان روی چند محور انجام ندهید. منبع: راهنمای رسمی Site move.

برای تفاوت ۳۰۱/۳۰۲/۳۰۷/۳۰۸، Rule، امنیت و تست یک-Hop، راهنمای ریدایرکت ۳۰۱ و مهاجرت URL را بخوانید.

Redirect QA؛ فقط Browser را باز نکنید

• تمام Old URLها را با Redirect خاموش و روشن در Pipeline تست کنید.
• مقصد باید مستقیم، مرتبط، ۲۰۰ و دارای Canonical خودش باشد.
• Query ضروری، Case، Encoding فارسی، Slash و HTTP/HTTPS را پوشش دهید.
• Loop، Chain، Hop به Homepage، Soft ۴۰۴ و Open redirect را Fail کنید.
• Asset، PDF، Image و URLهای دارای Backlink را فراموش نکنید.
• Ruleهای Wildcard را با نمونه مثبت و منفی تست کنید تا URL نامرتبط بلعیده نشود.

Crawl مقایسه‌ای Staging؛ تست نماینده لازم است

اگر Staging پشت Auth است، Crawler مجاز را با Credential محدود اجرا کنید و داده را عمومی نکنید. Crawl جدید را با Baseline بر اساس Template و اهمیت مقایسه کنید.

Acceptance testهای قابل‌خودکارسازی

برای هر URL نمونه:
1. GET مستقیم باید status مورد انتظار بدهد.
2. URL نهایی redirect نداشته باشد.
3. canonical دقیقاً با قرارداد URL برابر باشد.
4. robots meta/header با Page policy برابر باشد.
5. Title، H1 و body marker مورد انتظار موجود باشد.
6. لینک‌های داخلی مقصد نهایی و بدون chain باشند.
7. Schema parse و با UI سازگار باشد.
8. فرم/خرید و eventهای حیاتی کار کنند.

نمونه‌گیری باید Stratified باشد: Homepage، Hub، Article، Service، Product، Category، Pagination، Facet، Search، ۴۰۴، Login و چند URL قدیمی. تست پنج صفحه خوش‌شانس از یک Template پوشش کافی نیست.

برنامه انتشار از T-۳۰ تا T+۳۰

چک‌لیست دقیق روز انتشار

• DNS، TLS و Host canonical از شبکه‌های متفاوت پاسخ صحیح می‌دهند.
• Production از Auth خارج و Staging همچنان محافظت شده است.
• noindex و Disallow موقت از URLهای عمومی حذف شده‌اند.
• Homepage و نمونه هر Template مستقیم ۲۰۰ هستند.
• URL قدیمی نمونه، Redirect مستقیم و مقصد مرتبط ۲۰۰ دارد.
• Canonical، hreflang، OG و Schema به Host/URL جدید اشاره می‌کنند.
• Sitemap فقط URL نهایی و قابل‌Index دارد و در robots.txt معرفی شده است.
• لینک‌های داخلی به مقصد نهایی‌اند و به Redirect قدیمی تکیه ندارند.
• CSS/JS/Image حیاتی برای Render قابل‌دسترسی‌اند.
• محتوا، H1، Title و CTA در Source/Rendered page حاضرند.
• Form، Login، Search، Cart و Payment smoke test شده‌اند.
• Page view، Conversion و Revenue با Backend Reconcile می‌شوند.
• ۴۰۴، 5xx، latency، Crawl و Conversion Alert فعال‌اند.
• Backup و Rollback owner آماده و Change log ثبت شده است.

Search Console پس از انتشار؛ Live با Indexed فرق دارد

URL Inspection دو نگاه متفاوت دارد: داده نسخه Indexشده و Live test. موفقیت Live test یعنی URL احتمالاً قابل Crawl/Index است، نه اینکه اکنون Index یا در نتایج نمایش داده شده باشد. راهنمای رسمی: Inspect and troubleshoot a single page.

برای Decision tree کامل Discovery→Crawl→Render→Index و Reasonهای Search Console، راهنمای حل مشکل ایندکس نشدن صفحات را ببینید.

Monitoring و Rollback؛ انتشار پایان کار نیست

Dashboard باید هم Health فنی و هم Outcome را نشان دهد. Threshold مطلق واحد برای همه سایت‌ها نداریم؛ از Baseline و اهمیت Journey استفاده کنید.

Rollback فقط بازگرداندن کد نیست. اگر URL، داده، Event schema یا Content تغییر کرده، باید مسیر بازگشت آن‌ها نیز طراحی شود. برای نقص جزئی از Roll-forward استفاده کنید؛ برای خرابی Critical با معیار ازپیش‌تعیین‌شده بازگردید.

ملاحظات انتشار برای کاربران ایران

• شبکه واقعی: Lab خارج ایران را کافی ندانید؛ DNS، TLS، CDN، فونت و API را از چند اپراتور و شهر بسنجید.
• فونت و RTL: FOUT/FOIT، اعداد فارسی/لاتین، URL/ایمیل/کد پیگیری و Bidi را تست کنید.
• پرداخت: Callback/Verify، Referrer و Domain migration را با Sandbox و مبلغ کنترل‌شده آزمایش کنید.
• دامنه و CDN: تفاوت Host، Origin، IP و WAF نباید Bot یا کاربر داخلی را به پاسخ متفاوت ناخواسته ببرد.
• زمان: Annotation و مقایسه روزانه را با Time zone تهران ثبت کنید؛ Release نیمه‌شب می‌تواند گزارش روز را بشکند.
• جست‌وجوی فارسی: نیم‌فاصله، ی/ک عربی، رقم، جمع، غلط املایی و Finglish در Search و URL policy تست شود.
• PII: شماره موبایل، کد ملی و شناسه پرداخت را در URL، Data layer و Log نفرستید.

اشتباهات رایج سئو در طراحی و انتشار سایت

• افزونه‌محوری: Plugin جای معماری، رندر، Server status و QA را نمی‌گیرد.
• Lorem Ipsum تا روز آخر: Template با محتوای واقعی و Stateهای سخت آزموده نمی‌شود.
• تغییر هم‌زمان دامنه، CMS، URL و Design: علت Regression تشخیص‌ناپذیر می‌شود.
• robots.txt به‌جای noindex یا امنیت: Crawl، Index و Access control با هم خلط می‌شوند.
• Redirect همه‌چیز به Home: مقصد نامرتبط برای کاربر و Crawler ساخته می‌شود.
• Canonical به‌عنوان دستور: سیگنال‌های متناقض باقی می‌مانند و Google انتخاب دیگری می‌کند.
• Sitemap به‌عنوان تضمین: URL بدون لینک و ارزش صرفاً در Sitemap رها می‌شود.
• تست فقط Homepage: نقص Templateهای Article/Product/Facet پنهان می‌ماند.
• اتکا به میانگین Performance: کاربران موبایل و شبکه ضعیف ایران دیده نمی‌شوند.
• نداشتن Baseline و Rollback: افت اثبات و مهار نمی‌شود.

چک‌لیست تحویل بین طراحی، توسعه و SEO

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

سئو در پروژه طراحی سایت از چه زمانی شروع می‌شود؟

پیش از Wireframe و Route؛ وقتی Audience، Job، نوع صفحه، Content model، Taxonomy و URL تصمیم‌گیری می‌شوند. افزودن Meta tag در انتهای پروژه نمی‌تواند معماری و رندر اشتباه را جبران کند.

برای جلوگیری از ایندکس Staging، robots.txt کافی است؟

خیر. robots.txt Crawl را کنترل می‌کند و ابزار امنیت نیست. برای Staging از Authentication یا محدودیت شبکه استفاده کنید؛ noindex می‌تواند لایه تکمیلی باشد، به شرطی که در Production حذف آن Gate بحرانی باشد.

آیا هر بازطراحی به Redirect ۳۰۱ نیاز دارد؟

فقط وقتی URL تغییر می‌کند یا چند صفحه واقعاً ادغام می‌شوند. اگر URL سالم قابل‌حفظ است، Redirect بی‌دلیل نسازید. هر URL قدیمی باید به نزدیک‌ترین مقصد هم‌معنا برود یا در نبود جایگزین ۴۰۴/۴۱۰ واقعی بدهد.

چند H1 برای سئو مجاز است؟

HTML چند H1 را منع نمی‌کند، اما برای Templateهای محتوایی معمولاً یک عنوان اصلی روشن، ساده‌ترین قرارداد طراحی، دسترس‌پذیری و QA است. موضوع مهم‌تر، Hierarchy قابل‌فهم و تطابق عنوان با محتوای صفحه است.

بعد از انتشار سایت چقدر باید سئو را پایش کنیم؟

Health و Conversion از دقیقه اول، Log و Redirect در روزهای نخست، و Index/Search outcome طی هفته‌ها پایش می‌شوند. زمان ثابت عمومی برای تثبیت وجود ندارد؛ اندازه سایت، سرعت Crawl و دامنه تغییر تعیین‌کننده‌اند. Redirectهای مهاجرت را بلندمدت نگه دارید.

جمع‌بندی

سئوی طراحی سایت یک Plugin یا فهرست Meta tag نیست؛ قرارداد Release میان محتوا، Design، Engineering، Data و Operations است. قبل از انتشار Baseline و Inventory بسازید، Intent و URL را مالک‌دار کنید، Source/Rendered HTML، HTTP، robots، Canonical، Schema، Mobile و Performance را با معیار پذیرش بسنجید، Migration را با Map و Redirect مستقیم اجرا کنید و از T0 تا T+۳۰ با Search Console، Log، RUM و Conversion پایش کنید. اگر شاهد، مالک یا Rollback ندارید، آن مورد هنوز آماده انتشار نیست.