Я не знаю CMS, которые по-умолчанию генерируют sitemap.xml (DLE, Ghost - вроде?).
Как правило, это функционал расширения/модуля/плагина.
В любом случае, в WordPress (а это самая распространенная CMS), какой плагин для генерирования sitemap.xml поставишь - так и будет.
Если карта составляется налету, тогда есть возможность подставлять REQUEST_PROTOCOL.
Если карта генерируется время от времени в статический файл sitemap.xml, тогда можно прописать ссылки только по одному протоколу (я не уверен, работает ли ссылка типа //site.com в sitemap.xml).
И логично, что разработчики прописывают по-умолчанию HTTP ссылки, а не HTTPS.
Но это поведение очень легко изменить в исходном коде CMS/модуля/плагина/расширения.
Буквально, надо добавить одну букву.
Это имеет отношения только к подключаемым ресурсам.
HTTPS сайт может ссылаться на HTTP без потери маркера "Надежный".
Ссылки из sitemap.xml это ссылки, а не ресурсы.
Стоит ли переписывать их на HTTPS или редиректа будет достаточно, никто точно не скажет.
Нет, это так не работает.
Пришли предупреждения сайтам, у которых форма авторизации скрыта по умолчанию.
Chrome определяет именно наличие узла input с атрибутом type = password.
Показано это поле или скрыто, как я понял, не имеет значения.
Сертификат и его издатель не влияет на рейтинг ssllabs.com, а влияет корректность реализации протокола на стороне сервера (поддержка надежный шифров, запрет уязвимых шифров и другие параметры, которые четко перечисляются в отчете).
Рейтинг ssllabs.com важен только для вопроса безопасности и корректности работы вашего сайта на разных устройствах и в разных браузерах.
Как я понимаю, маркер "Незащищенный" будет появляться, если в DOM дереве размещен <input type="password">.
Из этого следующие итоги:
1. Чтобы на большинстве индексируемых и важных страниц не появился маркер "Незащищенный" достаточно вывести форму с полем ввода пароля на отдельную страницу, например, /login.php.
В этом случае, маркер "Незащищенный" появится только для страницы /login.php.
Эту страницу можно можно отдавать по HTTPS протоколу.
2. Можно изменить тип поля на type="text".
В этом случае, маркер "Незащищенный" не появится, а форма будет дальше работоспособной.
Из минусов - будет виден пароль в поле ввода и перестанет работать функция запоминания пароля в браузере.
Сомнительный метод, но если у вас интернет-магазин и вы переживаете за конверсию после выхода обновления Chrome (28 января), то это подходящая временная мера.
3. Добавление поля ввода пароля посредством JS, приведет к появлению маркера "Незащищенный". Поэтому, вариант ленивой загрузки формы посредством JS не будет работать.
4. То же самое, скорее всего касается и iframe.
5. Как решить проблему с маркером "Незащищенный" в Chrome и не потерять позиции в поисковых системах
/ru/forum/954232
Всегда пожалуйста.
Я не уверен, что правильно вас понял.
Было бы хорошо, если бы вы визуализировали то, что хотите получить.
Или можете показать пример в личные сообщения.
Как вариант, вместо hide(), вы просто можете задать оформление для .mess.invisible ($('.accordion .mess').toggleClass('invisible') вместо .hide()) - ограничить высоту блока / скрыть определенные вложенные блоки/поля ввода.
Например, .mess.invisible {max-height: 320px; overflow-y: hidden;}
Если нужно скрыть все поля ввода, кроме первого .mess.invisible input ~ input {display: none;}
Чтобы обрезание блока выглядело лучше, можно добавить эффект размывания и стрелочку/кнопку "Развернуть все".
Системы аналитики, типа Google Analytics, в размещаю в секции HEAD по ряду причин:
1. Как можно раньше отловить действия пользователя.
Например, если на ссылку будет повешена функция GOAL, то она может не сработать, если пользователь перейдет по этой ссылке раньше, чем загрузится код аналитики, который размещен ниже этой ссылки.
То же самое касается вебвизора - он банально раньше начинает следить за пользователем.
2. Если вы допустите какие-то ошибки в коде CMS, результатом которых будет неспособность CMS полностью сгенерировать страницу, есть высокая вероятность, что хотя бы секция HEAD будет корректно отдана пользователю и вы сможете отловить ошибку в статистике.
Код GA асинхронный.
Это означает, что он минимально влияет на скорость загрузки страницы.
Визуальные счетчики я не размещаю - зачем помогать конкурентам и недоброжелателям анализировать мои сайты?
Напротив, пользователю лучше отдавать большие цифры - накрученный счетчик просмотров, лайков, комментариев - это повышает авторитетность сайта и доверие к материалу.
Если я вас правильно понял, то нужно выбрать в поиске "Непрочитанные", а дальше можно уже выделить все результаты и отметить их, как прочитанные.
[ATTACH]159473[/ATTACH]
Вы хоть вдумываетесь, что пишите?
(тем-более, отвечаете два раза подряд)
В коде ошибки ясно сказано, что директива ServerName в настройках виртуального хоста Apache не отвечает шаблону DOMAIN в сертификате.
Как указанный вами сервис может помочь в этом?
