Java/backend, архитектура, производительность, техническое SEO, структурированные данные, эксплуатация сайтов
Руководитель Java/backend-разработки. Архитектура, микросервисы, интеграции, производительность и надёжность production-систем. Здесь — техническое SEO, структурированные данные и эксплуатация сайтов.
У архивной карточки важно сохранить не только URL, но и полезное содержимое: характеристики снятой модели, документацию, явную отметку о прекращении продажи и подходящие аналоги. Такая страница с HTTP 200 может по-прежнему отвечать на запрос о старом товаре. Если же оставить только пустой шаблон и «товара нет», Google может распознать soft 404, несмотря на код 200.
Если полезную карточку действительно убирают и равноценной замены нет, 404 или 410 честнее перенаправления на другую модель либо категорию. В актуальной справке Google эти ответы относятся к одной группе обработки; обещать более быстрое удаление именно с 410 оснований нет. Сам по себе 200 тоже не гарантирует индексацию.
LikeAVirgin, для описанной аудитории я бы оценивал статью по одной выполненной задаче читателя. Например, если объясняем перенаправление старой страницы на новую, человек должен понять, где в его варианте сайта это настраивается, как проверить результат и как отменить изменение. Просто заменить термин «.htaccess» на более простые слова недостаточно. В разборе удобно отдельно отметить три вещи: понятность текста, точность совета и возможность выполнить его без догадок. Статья может хорошо пройти первую проверку и провалить третью: звучит уверенно, но не объясняет, что именно открыть или какой результат считать успешным. Это даст более предметное сравнение промптов, чем спор о том, насколько текст похож на экспертный.
truebusiness, раз целиком у вас получается связнее, я бы оставил первый проход целиком, а по разделам делал уже правки. В запрос на правку передавал бы весь черновик и конкретную задачу: дополнить такой-то раздел, не повторяя то, что уже раскрыто выше.
Если всё же писать секциями, одного списка заголовков мало. Добавьте к каждой секции, какой вопрос она закрывает, что уже объяснено в соседних разделах и какие факты и термины должны оставаться одинаковыми во всей статье. Тогда у раздела будет своё место в тексте, а не новое вступление и новое заключение.
И 60 примеров я бы проверил отдельно: сделать два черновика на одной теме, с полным промптом и с короткими правилами плюс несколькими удачными образцами. Сравнивать повторы, фактические ошибки и объём ручной правки, а не длину промпта.
dzogchen_po, требование убрать canonical при подаче заявки есть в справке, в разделе «Почему заявка на переезд не принимается»: https://yandex.ru/support/webmaster/ru/yandex-indexing/moving-site#qanda . Но это условие принятия заявки, а не обещание, что возврат тега на любом этапе уже начатого переезда ничего не изменит. Такого обещания в справке нет. И для www/без www у Яндекса есть отдельное исключение: canonical для такой смены адреса прямо описан здесь — https://yandex.ru/support/webmaster/ru/robot-workings/canonical#move . Поэтому «межхостовый canonical вообще не работает» для этой пары слишком широкое утверждение. После переезда canonical со страницы на её же конечный URL без www сам по себе ошибкой не считается.
truebusiness, раз целиком у вас получается связнее, я бы оставил первый проход целиком, а по разделам делал уже правки. В запрос на правку передавал бы весь черновик и конкретную задачу: дополнить такой-то раздел, не повторяя то, что уже раскрыто выше.
Если всё же писать секциями, одного списка заголовков мало. Добавьте к каждой секции, какой вопрос она закрывает, что уже объяснено в соседних разделах и какие факты и термины должны оставаться одинаковыми во всей статье. Тогда у раздела будет своё место в тексте, а не новое вступление и новое заключение.
И 60 примеров я бы проверил отдельно: сделать два черновика на одной теме, с полным промптом и с короткими правилами плюс несколькими удачными образцами. Сравнивать повторы, фактические ошибки и объём ручной правки, а не длину промпта.