Начните с проверки страниц, через которые клиенты находят ваши услуги: открываются ли прежние адреса, сохранились ли заголовки и разрешён ли доступ поисковым роботам. После правок Cursor сайт может выглядеть привычно, хотя в коде изменились настройки индексации или маршруты страниц. Ниже — порядок проверки URL, редиректов и метатегов для сайта малого бизнеса. Он поможет найти технические ошибки после вайбкодинга и подготовить понятную задачу разработчику, даже если вы сами не пишете код.
Что сохранить перед проверкой сайта после Cursor?
Составьте список важных страниц: главная, каталог или перечень услуг, отдельное предложение, контакты. Добавьте страницы, на которые ведут реклама и ссылки с других сайтов. Для каждой запишите прежний адрес и ожидаемый результат: страница открывается, показывает нужную услугу и позволяет отправить заявку.
Если правки ещё не опубликовали, сохраните текущую версию проекта через систему контроля версий или резервную копию. Попросите Cursor перечислить файлы, которые он изменил, и отдельно отметить изменения адресов, шаблона страницы и настроек поисковых роботов. Такой отчёт помогает выбрать, что проверить, но сам по себе не подтверждает исправность сайта.
Используйте конкретное задание: «Покажи изменения, которые затрагивают URL, редиректы, title, description, canonical, robots.txt и sitemap.xml. Пока ничего не исправляй. Для каждого изменения укажи файл и возможное влияние на поиск». Сначала получите перечень, затем сопоставьте его с поведением сайта.
Записывайте результаты в одном документе по схеме: адрес → что ожидали → что получили → что исправить. Формулировка «страница услуги открывает главную вместо прежнего содержимого» полезнее задачи «починить SEO».
Как проверить URL и редиректы после правок?
Откройте каждый адрес из списка напрямую в новой вкладке. Переход через меню недостаточен: Cursor мог обновить внутренние ссылки, а старые адреса из поиска оставить без рабочего перехода. Проверьте также обновление страницы в браузере. В приложении переход по меню иногда работает, хотя прямое открытие того же адреса заканчивается ошибкой.
- Откройте прежний URL и убедитесь, что видите нужную страницу, а не главную или сообщение об ошибке.
- Если адрес изменился, проверьте, куда браузер перенаправляет посетителя. Новая страница должна соответствовать прежней по смыслу.
- Откройте внутренние ссылки на эту страницу. Они должны вести сразу на актуальный адрес.
- Введите заведомо несуществующий путь и проверьте, что сайт сообщает об отсутствии страницы.
Для проверки откройте инструменты разработчика в браузере, выберите вкладку Network и обновите страницу. Нажмите на запрос документа: в нём видны статус ответа и адрес назначения при перенаправлении. Сам факт появления нужного текста ещё ничего не говорит о статусе ответа сервера.
При окончательном переносе страницы нужен постоянный редирект на её замену. Не отправляйте все удалённые адреса на главную: посетитель, который искал конкретную услугу, потеряет контекст. Если равноценной замены нет, сервер должен корректно сообщать, что страницы больше нет.
Отдельно проверьте варианты адреса со слешем в конце и без него. Если оба показывают одинаковое содержимое, задайте согласованное правило основного адреса. Затем проверьте, что редирект не возвращает посетителя обратно и не проходит через лишние промежуточные страницы.
Как проверить title, description и canonical?
Откройте исходный код страницы через меню браузера и найдите title, description, canonical и robots. Title задаёт заголовок страницы для поисковой системы, description описывает её содержимое, а canonical указывает предпочтительный адрес среди дублей. Поисковик при этом может сформировать заголовок и описание результата по своему алгоритму.
Проверьте каждую важную страницу отдельно. После изменения общего шаблона разные услуги иногда получают один заголовок или canonical на главную. На экране всё выглядит как прежде, но служебные данные уже описывают другую страницу.
- Title называет конкретную услугу или товар и совпадает с содержанием страницы.
- Description описывает именно эту страницу, без обещаний, которых нет в предложении.
- Основной видимый заголовок помогает понять, куда попал посетитель, и не остался от старого шаблона.
- Canonical ведёт на предпочтительный рабочий адрес, без тестового домена и случайных параметров.
- В robots нет случайного noindex на странице, которую нужно показывать в поиске.
Если в исходном коде метатегов нет, а в панели Elements они появляются, их добавляет JavaScript после загрузки. Попросите разработчика проверить, как поисковый робот получает содержимое страницы. Для сайта услуг полезно отдавать основной текст и метаданные уже в первоначальном HTML: так проверка меньше зависит от выполнения скриптов.
Видимый заголовок проверьте и в мобильной версии: он может остаться в коде, но исчезнуть за другим блоком. Для такой проверки пригодится порядок проверки вёрстки после ИИ-правок в Playwright. Он дополняет SEO-проверку: доступность текста в коде и его читаемость на экране — разные задачи.
Как проверить доступность сайта для Google и Яндекса?
Откройте файл /robots.txt и найдите правила, которые закрывают сайт или нужные разделы от обхода. Затем проверьте метатег robots и заголовок ответа X-Robots-Tag. Это разные механизмы: robots.txt управляет обходом, а noindex сообщает, что страницу не следует включать в поиск. Если робот не может загрузить страницу из-за запрета обхода, он не увидит её метатег noindex.
Проверьте /sitemap.xml, если сайт использует карту сайта. В ней должны быть актуальные адреса страниц, которые вы хотите видеть в поиске. Уберите ссылки на тестовую версию, удалённые страницы и адреса, которые перенаправляют на другие URL. Наличие страницы в карте помогает её обнаружить, но не гарантирует включение в поиск.
В Google Search Console и Яндекс Вебмастере проверьте важные URL доступными инструментами диагностики. Посмотрите, может ли робот получить страницу, какой адрес система считает основным и нет ли запрета индексации. Различайте сведения о последнем обходе и проверку текущей версии: после публикации они могут описывать разное состояние сайта.
Если сервер отвечает ошибкой 503, сначала устраните проблему доступности. Такой ответ означает, что сервер сейчас не может обработать запрос, например из-за перегрузки или технических работ (источник: «Ошибка 503 на сайте: что значит и что проверить»). Правка description эту причину не устранит.
Если после обновления страницы стали загружаться медленнее, разберите это отдельно по порядку поиска причин замедления сайта после ИИ-правок. Для передачи задачи сохраните адрес страницы и описание: долго приходит первый ответ сервера или уже после него задерживается содержимое.
Какие типичные ошибки мешают принять работу?
- Проверяют только главную. Ошибка в шаблоне отдельной услуги остаётся незаметной, поэтому в проверку включают страницы каждого типа.
- Считают отсутствие страницы по поисковому запросу доказательством поломки. Сначала проверяют её доступность и статус в кабинете поисковой системы.
- Принимают ответ Cursor «всё исправлено» без повторного теста. После каждой правки снова открывают конкретный URL и проверяют прежний симптом.
- Одновременно меняют адреса, тексты и структуру. Из-за этого сложнее установить причину ошибки; исправления лучше разделять по задачам.
- Оставляют noindex после переноса с тестовой версии. Перед публикацией проверяют настройки рабочего сайта отдельно от среды разработки.
Работу можно принять, когда прежние важные адреса открываются или ведут на подходящую замену, метатеги соответствуют страницам, а настройки не мешают поисковым роботам. Это проверка технической готовности, а не обещание позиций в поиске. Если нужна помощь разработчика, передайте ему список URL с ожидаемым поведением и попросите приложить результат повторной проверки после исправлений.
Сейчас потратьте одну минуту: откройте прежний адрес самой важной услуги напрямую и убедитесь, что после обновления вкладки он по-прежнему показывает нужную страницу.
