رفع خطای Bad escape sequence in string در سایت و وب مستر تولز

خطای Bad escape sequence in string یعنی در یک مقدار متنی JSON، بعد از کاراکتر بک اسلش یک توالی نامعتبر قرار گرفته است. در سایت و وب مستر تولز، که امروز با نام Google Search Console شناخته می شود، این پیام اغلب هنگام پردازش داده های ساختاریافته JSON-LD دیده می شود. مثلا اگر توضیحات محصول شامل بک اسلش باشد و برنامه آن را بدون تبدیل صحیح وارد اسکیما کند، گوگل ممکن است نتواند بلوک مربوط را بخواند؛ حتی وقتی ظاهر صفحه برای بازدیدکننده کاملا سالم است.

برای رفع خطا باید خروجی واقعی صفحه را پیدا کنید، رشته معیوب را تشخیص دهید و روش تولید JSON را اصلاح کنید. پاک کردن همه بک اسلش ها، حذف متن فارسی یا کلیک مکرر روی Validate Fix راه حل اصولی نیست. در این راهنمای تخصصی، نمونه های اشتباه و صحیح، عیب یابی وردپرس و ووکامرس، تولید امن JSON و مسیر تایید اصلاح در سرچ کنسول را مرحله به مرحله بررسی می کنیم.

پاسخ سریع: برای رفع Bad escape sequence in string چه کنیم؟

1. یکی از URLهای گزارش شده را در Rich Results Test بررسی کنید.
2. بلوک JSON-LD و مقدار متنی دارای escape نامعتبر را پیدا کنید.
3. منبع تولید آن بلوک را در قالب، افزونه یا کد سفارشی شناسایی کنید.
4. داده خام را با serializer استاندارد مانند wp_json_encode یا JSON.stringify به JSON تبدیل کنید.
5. کش مرتبط را پاک کنید و خروجی عمومی URL را دوباره آزمایش کنید.
6. پس از اصلاح نمونه های همان مشکل، در گزارش سرچ کنسول Validate Fix را اجرا کنید.

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

معنی دقیق خطا در سایت و وب مستر تولز

JSON یک قالب تبادل داده است و قواعد نگارشی مشخصی دارد. JSON-LD از همین قواعد استفاده می کند و اطلاعاتی مانند نوع صفحه، محصول یا مقاله را با ساختار قابل پردازش ارائه می دهد. مرورگر ممکن است متن معمولی صفحه را نمایش دهد، اما پردازشگر داده ساختاریافته هنگام رسیدن به رشته نامعتبر متوقف شود. بنابراین سالم بودن ظاهر سایت، صحت اسکیما را ثابت نمی کند.

گوگل در راهنمای رسمی Rich Results Test این پیام را به استفاده از escape نامعتبر در یک مقدار رشته ای نسبت می دهد. در گزارش Unparsable structured data نیز خطاهای نگارشی شدیدی ثبت می شوند که ممکن است حتی تشخیص نوع داده را مختل کنند.

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

Escape چیست و چرا بک اسلش اهمیت دارد؟

بک اسلش با اسلش معمولی متفاوت است. اسلش معمولی در آدرس های وب دیده می شود، اما بک اسلش در رشته JSON آغاز یک escape است. بر اساس استاندارد RFC 8259، کوتیشن دوتایی، بک اسلش و کاراکترهای کنترلی محدوده U+0000 تا U+001F در رشته به نمایش escape شده نیاز دارند. حروف فارسی به خودی خود escape نامعتبر ایجاد نمی کنند.

نمایش داخل رشته JSON	معنا
\"	کوتیشن دوتایی داخل متن
\\	یک بک اسلش واقعی
\/	اسلش معمولی؛ خود / هم مجاز است
\n	رفتن به خط بعد
\r	بازگشت carriage return
\t	تب
\b و \f	backspace و form feed
\uXXXX	نمایش یونیکد با 4 رقم هگزادسیمال؛ XXXX جای نگهدار است

توالی هایی مانند \q، \s یا \' escape معتبر JSON نیستند. اشتباه رایج این است که قواعد رشته در یک زبان برنامه نویسی را عینا به JSON تعمیم دهیم.

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

نمونه های این بخش، JSON خام هستند؛ تعداد بک اسلش هایی که می بینید مربوط به خود JSON است، نه یک رشته تو در تو در PHP یا JavaScript. این تفاوت برای جلوگیری از escape دوباره اهمیت دارد.

1. بک اسلش پیش از یک حرف نامعتبر

نمونه زیر نامعتبر است، چون q بعد از بک اسلش، escape شناخته شده ای نمی سازد:

{"description":"Model \q"}

اگر واقعا می خواهید متن شامل یک بک اسلش قبل از q باشد، نمایش صحیح در JSON خام چنین است:

{"description":"Model \\q"}

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

2. استفاده اشتباه از escape برای آپاستروف

این مثال به دلیل استفاده از escape نامعتبر برای کوتیشن تکی مشکل دارد:

{"description":"Owner\'s guide"}

آپاستروف داخل رشته ای که با کوتیشن دوتایی JSON محصور شده، نیازی به این escape ندارد:

{"description":"Owner's guide"}

3. کوتیشن دوتایی داخل توضیحات محصول

برای متنی مانند Size “XL”، کوتیشن های داخل مقدار باید escape شوند. نمونه زیر JSON معتبر است:

{"description":"Size \"XL\""}

کوتیشن داخلی بدون escape ممکن است پیام دیگری مانند کمبود کاما یا پایان نامعتبر رشته بسازد؛ همه خطاهای کوتیشن الزاما با همان عبارت Bad escape sequence گزارش نمی شوند.

4. مسیرهای ویندوزی و خراب شدن بی صدای متن

اگر لازم است یک مسیر نمونه ویندوز را در مقدار متنی نگه دارید، بک اسلش واقعی را درست نمایش دهید:

{"description":"C:\\products\\new"}

نکته ظریف این است که بک اسلش اشتباه همیشه خطای نحوی ایجاد نمی کند. مثلا ترکیب بک اسلش و n می تواند به خط جدید تبدیل شود و ترکیب بک اسلش و t به تب. در این حالت JSON از نظر نحوی معتبر می ماند، اما مقدار خوانده شده با داده اصلی فرق می کند. پس علاوه بر موفق بودن parse، مقدار نهایی را هم بررسی کنید.

تفاوت خطای escape با خطاهای مشابه

نشانه	محل بررسی	اقدام مناسب
Bad escape sequence in string	کاراکتر بعد از بک اسلش	تولید صحیح مقدار رشته با encoder
خطای Unicode escape	توالی یونیکد ناقص یا نامعتبر	بررسی خروجی encoder و بریدن رشته
Missing ‘,’ or ‘}’	کاما، آکولاد یا کوتیشن قبلی	اصلاح ساختار JSON از محل واقعی شکست
Incorrect value type	نوع مقدار فیلد	تطبیق مقدار با نوع مورد انتظار
Missing field	اطلاعات الزامی نوع اسکیما	تکمیل داده مرتبط و واقعی

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

پیدا کردن محل خطا در خروجی واقعی سایت

مرحله اول: URL و نمونه گزارش شده را ثبت کنید

در سرچ کنسول، گزارش Unparsable structured data را در صورتی که برای سایت موجود است باز کنید و ردیف خطا را ببینید. URL، زمان آخرین خزش و جزئیات نمونه را ثبت کنید. اگر تعداد زیادی صفحه با یک الگوی مشترک خطا دارند، ابتدا قالب مشترک یا مسیر تولید داده را بررسی کنید؛ ممکن است مشکل از یک فایل یا فیلتر باشد، نه از تک تک نوشته ها.

مرحله دوم: آدرس را در Rich Results Test آزمایش کنید

در Rich Results Test گوگل حالت URL را اجرا کنید و کد دریافت شده را ببینید. محل نمایش خطا را با ابتدای همان مقدار رشته تطبیق دهید. گاهی پردازشگر کمی بعد از علت اصلی متوقف می شود؛ بنابراین فقط کاراکتر هایلایت شده را نگاه نکنید و کوتیشن یا بک اسلش قبل از آن را هم بررسی کنید.

مرحله سوم: همه بلوک های JSON-LD را بررسی کنید

در سورس صفحه عبارت application/ld+json را جستجو کنید. ممکن است افزونه سئو یک بلوک سالم تولید کند و ابزار دیگری بلوک خراب جداگانه ای بسازد. داشتن چند بلوک به خودی خود خطای escape نیست؛ هر بلوک باید جداگانه قابل پردازش باشد. حذف همه اسکیماها برای پنهان کردن پیام، تشخیص ریشه ای محسوب نمی شود.

اگر داده با جاوا اسکریپت اضافه می شود، سورس اولیه کافی نیست؛ DOM رندرشده و خروجی قابل مشاهده ابزار گوگل را هم بررسی کنید. راهنمای سئو جاوا اسکریپت تفاوت HTML اولیه و محتوای رندرشده را توضیح می دهد.

رفع خطا در وردپرس، ووکامرس و افزونه های سئو

وجود Yoast، Rank Math یا هر افزونه دیگری در سایت، ثابت نمی کند همان افزونه منبع خطاست. قالب، افزونه امتیازدهی، ابزار FAQ، کد هدر و فوتر یا فیلتر سفارشی می توانند خروجی مستقل داشته باشند. نام یا شناسه بلوک فقط سرنخ است؛ برای نتیجه قطعی، محل تولید مقدار خراب را دنبال کنید.

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

برای مثال، اگر مقدار description با چسباندن متن محصول به یک قالب رشته ای ساخته می شود، یک کوتیشن یا بک اسلش کافی است تا ساختار بشکند. راه درست این است که آرایه داده را بسازید و کل ساختار را به encoder بدهید. تابع wp_json_encode در وردپرس مقدار را به JSON تبدیل می کند و در صورت ناتوانی می تواند false برگرداند؛ نتیجه باید کنترل شود.

نمونه تولید JSON-LD در وردپرس

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

$data = [
    '@context'    => 'https://schema.org',
    '@type'       => 'WebPage',
    'name'        => get_the_title(),
    'url'         => get_permalink(),
    'description' => wp_strip_all_tags(get_the_excerpt()),
];

$json = wp_json_encode(
    $data,
    JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS |
    JSON_HEX_QUOT | JSON_UNESCAPED_UNICODE
);

if (false !== $json) {
    echo '<script type="application/ld+json">' . $json . '</script>';
}

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

روی کل JSON خروجی، addslashes، stripslashes، esc_js یا جایگزینی عمومی بک اسلش اجرا نکنید. استفاده از esc_html روی کل payload داخل تگ script نیز می تواند کوتیشن های ساختاری را به entity تبدیل و JSON را خراب کند. پاکسازی ورودی، تنظیم اسلش در مرز API وردپرس و serialization خروجی مراحل متفاوت اند؛ wp_unslash فقط در جایی به کار می رود که قرارداد ورودی واقعا داده slashed ارائه می دهد، نه به عنوان درمان عمومی این خطا.

رفع خطا در جاوا اسکریپت و Google Tag Manager

ساختن رشته JSON با قراردادن مستقیم نام محصول یا عنوان صفحه میان کوتیشن ها شکننده است. داده را به شکل یک شیء بسازید و با JSON.stringify تبدیل کنید. نمونه زیر یک بلوک ساده در DOM می سازد؛ اجرای آن برای بررسی الگوست و باید فقط در صورت نیاز واقعی و بدون ایجاد خروجی موازی استفاده شود:

const data = {
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": document.title,
  "description": document.querySelector("h1")?.textContent || document.title
};

const node = document.createElement("script");
node.type = "application/ld+json";
node.textContent = JSON.stringify(data);
document.head.appendChild(node);

این نمونه، متن را از DOM موجود می خواند و با textContent به عنصر ایجادشده اختصاص می دهد. اگر مقدار را ابتدا داخل یک رشته JavaScript در HTML خام یا Custom HTML تگ منیجر قرار دهید، مشکل escape می تواند پیش از رسیدن به JSON.stringify رخ دهد. در چنین پیاده سازی هایی باید مرز HTML، JavaScript و JSON را جداگانه کنترل کنید؛ stringify روی داده ای که قبلا خراب شده، داده اصلی را بازسازی نمی کند.

همچنین stringify را دوبار اجرا نکنید. خروجی مرحله اول یک متن JSON است؛ تبدیل دوباره می تواند یک رشته JSON به جای شیء مورد انتظار بسازد. نتیجه شاید از نظر نگارشی معتبر باشد، اما ساختار مورد نیاز JSON-LD را ارائه ندهد.

ابزار محلی برای پیدا کردن بلوک خراب

کد زیر فقط بلوک های JSON-LD موجود در DOM صفحه بازشده را می خواند و نتیجه parse را در کنسول مرورگر نشان می دهد. هیچ تغییری در سایت ایجاد نمی کند. پس از بارگذاری کامل صفحه خودتان آن را اجرا کنید:

document.querySelectorAll('script[type="application/ld+json"]')
  .forEach((node, index) => {
    try {
      const data = JSON.parse(node.textContent);
      console.log("Block", index + 1, "Valid JSON", data);
    } catch (error) {
      console.error("Block", index + 1, error.message, node);
    }
  });

پیام Valid JSON فقط صحت نگارشی را تایید می کند؛ اعتبار معنایی اسکیما، الزامات گوگل و تطبیق با محتوای قابل مشاهده را تایید نمی کند. این بررسی همچنین به iframeها یا محتوایی که هنوز بارگذاری نشده سر نمی زند. برای ارزیابی schema می توانید از Schema Markup Validator و برای قابلیت های پشتیبانی شده گوگل از Rich Results Test استفاده کنید.

آیا کاراکتر فارسی، & یا اسلش علت خطاست؟

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

تفاوت مهم دیگری میان JSON و HTML وجود دارد: entityهایی مانند " جایگزین عمومی escape کوتیشن در JSON نیستند. داخل script، رفتار متن با یک پاراگراف HTML یکسان نیست. اصلاح باید متناسب با زمینه خروجی انجام شود؛ تغییر همه توضیحات فارسی یا حذف علائم نگارشی از پایگاه داده، راه حل قابل اتکایی نیست.

اگر URLهای عجیب و پارامترهای ناشناس در گزارش دیده شوند

ممکن است یک عبارت جستجو یا پارامتر URL به صورت پویا در نام صفحه یا breadcrumb قرار گیرد. اگر مقدار بدون serialization صحیح وارد JSON-LD شود، ورودی دارای بک اسلش می تواند خطا را آشکار کند. این وضعیت به تنهایی اثبات هک شدن سایت نیست، اما URLهای ناشناس باید از نظر محتوای واقعی، پاسخ سرور و منبع تولید بررسی شوند.

در صفحات آرشیو و فیلتر، سیاست ایندکس و سلامت خروجی دو مسئله جدا هستند. اصول سئو صفحات دسته بندی را برای تعیین نقش صفحه به کار بگیرید، ولی noindex را جایگزین اصلاح serializer نکنید. بازتاب ورودی کاربر در HTML یا script نیز باید از نظر امنیت خروجی بررسی شود؛ رفع خطای parse به تنهایی ممیزی امنیت نیست.

تاثیر خطا بر ایندکس، رتبه و ریچ ریزالت

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

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

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

پس از اصلاح، چگونه Validate Fix را انجام دهیم؟

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

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

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

چک لیست پیشگیری برای توسعه دهنده و مدیر سایت

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

سوالات متداول درباره Bad escape sequence in string

آیا این خطا باعث حذف سایت از گوگل می شود؟

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

آیا حذف بک اسلش از توضیحات محصول کافی است؟

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

آیا Yoast یا Rank Math همیشه عامل خطا هستند؟

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

چرا تست محلی سالم است ولی سرچ کنسول هنوز خطا دارد؟

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

آیا فارسی بودن سایت باعث Bad escape sequence می شود؟

خیر. متن فارسی معتبر در JSON قابل استفاده است. اشکال معمولا در تبدیل، کوتیشن گذاری یا escape نادرست داده رخ می دهد، نه صرف فارسی بودن متن.

آیا سبز شدن JSON Validator به معنی رفع کامل مشکل سئو است؟

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

آیا با robots.txt یا noindex باید خطا را رفع کنیم؟

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

راه حل پایدار: اصلاح تولید داده و کنترل خروجی نهایی

برای رفع خطای Bad escape sequence in string، از URL واقعی شروع کنید، بلوک خراب را پیدا کنید و داده را فقط یک بار با encoder مناسب به JSON تبدیل کنید. پس از آن، کش و خروجی عمومی را بررسی کنید و اعتبارسنجی سرچ کنسول را پیگیری کنید. این مسیر هم مشکل فعلی را حل می کند و هم احتمال تکرار آن با عنوان، محصول یا ورودی جدید را کاهش می دهد.