Андрей Овчаренко

Для начала полезно сравнить в Search Console одну страницу, которая есть в индексе, и одну отсутствующую. В «Проверке URL» важен сохранённый отчёт об индексировании: видел ли Google адрес, когда обходил его и какой canonical выбрал. Если выбран другой URL, отсутствие именно проверяемого адреса в выдаче ещё не означает, что контент вообще не проиндексирован.

«Проверить опубликованный URL» отвечает на другой вопрос: доступна ли страница для обхода сейчас. Успешный live-тест не подтверждает включение в индекс и не показывает, какой canonical Google выберет.

Поэтому сначала стоит разделить неизвестный Google адрес, проблему обхода и дубль с другим canonical. Это даст конкретное направление проверки вместо общего вывода «Google не хочет индексировать сайт».

Справка Google: https://support.google.com/webmasters/answer/9012289?hl=ru

Для Java-приложения подойдёт обычный VPS, где можно установить нужную версию JDK и запускать свой процесс. Установка Java — это настройка сервера; импортировать её в панели хостинга не требуется. На shared-хостинге такой возможности может не быть, поэтому VPS и обычный хостинг сайтов здесь стоит различать.

Если приложение на Spring Boot и собрано в исполняемый jar, отдельный Tomcat обычно не нужен: запуск через java -jar app.jar. Такой вариант описан в документации Spring: https://docs.spring.io/spring-boot/how-to/deployment/installing.html

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 сам по себе ошибкой не считается.