طراحی سایت

چک لیست قبل از انتشار سایت

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

  • درس ۱۱ از ۱۲
  • میانی
  • رایگان، بدون ثبت نام

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

شمار هر ستون، همان کارتی است که زیرش نوشته شده.

  1. محتوا

    ۴
    • صفحه های ضروری

      تماس، درباره ما، قوانین، حریم خصوصی

    • متن نهایی

      هیچ متن ساختگی روی سایت زنده نماند

    • تصویرها با عرض و ارتفاع

      تا متن زیر پای خواننده جابه جا نشود

    • آیکن سایت و تصویر اشتراک گذاری

      با فرستادن لینک در یک گفتگو تست می شود

  2. فنی

    ۵
    • noindex برداشته شده

      در سورس صفحه و در robots.txt، هر دو

    • یک نام میزبان و SSL معتبر

      بقیه حالت ها با ۳۰۱ و بدون زنجیره

    • صفحه ۴۰۴ با کد ۴۰۴

      نه ۲۰۰ با نوشته پیدا نشد

    • نقشه سایت و robots

      CSS و جاوااسکریپت بسته نشده باشند

    • بکاپ خودکار فعال

      و یک بار بازیابی امتحان شده باشد

  3. حقوقی

    ۳
    • دامنه به نام مالک

      طراح دسترسی می گیرد، مالک صاحب می ماند

    • حساب هاست و دسترسی DNS

      روز تحویل، نه یک سال بعد

    • قرارداد و تحویل فایل ها

      فایل های طراحی هم جزو تحویل است

  4. اندازه گیری

    ۴
    • گوگل آنالیتیکس ۴

      با یک بازدید آزمایشی در گزارش لحظه ای

    • سرچ کنسول تایید شده

      ترجیحا با رکورد DNS، و نقشه سایت ثبت شده

    • رویداد فرم تماس

      وگرنه فقط بازدید را می شمارید نه تماس را

    • تست واقعی ارسال ایمیل

      به دو مقصد، و بعد نگاه به لاگ سرور

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

آخرین بررسی: فکت ها و نام ابزارهای این درس در همین تاریخ با منابعشان بازبینی شده اند.

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

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

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

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

فنی: دو خطی که بیشترین آسیب را می زنند

هر دو از نسخه آزمایشی می آیند و هر دو نامرئی اند. اولی تگ noindex در هدر صفحه است و دومی خط Disallow: / در فایل robots.txt. سایت را دیده اید که بالا آمده، کار می کند، سریع است، و شش هفته بعد کسی می پرسد چرا در گوگل نیست.

در وردپرس این تگ معمولا از یک تیک می آید: در تنظیمات و بخش خواندن، گزینه ای هست که به موتورهای جستجو می گوید سایت را ایندکس نکنند. روی نسخه آزمایشی درست است که روشن باشد؛ روز انتشار باید خاموش شود و این باید آخرین کلیدی باشد که می زنید، نه اولین.

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

سه مورد دیگر همین ستون:

  • یک نام میزبان اصلی. سایت باید فقط از یک آدرس بالا بیاید و بقیه حالت ها با ۳۰۱ به همان یکی بروند: بدون https به با https، و با www به بدون www یا برعکس. زنجیره ریدایرکت نسازید؛ هر حالت مستقیم به مقصد نهایی برود. گواهی SSL باید روی هر دو حالت با www و بدون آن معتبر باشد و با ابزار بررسی SSL می توانید تاریخ انقضا و زنجیره صدورش را ببینید.
  • صفحه ۴۰۴ واقعی. یک آدرس بی معنی را باز کنید. باید هم صفحه ۴۰۴ خودتان را ببینید و هم کد وضعیت واقعا ۴۰۴ باشد، نه ۲۰۰ با یک متن «پیدا نشد». صفحه ای که ۲۰۰ برمی گرداند برای گوگل یک صفحه سالم است.
  • نقشه سایت و robots. نقشه سایت باید در دسترس باشد و فقط آدرس های قابل ایندکس داخلش باشند، و robots.txt نباید CSS و جاوااسکریپت را ببندد. ابزار robots و sitemap هر دو را با هم می خواند.

محتوا: صفحه هایی که روز اول نباید نیمه کاره باشند

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

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

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

ایمیل سایت واقعا می رسد؟

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

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

سه رکورد DNS این را تعیین می کنند و هر سه قبل از انتشار باید سر جایشان باشند. SPF می گوید کدام سرورها اجازه دارند به اسم دامنه شما ایمیل بفرستند. DKIM یک امضای رمزنگاری شده روی خود پیام می گذارد تا گیرنده بتواند مطمئن شود دست نخورده و از همان جا آمده. DMARC به گیرنده می گوید اگر آن دو تا نخواندند چه کند و گزارش را کجا بفرستد. یک رکورد چهارم هم هست که در DNS شما نیست و در دست سرویس دهنده سرور است: رکورد معکوس یا PTR، که آی پی فرستنده را به یک نام برمی گرداند. سرورهای بزرگ ایمیلی که از آی پی بدون نام معکوس می آید را با بدگمانی نگاه می کنند.

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

مسیر یک ایمیل، از دکمه ارسال تا صندوق ورودی

پیام سبز در قدم اول چاپ می شود و تست شما باید در قدم پنجم تمام شود.

  1. ۱

    فرم سایت

    پیام «ارسال شد» همین جا چاپ می شود و هنوز هیچ چیز ثابت نشده.

  2. ۲

    تابع ارسال وردپرس

    مقدار true یعنی تحویل داده شد، نه اینکه رسید.

  3. ۳

    سرویس ارسال روی سرور

    اولین جایی که یک لاگ واقعی نوشته می شود و می شود خواندش.

  4. ۴

    بررسی نزد گیرنده

    اینجا SPF و DKIM و DMARC و نام معکوس آی پی خوانده می شوند.

  5. ۵

    صندوق ورودی یا هرزنامه

    تنها جایی که تست شما اجازه دارد تمام شود.

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

اندازه گیری: چیزی که بعدا جبران نمی شود

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

سه کار در این ستون هست. اول نصب گوگل آنالیتیکس ۴ و یک ارسال آزمایشی برای اینکه ببینید داده واقعا می رسد؛ گزارش لحظه ای همان جا جوابتان را می دهد. دوم مالکیت سایت را در سرچ کنسول تایید کنید، ترجیحا با رکورد DNS، چون آن روش به یک فایل یا یک تگ روی سایت وابسته نیست و با تغییر قالب از بین نمی رود. سوم نقشه سایت را ثبت کنید؛ راهنمای معرفی سایت به گوگل این مرحله را قدم به قدم دارد.

یک نکته که معمولا از قلم می افتد: ثبت فرم تماس را به عنوان یک رویداد تعریف کنید. بدون آن، ماه بعد می دانید چند نفر آمدند و نمی دانید چند نفر تماس گرفتند، و همین عدد دوم است که تصمیم های بعدی را می سازد.

مالکیت و حقوقی: چیزی که باید در قرارداد نوشته باشد

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

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

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

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

ترتیب روز انتشار، و اینکه چرا noindex آخر برداشته می شود

همه این کارها را قبلا کرده اید؛ اینجا فقط ترتیبشان مهم است.

  1. نسخه آزمایشی بسته بماند

    با رمز، نه فقط با noindex؛ دو نسخه از یک سایت در نتایج دردسر است.

    ۱

  2. دامنه، SSL و یک نام میزبان

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

    ۲

  3. آنالیتیکس و سرچ کنسول

    قبل از اولین بازدید واقعی، وگرنه آن داده برای همیشه رفته.

    ۳

  4. تست واقعی فرم و ایمیل

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

    ۴

  5. noindex را بردارید

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

    ۵

  6. نقشه سایت را ثبت کنید

    حالا که صفحه ها قابل ایندکس اند، این کار معنا دارد.

    ۶

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

چهل و هشت ساعت اول بعد از انتشار

انتشار پایان کار نیست، شروع دو روزی است که بیشترین خطاها در آن پیدا می شوند. چهار چیز را نگاه کنید: لاگ خطای سرور، آدرس هایی که ۴۰۴ می گیرند (اگر سایت قبلی داشته اید، اینجا معلوم می شود کدام ریدایرکت جا افتاده)، رسیدن ایمیل فرم ها، و بخش صفحه های سرچ کنسول در روزهای بعد.

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

روی همین سایت سه لایه بین شما و PHP هست: کش صفحه روی خود سرور، کش شبکه توزیع محتوا در لبه، و کش خود مرورگر. سرآیند صفحه های عمومی همین سایت به لبه می گوید نسخه HTML را تا ۲۵۹۲۰۰۰ ثانیه، یعنی سی روز، نگه دار. یعنی یک اصلاح که همین حالا روی سرور نشسته، ممکن است تا وقتی آن کش پاک نشود به چشم یک بازدیدکننده نرسد. قبل از انتشار بدانید کدام لایه ها را دارید و هر کدام چطور پاک می شوند؛ روز انتشار وقت کشف کردنش نیست.

مسیر سریع با هوش مصنوعی

روش معمول این است که آدم در مرورگر کلیک کند و صفحه به صفحه نگاه کند، و دقیقا به همین دلیل تگ noindex از دستش درمی رود: چون دیده نمی شود. مسیر سریع این را وارونه می کند. اول با چند خط دستور از خود سایت می پرسید که چه چیزی برمی گرداند، بعد همان خروجی خام را، نه توصیفتان از وضعیت را، به مدل می دهید تا مرتب و اولویت بندی اش کند. کل کار کمتر از دو دقیقه است و برای مرتب کردن خروجی یک مدل سریع و ارزان کافی است؛ انتخاب فعلی ما در <a class="text-link" href="/ai/">بخش هوش مصنوعی</a> هست.

  1. بخش اول نسخه پایین را در ترمینال اجرا کنید و به جای نشانه، دامنه خودتان را بگذارید. اگر ترمینال ندارید، همان آدرس ها را در مرورگر باز کنید و سورس صفحه را نگاه کنید.
  2. خروجی را دست نخورده بردارید. خلاصه کردنش یا نوشتن اینکه «همه چیز درست بود» دقیقا همان جایی است که این روش بی فایده می شود.
  3. بخش دوم نسخه را با همان خروجی اجرا کنید و فهرست اولویت بندی شده را بگیرید.
  4. هر موردی را که مدل علامت زد، خودتان دوباره با همان دستور چک کنید. اصلاح واقعی وقتی تمام است که خروجی دستور عوض شده باشد، نه وقتی مدل گفته درست شد.

نسخه آماده کپی

بخش اول، در ترمینال:

SITE=https://{دامنه خودتان}
for u in / /contact/ /blog/ /a-page-that-does-not-exist/; do
  printf "%s  " "$u"
  curl -s -o /dev/null -w "status=%{http_code} redirect=%{redirect_url}\n" "$SITE$u"
done
curl -s "$SITE/" | grep -oiE "<meta[^>]+name=.robots.[^>]*>|<link[^>]+rel=.canonical.[^>]*>"
curl -s "$SITE/robots.txt"

بخش دوم، خروجی بالا را با این متن بدهید:

نقش: بازبین انتشار سایت.

خروجی زیر از دستورهای بالا روی سایت من گرفته شده است:
{خروجی را همین جا بگذارید}

سایت امروز منتشر می شود و {یک خط: سایت تازه است یا جایگزین سایت قبلی}.

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

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

هوش مصنوعی در این کار

در این موضوع مدل زبانی نقش یک جفت چشم دوم روی متن تنظیمات را دارد و در همین کار واقعا خوب است: robots.txt، سرآیندهای پاسخ، فهرست ریدایرکت ها و رکوردهای DNS را دقیق می خواند و می گوید هر خط چه پیامدی دارد. موضع ما یک جمله است: خروجی واقعی را بدهید، نه توصیفتان از وضعیت را. تفاوت این دو، تفاوت یک بررسی با یک گفتگوی دلگرم کننده است.

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

  • Claude برای خواندن یک خروجی خام و مرتب کردنش به فهرست اولویت دار خوب است، و اگر بخواهید دلیل هر مورد را هم توضیح می دهد. ایران در فهرست کشورهای پشتیبانی شده انتروپیک نیست؛ این را از صفحه خود انتروپیک خوانده ایم.
  • Gemini برای سوال های تنظیماتی و توضیح یک رکورد DNS به فارسی کافی است. صفحه خود گوگل می گوید اپ وب جمنای در بیش از دویست و سی کشور و منطقه کار می کند و ایران در آن فهرست نیست.
  • Claude Code چون در ترمینال خودتان کار می کند، می تواند خود دستورها را اجرا کند و جواب را همان جا بخواند؛ برای وقتی که چند سایت را پشت سر هم باید چک کنید صرفه دارد. خودش رایگان نصب می شود ولی به اشتراک انتروپیک نیاز دارد و ایران در فهرست کشورهای پشتیبانی شده نیست.

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

سه خطر، و اولی از همه رایج تر است: مدل حرف شما را باور می کند. اگر بنویسید noindex را برداشتم، جواب بر همان اساس ساخته می شود و هیچ چیز آن را نقض نمی کند، چون مدل نمی تواند سایت شما را باز کند. تنها چیزی که این را حل می کند، دادن خروجی واقعی است. دوم، پیشنهادهای robots.txt را با احتیاط بخوانید: قانون هایی که CSS و جاوااسکریپت را می بندند هنوز در جواب ها پیدا می شوند، در حالی که گوگل برای رندر کردن صفحه به همان فایل ها نیاز دارد؛ و یک Disallow سراسری که برای نسخه آزمایشی نوشته شده اگر به نسخه اصلی کپی شود، همان فاجعه ای است که این درس درباره اش هشدار می دهد. سوم و ساده: کلید API سرویس DNS، رمز هاست و اطلاعات ورود، هیچ کدام جایشان در پنجره چت نیست. برای اینکه ببینید هر ابزار از ایران چطور قابل پرداخت است، راهنمای خرید را ببینید.

منبع ها: Google: block search indexing with noindex Google: build and submit a sitemap Google: verify site ownership in Search Console Google: email sender guidelines Anthropic: supported countries Google: where Gemini Apps are available

حد این توصیه

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

از تجربه خود ما

سه چیزی که روی سرور همین سایت قابل بررسی است و هر سه از همان مواردی هستند که این درس درباره شان هشدار می دهد. اول ایمیل: مسیر ارسال با Postfix است و دو تنظیمش عمدا روی نسخه چهار پروتکل قفل شده، inet_protocols و smtp_address_preference هر دو ipv4. دلیلش را همین امروز دوباره چک کردیم: آدرس نسخه چهار این سرور نام معکوس دارد و آدرس نسخه شش هیچ نام معکوسی ندارد، و ایمیلی که از آدرس بدون نام معکوس بیرون برود از همان اول با بدگمانی نگاه می شود. امضای DKIM را هم سرویس rspamd روی ۱۲۷.۰.۰.۱ و پورت ۱۱۳۳۲ می زند. و چیزی که واقعا نگاهش می کنیم لاگ ارسال است، نه پیام سبز فرم. دوم کش: سرآیند صفحه های عمومی این سایت به لبه می گوید HTML را ۲۵۹۲۰۰۰ ثانیه نگه دار، یعنی سی روز؛ همین یک خط توضیح می دهد چرا یک اصلاح بعد از انتشار ممکن است ساعت ها به چشم بازدیدکننده نرسد. سوم یک تله کوچک که خودمان خورده ایم: قالب این سایت تگ robots را با کوتیشن تکی چاپ می کند، پس هر جستجویی که name را با کوتیشن دوتایی بنویسد هیچ چیز پیدا نمی کند و به شما می گوید تگ نیست، در حالی که سر جایش است.

سوال هایی که واقعا پرسیده می شوند

سایت را منتشر کردم ولی در گوگل نیست. چقدر باید صبر کنم؟

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

سایت قدیمی دارم و می خواهم با سایت جدید جایگزینش کنم. همین فهرست کافی است؟

نه. جایگزینی یک کار جداست و مهم ترین بخشش نقشه ریدایرکت است: فهرست همه آدرس های قدیمی و اینکه هر کدام با ۳۰۱ به کجا می روند. اگر این نقشه نباشد، صفحه هایی که سال ها رتبه گرفته بودند به ۴۰۴ می خورند و اعتبارشان از بین می رود. این فهرست را بعد از آن نقشه اجرا کنید، نه به جایش.

حتما باید نسخه آزمایشی جدا داشته باشم؟

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

ادامه یادگیری