Карта страниц, тем и постоянных URL

Ручная панель помогает увидеть вопросы, но редактору нужно понять, какую страницу менять. В этом уроке свяжем задачи читателя, внутренние идентификаторы и постоянные адреса. Такая карта пригодится и для AI-поиска, и для обычной навигации библиотеки.

Продолжаем ProfessorWeb Lab. В наборе есть старый PHP-адрес и два новых урока. Это придуманные адреса на зарезервированном домене professorweb-lab.example; они не являются опубликованными материалами настоящего сайта.

Имя материала и адрес страницы

У учебной страницы есть как минимум три имени. page_id нужен нашим таблицам, публичный URL — читателю и поиску, путь Markdown — редактору. Переименование локального файла не обязано менять URL. Если смешать эти значения в одном столбце, обновление сборки может нарушить аналитические связи, хотя материал остался прежним. Поэтому создадим отдельную строку для устойчивого идентификатора P01.

В page-map.csv P01 содержит урок сохранения адресов. У него есть canonical_url, markdown_file, intent_id и content_version. Исторический URL записан отдельным полем legacy_url. Это не правило автоматически перенаправить его на новый красивый путь. В нашей модели старая страница продолжает обслуживаться по прежнему адресу, а Markdown лишь становится новым источником её содержания. Если реальный перенос действительно требует другого URL, решение и соответствие записывают отдельно.

Свяжем Q01 и Q02 из панели с P01. Оба относятся к сохранению адресов, но требуют разных фрагментов: общего принципа и проверки расширения PHP. Для каждого сопоставления сохраняем coverage, принимающее значения full, partial, missing. Это редакционная оценка после чтения страницы, а не оценка поискового алгоритма. Частичное покрытие позволяет увидеть конкретную работу без обещания позиции.

P02 объясняет коллекции Markdown, P03 — безопасную публикацию. Вопрос о возврате трафика нельзя считать полностью покрытым только потому, что P03 содержит слово «деплой». Техническое действие и бизнес-результат отличаются. Наша карта должна отражать задачу, которую человек сможет решить после чтения, поэтому поле reader_result формулируется глаголом: составить карту, проверить ответ сервера, открыть исходник.

Отдельно рассмотрим canonical. В данных Google результаты обычно связываются с каноническим URL, и дубль может отсутствовать в выгрузке как самостоятельная строка. Для аналитической карты полезно хранить наблюдённый адрес и адрес, к которому его отнесли. Не удаляйте старое наблюдение после нормализации: иначе исчезнет возможность объяснить, почему две внешне разные ссылки относятся к одному материалу.

Пробел не всегда означает новую страницу

Представим, что Q02 помечен как partial. Есть три разумных изменения: добавить подраздел в P01, написать следующий урок о проверке адресов или улучшить связь с уже существующим руководством. Выбор зависит от самостоятельности результата. Если читателю нужен отдельный набор инструментов и полный разбор ошибок, новый урок оправдан. Если недостаёт только одного соответствия в таблице, отдельная страница раздробит объяснение.

В демонстрационной карте выбираем доработку P01. Сохраняем URL и page_id, меняем content_version с v1 на v2, добавляем результат «различить путь Markdown и URL страницы». Панель запросов остаётся прежней. Это создаёт понятную цепочку: наблюдение → задача → изменение конкретного документа. Позднее измерения смогут ссылаться на стабильный объект, даже если заголовок станет более ясным.

Проверьте карту на конфликт: один и тот же canonical_url оказался у P01 и P03, хотя тексты учат разным действиям. Такой конфликт нельзя исправить случайным выбором первой строки. Нужно открыть метаданные и определить ошибку источника. В аналитическом журнале оставим статус needs_review, а затронутые строки временно исключим из сравнения страниц с объяснением причины.

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

Добавьте к карте owner и source_state. Владелец помогает выяснить, кто проверяет смысл страницы; состояние источника показывает, относится запись к проекту, локальному черновику или публикации. Нельзя выводить рабочее индексирование из того, что Markdown-файл существует в репозитории. Это разные состояния жизненного цикла, и при большой библиотеке они регулярно расходятся.

Не используйте title как ключ связи. Заголовок «Перенос сайта» редактор может уточнить до «Сохранение прежних URL», и все исторические наблюдения должны остаться связанными с P01. Устойчивые ключи превращают переименование в небольшое изменение текста, а не в пересоздание статистики. Такой же принцип позже применим к видео, плейлистам и главам курса.

Карта также помогает находить нежелательные повторы. Если два новых Markdown-файла обещают одинаковый результат и относятся к одному вопросу, откройте их рядом. Разница оформления или названия ещё не делает их самостоятельными уроками. Возможно, нужен один полный материал и дополнительный вариант внутри него. Если результаты действительно разные, сохраните их отдельными ключами и объясните отношение. Такая редакционная проверка особенно важна при параллельном написании: авторы могут случайно решать одну задачу разными словами. Устойчивая карта не запрещает похожие темы, она делает их различие видимым и позволяет выбрать понятный маршрут для читателя.

Чтение сохранённого состояния

В артефакте сначала найдите P01 и проследите все три его имени: внутренний ключ, адрес и локальный исходник. Затем откройте Q01/Q02 в панели. Связь должна объяснять, что именно покрывает страница. Имена внешних систем и редакционных таблиц здесь не заменяют содержательное чтение урока.

Объект	Что сохраняется при обновлении
P01	Внутренний ключ остаётся прежним, когда уточняется заголовок или добавляется пример следующей версии.
Исторический URL	Старое расширение остаётся частью публичного пути; Markdown не требует автоматического изменения адреса.
Markdown-файл	Локальное имя можно изменить независимо, если метаданные продолжают задавать тот же публичный permalink.
Карта покрытия	Оценка полноты относится к определённой версии текста и не является подтверждением алгоритмического ранжирования.

В файле нет работающего лабораторного сайта. Поэтому canonical является заданным учебным адресом, а не результатом получения HTML. Это ограничение важно для будущей адаптации: реальные сведения потребуют собственного источника, времени и способа наблюдения. Нельзя переносить значение из нашей таблицы в отчёт рабочего сайта.

Попробуйте переименовать title в своей копии карты, сохранив P01 и URL. Старые наблюдения должны продолжать относиться к тому же объекту. Затем измените саму задачу материала. Теперь одного переименования недостаточно: потребуется редакционное решение о совместимости прежней страницы и нового содержания. Так становятся видны разные последствия косметического и смыслового изменения.

Основной артефакт page-map.csv находится в lesson-03 архива серии. Полный снимок содержит также исходные таблицы и договоры. Они читаются вручную; результаты примеров описаны как ожидаемые, выполнение не проводилось.

Первичные источники: google guide, google ai.