Sitemap не читается: URL-кодирование и экранирование XML

Если Sitemap не читается из-за амперсанда или другого символа, разделите правильный URL и его запись внутри XML. Сначала формируется адрес, затем значение экранируется для XML один раз. После разбора должен восстановиться тот же адрес: успешная проверка синтаксиса ещё не доказывает, что карта указывает нужные страницы.

Две операции решают разные задачи

URL-кодирование описывает символы и границы частей адреса. Экранирование XML позволяет поместить уже подготовленное значение в документ. Они не взаимозаменяемы: замена разделителя параметров на процентную последовательность может изменить смысл адреса, а повторное XML-экранирование — значение после чтения.

В протоколе Sitemap отдельно указаны UTF-8, экранирование значений и корректное представление URL. Не стоит пытаться исправить все три задачи одной глобальной заменой символов. Сначала выясните, на каком этапе возникло искажение.

Учебный пример на двух параметрах

Предположим, нужная страница имеет часть запроса a=1&b=2. Здесь амперсанд разделяет два параметра. Далее показаны только значения без XML-обёрток; полный адрес в настоящей карте должен быть абсолютным. Все фрагменты вымышлены и не являются ссылками на страницы сайта.

Примеры проверены локальным XML-парсером и разбором query-параметров. В третьей строке нет синтаксической ошибки XML, но адрес уже другой. В четвёртой строке получилось значение a, содержащее текст 1&b=2, вместо двух исходных параметров.

Когда %26 действительно нужен

Если амперсанд является частью самого значения, задача другая. В учебном параметре note значение A&B можно представить как note=A%26B. Тогда после URL-разбора получается одно значение A&B. Но нельзя из этого сделать правило заменять любой амперсанд, включая разделитель разных параметров.

Поэтому приёмка должна сравнивать не только внешне похожие строки, но и структуру адреса. Какие ключи должны существовать? Какие значения у них ожидаются? Как сервер трактует полученный URL? Для последнего вопроса нужен проверенный рабочий контракт конкретного сайта, а не догадка по общему примеру.

Найдите границу, где экранирование повторилось

Частая область проверки — передача значения из CMS в генератор и затем в сериализатор. Один компонент мог уже подготовить XML-текст, а другой воспринять его как обычный исходный адрес. В результате преобразование технически отработало дважды и сохранило лишний текст amp;.

В интеграции источников данных задайте смысл поля: это исходный URL или готовый текст XML-значения. Не передавайте оба вида под одинаковым названием. Готовый сериализатор должен получать данные в согласованном представлении, иначе ручные исправления в выгрузке будут возвращаться при следующей генерации.

Проверьте опубликованный файл, а не только локальную копию

Сохраните фактически отдаваемое содержимое карты и ответ сервера. CMS может показывать один вариант, а публичный адрес — старую версию или страницу ошибки. Проверка должна относиться к тому файлу, который сможет получить робот, с понятной датой наблюдения.

В инструкции Google по созданию Sitemap требуются полные абсолютные URL и экранирование XML-значений. Если после разбора получен адрес с неожиданным ключом или схемой, исправляйте источник значения. Наличие принятого XML-документа не решает вопрос о правильности его содержимого.

Приёмка генератора на малом наборе

1. Подготовьте несколько учебных адресов: обычный, с двумя параметрами и с зарезервированным символом внутри значения. Зафиксируйте ожидаемую структуру.
2. Проверьте исходный URL до XML-сериализации. Не меняйте разделители параметров как обычные символы значения.
3. Сериализуйте данные одним согласованным способом и прочитайте их XML-парсером. Сырой недопустимый символ должен обнаруживаться как ошибка.
4. Сравните извлечённое значение с ожидаемым адресом. Повторное экранирование нельзя считать успехом только из-за отсутствия ParseError.
5. Разберите параметры и сопоставьте ключи и значения. Проверьте, что a и b не превратились в a и amp;b либо в одно значение.
6. Повторите проверку для фактически опубликованного файла. Исправление ручной копии не подтверждает исправление генератора.

При поддержке сайта передайте разработчику исходное значение, опубликованный фрагмент и результат разбора. Это воспроизводимый дефект. Сообщение «Sitemap неправильный» без конкретного адреса не позволяет отличить кодировку, XML-синтаксис и ошибочный состав URL.

Синтаксис и индексация проверяются отдельно

После исправления карта должна возвращать ожидаемые адреса, но остаются другие вопросы: доступны ли документы, соответствуют ли выбранные варианты назначению и могут ли участвовать в поиске. XML-парсер не проверяет качество страниц или решение поисковой системы об индексации.

В техническом SEO-аудите фиксируйте эти результаты раздельно. Один этап подтверждает чтение файла, другой — восстановление URL, третий — состояние самих страниц. Такое разделение помогает устранить конкретную ошибку без обещания, что один исправленный амперсанд гарантирует поисковый трафик.