برای بهتر شدن یک وبسایت، همیشه به افزودن قابلیتهای بزرگ نیاز نیست. چند فایل کوچک در ریشهٔ سایت میتوانند به خزندهها در کشف صفحهها، به مرورگر در نمایش هویت برند و به پژوهشگران امنیتی در گزارش آسیبپذیری کمک کنند. البته هیچکدام بهتنهایی رتبهٔ گوگل را افزایش نمیدهند؛ اثرشان وقتی ارزشمند است که در کنار محتوای مفید، ساختار درست و تجربهٔ کاربری خوب قرار بگیرند.
در این راهنما پنج فایل را با کاربرد، نمونه و خطاهای رایج مرور میکنیم. سه فایل نخست برای بیشتر سایتها آشنا هستند؛ دو مورد پایانی به نیاز کسبوکار بستگی دارند. اگر در کنار این تنظیمات به بررسی فنی سایت نیاز دارید، صفحهٔ خدمت بهینهسازی سایت را هم ببینید.
۱. robots.txt؛ راهنمای دسترسی خزندهها#
فایل robots.txt در نشانی https://example.com/robots.txt قرار میگیرد و مشخص میکند خزندههای پیرو این پروتکل به کدام مسیرها سر بزنند. مثلاً میتوانید خزش صفحههای جستوجوی داخلی یا مسیرهای کمارزش را محدود کنید تا درخواستهای غیرضروری کمتر شوند.
User-agent: *
Disallow: /search/
Sitemap: https://example.com/sitemap.xmlنشانی نقشهٔ سایت در این مثال باید کامل و متعلق به دامنهٔ واقعی شما باشد. دستور Disallow برای محرمانهکردن اطلاعات یا حذف قطعی یک صفحه از نتایج جستوجو نیست؛ گوگل ممکن است نشانی صفحهٔ مسدودشده را از طریق پیوندهای دیگر پیدا کند. برای صفحهای که نباید در نتایج باشد، بسته به شرایط از noindex یا دسترسی محدود استفاده کنید. همچنین صفحهٔ دارای noindex باید برای خزنده قابل دسترس باشد تا این دستور خوانده شود.
بررسی سریع: فایل را در ریشهٔ هر میزبان یا زیردامنهٔ موردنظر باز کنید، از مسدود نبودن صفحههای مهم و فایلهای ضروری نمایش آنها مطمئن شوید و سپس گزارشهای گوگل سرچ کنسول را بررسی کنید.
۲. sitemap.xml؛ فهرست صفحههای مهم برای کشف بهتر#
نقشهٔ سایت، نشانی صفحههای اصلی و قابل نمایهسازی را به موتور جستوجو معرفی میکند. برای سایت تازهتأسیس، بزرگ یا دارای صفحههای کمپیوند، این فایل میتواند کشف نشانیها را آسانتر کند؛ بااینحال ثبت یک صفحه در نقشهٔ سایت تضمینکنندهٔ خزش، نمایهشدن یا رتبهگرفتن آن نیست.
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/services</loc>
<lastmod>2026-09-14</lastmod>
</url>
</urlset>در <loc> نشانی کامل و ترجیحی صفحه را بنویسید. مقدار <lastmod> را فقط پس از تغییر معنادار محتوا یا ساختار صفحه بهروز کنید؛ گوگل مقدارهای <priority> و <changefreq> را برای نقشهٔ سایت نادیده میگیرد. بهتر است صفحههای حذفشده، تغییرمسیریافته، تکراری یا دارای noindex در نقشهٔ سایت اصلی نباشند.
بررسی سریع: پاسخ فایل باید موفق و ساختار XML معتبر باشد. نقشه را در سرچ کنسول ثبت کنید و اختلاف تعداد نشانیهای ارسالشده و نمایهشده را با راهنمای عیبیابی خزش و نمایهسازی بررسی کنید.
۳. favicon.ico؛ نشانهٔ قابلشناسایی برند#
فاوآیکون تصویر کوچکی است که مرورگر ممکن است کنار نام زبانه، در نشانکها یا بخشهای دیگر رابط خود نشان دهد. این فایل ابزار مستقیم سئو نیست، اما به تشخیص سایت و یکپارچگی هویت بصری کمک میکند. نام favicon.ico در ریشهٔ دامنه برای سازگاری مفید است؛ امروزه میتوان آیکون PNG را نیز با تگ link معرفی کرد و الزامی نیست همهٔ نسخهها فقط ICO باشند.
<link rel="icon" href="/favicon.ico" sizes="any">
<link rel="icon" type="image/png" href="/icon-32.png" sizes="32x32">آیکون را ساده، خوانا و متناسب با رنگهای برند طراحی کنید؛ نوشتههای ریز در اندازهٔ ۱۶ یا ۳۲ پیکسل دیده نمیشوند. پس از تغییر، نسخهٔ جدید را در چند مرورگر و حالت موبایل آزمایش کنید، چون کش مرورگر ممکن است نسخهٔ پیشین را نشان دهد. اگر هویت بصری سایت نیاز به بازنگری دارد، خدمت طراحی گرافیک میتواند نقطهٔ شروع باشد.
۴. site.webmanifest؛ اطلاعات نسخهٔ قابلنصب وبسایت#
اگر وبسایت شما قرار است مانند یک برنامهٔ وب روی صفحهٔ اصلی دستگاه نصب شود، فایل .webmanifest نام، آیکون، رنگ و شیوهٔ نمایش آن را به مرورگر معرفی میکند. این فایل برای هر وبسایت شرکتی ضروری نیست و صرف ساختن آن نیز قابلیت کار آفلاین یا تجربهٔ یک اپلیکیشن کامل ایجاد نمیکند.
{
"name": "نام کسبوکار",
"short_name": "نام کوتاه",
"start_url": "/",
"display": "standalone",
"icons": [
{ "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
{ "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
]
}فایل را با <link rel="manifest" href="/site.webmanifest"> در بخش سرصفحه معرفی کنید، پاسخ سرور و مسیر آیکونها را بیازمایید و دربارهٔ نصبپذیری در مرورگرهای هدف تصمیم بگیرید. اگر هدف شما تجربهای فراتر از وبسایت معمولی است، تفاوت نیازها را در مرحلهٔ طراحی سایت مشخص کنید.
۵. security.txt؛ مسیر استاندارد گزارش مشکل امنیتی#
برای سایتی که امکان دریافت و رسیدگی به گزارشهای امنیتی را دارد، فایل /.well-known/security.txt راه تماس با تیم مسئول را مشخص میکند. پژوهشگر امنیتی با این فایل میفهمد آسیبپذیری احتمالی را کجا گزارش کند. این فایل نشانهٔ «امن بودن قطعی» سایت نیست و جای بهروزرسانی نرمافزار، کنترل دسترسی یا پایش امنیتی را نمیگیرد.
Contact: mailto:security@example.com
Expires: 2027-09-14T00:00:00Z
Preferred-Languages: fa, enنشانی تماس باید واقعاً پاسخگو باشد و تاریخ Expires پیش از انقضا تمدید شود. اگر هنوز فرایندی برای دریافت و پیگیری گزارشها ندارید، اول مسئولیت و مسیر پاسخگویی را تعیین کنید؛ قراردادن یک ایمیل بدون پیگیری، کمکی به امنیت کاربران نمیکند.
آیا فایلهای قدیمی Dublin.rdf و OpenSearch.xml هنوز لازماند؟#
نسخهٔ پیشین این مقاله از dublin.rdf و opensearch.xml نام میبرد. اولی قالبی برای فراداده و دومی توصیف جستوجوی داخلی سایت است؛ هیچکدام پیشنیاز عمومی سئو یا راهی تضمینی برای افزایش رتبه نیستند. اگر سامانهٔ خاصی در کسبوکار شما به آنها وابسته است، میتوان حفظشان کرد؛ در غیر این صورت بهتر است اولویت را به ساختار محتوا، پیوندهای داخلی، دسترسپذیری و تنظیمات فنی مؤثر بدهید.
چکلیست نهایی#
- نشانی فایلها را در دامنهٔ واقعی باز کنید و پاسخ سرور را بررسی کنید.
- مطمئن شوید محدودیت خزش، صفحههای مهم یا منابع لازم برای نمایش آنها را مسدود نکرده است.
- نقشهٔ سایت را با نشانیهای اصلی و تاریخ تغییر واقعی هماهنگ نگه دارید.
- فاوآیکون و در صورت نیاز فایل نصبپذیری را روی دستگاههای هدف آزمایش کنید.
- برای گزارش امنیتی، مسیر پاسخگویی مشخص و فعال داشته باشید.
این فایلها بخشی از زیرساخت فنی هستند. کیفیت محتوا، سرعت، تجربهٔ کاربری و معماری پیوندها نیز بر نتیجه اثر میگذارند. برای بررسی یکپارچهٔ این موارد میتوانید با خدمات بهینهسازی سایت آشیانه پارس آشنا شوید و برای ایدههای مربوط به ظاهر و کاربری، مقالهٔ ۱۰ ایده برای طراحی سایتهای منحصربهفرد را بخوانید.
منابع تکمیلی#
راهنمای robots.txt گوگل، راهنمای نقشهٔ سایت گوگل، مستندات وبمنیفست و استاندارد security.txt.
