Антоний Казанский

Уверен, это два балла ни на что существенно не повлияют.

На вашем месте я бы убрал h3 на заголовке "Похожие статьи", но если не получается - оставьте как есть, это не тот вопрос  в который нужно принципиально упираться.

Не запрещается, можете вставлять. Есть и такие, и такие примеры.

вам решать, будет ли <aside> частью семантического элемента <article> или нет.

Я лично выношу, чтобы четко понимать, где конец <article> блока и начало второстепенных элементов, не входящих в содержание статьи.

Это полезно, когда используется парсинг целевых данных внутри <article> блока с тем, чтобы например, вычленить целевой текст и выполнить текстовый SEO анализ. В этом случае заголовки и анонсы блока "Похожие статьи" не будут попадать в рабочую выборку данных. 

Сама по себе схожесть не является проблемой, есть случаи, где title и <H1> заголовок могут быть идентичны и это в отдельном случае может быть вполне рабочий результат.

Другое дело, что когда вы решаете задачи SEO оптимизации конкретной посадочной страницы, вот здесь есть свои особенности и рекомендации по формированию title-а и <H> заголовков.

Всё всегда определяет контекст и конкретная рабочая задача.

Тогда совершенно точно нужно искать не сервисы, а частных исполнителей, способных работать с гибкими ТЗ. 

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

Похожие статьи - это блок доп. информации, который не является частью основного документа, поэтому не надо его включаться в <article>, лучше вынести в <aside>.

Значит вопрос только в том, когда он заблокирует возможность работы и попросит оплатить рассчитанный объём :)

Записываете пошаговые инструкции, показываете на практике (можно видео записать) и отдаёте.

Таки - вот, он был выше,

<h3>
  <span style="color: #c0392b; font-size: 20px">Содержание H3</span>
</h3>

Если это связано с названием сайта, которое есть в Title Главной страницы, то вообще для всех остальных страниц (потому как footer сквозной) - это ничего не даст.

Лучше увеличить релевантность Главной страницы по ключевым словам, которые входят в описание сайта, но здесь лучше оценить ключевую плотность текста Главной страницы и если очень хочется использовать strong-и.

Избыточность кода, форматность, ограниченный функционал.

Если есть возможность писать код вручную, то конечно лучше полная свобода действий, чем её ограничение.

Как и любая CMS/компонент - данный компонент имеет набор своих скриптов и программных решений.

Это всегда выбор между программной гибкостью и простотой функциональной управляемости.

Всё зависит от вашего ресурса. Я например тоже не программист и временами вынужден использовать готовые компоненты как Elementor и подобные и насколько это возможно его адаптировать. 

Зачастую - да, медленнее, тормознутее, но если это не отражается на пользователях и не критично для SEO, то приходится мириться.

Программист, который можем сам оптимизировать скрипты он чаще всего Elementor и не выбирает, у него есть свои наработки. 

Это знаете, как поселиться в общежитии (не имея возможности снять отдельную квартиру или дом) и проводиться сравнение.

Если вы уже поселились, то вы и так понимаете с какими ограничениями это будет сопряжено.

Поэтому тут тоже самое, вы либо используете конструктор, либо не используете. 

Вы можете самостоятельно сгенерировать XML карту внешним сервисом и потом использовать её.

Например, здесь.

Также XML карту можно сгенерировать отдельной программой, например, Screaming Frog.