Поиск

Не может. Теоретически может. Для обычных сайтов подобную переадресацию лучше вынести на уровень Web-сервера, чтобы объединить еще и с корректировкой протокола запроса (HTTP/HTTPS). Можно запросы по HTTP обрабатывать и на отдельном виртуальном хосте. Также можно запросы по HTTPS к неглавному зеркалу обрабатывать на отдельном виртуальном хосте. Как это обычно сделано на моих серверах: Специальный виртуальный хост для всех запросов по HTTP, например http:// или http:// www., передает управление специальной программе, которая знает главные зеркала всех сайтов сервера и настроена на переадресацию на эти зеркала. Виртуальный хост для https:// www. передает управление этой же специальной программе. Виртуальный хост для https:// (главное зеркало) не имеет дополнительных алиасов. Т.е. на основном хосте сайта вовсе не нужны условия, касающиеся корректировки главного зеркала.

истец просит: признать незаконным отказ ответчиков от исполнения условий использования Google https://; (Что, прям так и указано?) Скрин от 2012 года нотариально заверенный имеется? исполнить условия использования YouTube (Что, прям так и указано?) Скрин от 2012 года нотариально заверенный имеется? исполнить условия использования Google AdSense (Что, прям так и указано?) Скрин от 2012 года нотариально заверенный имеется? признать незаконными действия ответчиков по блокировке аккаунта Adsense for YouTube, принадлежащего истцу, и отключению в этой связи показа объявлений (рекламы) (Что, прям так и указано?) Ответчиков во множественном числе? А в условиях использования ОНИ тоже ОБА присутствовали? обязать ответчиков снять блокировку с аккаунта Adsense for YouTube, принадлежащего истцу, и включить показ объявлений (рекламы), (Что, прям так и указано? - ОБОИМ снять блокировку?) обязать ответчиков опубликовать извинения в адрес истца во всех социальных сетях корпорации Google LLC,...

В настройках конфига Nginx у меня только редирект на https: return 301 https://$host:443$request_uri; И то там не то что www, не указан, там и домен не прописан, там переменная $ host, откуда она его берет тоже не ясно, может с server _ name, но там указаны два домена один без www другой типа как алиес с www. Фиг знает может это. А в самой панели управления сервером ISPmanager е, есть в настройках сайта, возможность выставить редирект с не www на www или наоборот, но эта настройка не настроена. Тогда у меня остался всего один вопрос и к сожалению он тот же самый: Как же понять и где посмотреть где настроен редирект с не www на www ? Панель управления(Скрытая настройка или таинственная работа) DNS записи WordPress движок PHP интерпритатор Apache Nginx Единственное место где я прямо вижу что прописано с www это настройки в WordPress, Общие, там два URL а.

Да не то что бы нужно, не нужно, оно так с самого начала создания сайта было, я даже вот переезд с VPS на другой VPS делал и там все по умолчанию я ничего не менял, и ничего не настраивал все по дефолту, и вот само редиректит с не www на www, я даже не понимаю где это настраивается, есть подозрения что в движке WordPress в Настройках Общие: Адрес WordPress ( URL ) или Адрес сайта ( URL ), так как там вбито именно с www URL, есть еще вариант в настройках Nginx редирект сделать, но он там не настроен, только с http на https. Получается это движок( PHP ) редиректит, может быть на бэканде apache, но там тоже особо каких настроек редиректа вроде нету. Может это связанно с так называемыми ServerAlias алиасов дополнительные имена хоста, там один как раз как дополнительный прописан с www, но не думаю, что это редирект означает, еще может в настройках записей домена что-то есть, мне бы понять что перенаправляет с без www на www для начала.

заметил, что на некоторых доменах не убирается ipv6hint, через API запрос, в HTTPS DNS записи. непон

Собственно вопрос в теме У меня есть главная страница и есть страница https://moy-sayt.ru/moskva Данные страницы отражают одинаковый контент. Если я на ГЛАВНОЙ странице пропишу link rel= 'canonical ' href= ' ' таким образом по сути закрыв главную страницу от индексации, как это будет воспринято роботом Яндекса и Гугла? Может есть у кого-то личный опыт?

в топах начнут появляться страницы вида https://moy-sayt.ru/moskva вот и все, каноникал всего навсего доп ссылка и все, но нужно понимать уместна ли она у вас на сайте как схлебными крошками - поставили = страницы проседают, убрали - подросли, причина - та же

не то слово, уже 2 недели как самовольно расклеил мне http и https, и не собирается всё вертать взад.

Спасибо давно нужно, да работает без https.

Всё работает, но кривой движок этого форума сам добавляет HTTPS префикс протокола, а этого протокола там нет, и нет желания его добавлять.

Не бойся делай. Всё нормально. У меня также сделано, проблем нет. link rel = ' canonical ' href = ' https://мойсайт.ru/ ' / Главная и - одинаковые. Всё нормально индексирует, ничего не выпадает.

Да ну, это вообще не вариант. А как реализованы редиректы? Как проверяли? Вы могли при настройке редиректа всё сделать правильно, потом что-то поменять, а редирект мог слететь, но в браузере он может быть закеширован. Попробуйте вот этим или вот этим инструментом посмотреть, точно ли всё OK с редиректами. Новый сайт настроен на редирект с http на https? И как настроен в этом плане старый домен? Может старый домен редиректит с версии http на версию нового домена с https? По идее надо сделать на старом домене редирект на https, а потом уже после всех строчек конфига касающихся блоков server надо что-то такое прописать: Ну и логи старого сайта смотрите. Выпаливайте там бота Яндекса, который почему-то получает ответ 200OK. Если там реально бот получает 200OK для старого домена значит редиректы настроены неправильно. Если несколько лет стоит редирект, а в Google до сих пор морда старого сайта это точно ошибка какая-то. Если сделано как я выше показывал в блоке location не может такого...

В этой теме утверждают, что достаточно кофе себе заварить, и все само наладится. А кто не согласен - нагадят под дверь. Обычно 410 - это когда страница удалена. Если ошибка исчезает при отключении проксирования клаудом - то вы накосячили где-то в настройках последнего. Или в кэшировании, как описали выше со сбросом кэша, или забанили какие-то соединения с самой тильдой, или SSL, или HSTS, или HTTPS. Вариантов наступить на грабли - великое множество. Техподдержка любого хостинга всегда и во всех случаях первым действием отправляет в спортлото, даже не дочитав тикет до конца. Подключен сторонний сервис - идите туда. Даже если в этот момент ваш сервер тупо лежит и проблема в нем.

Если вы разместили ссылки - как платные то, скорее всего никак. А если вам нужен переход по ссылке - задайте для объекта (div, button или др.) событие ( 'click ',function(){('https://need_site');},false);

Всем привет! Вот не пойму, нужен ли SSL сертификат и работа сайта по https протоколу для сайта с доменом. onion ? Одни говорят что домен или соединение к. onion уже по умолчанию поддерживает шифравание и работает как типа с https, по факту очень похоже, т.к. при подключении браузер пишет безопасное соединение, хотя если ввести в начале пути протокол http то идет подключение типа по http, а по https вообще не доступен сайт, и все это странно т.к. сам веб сервер не настроен на работу по 443 порту с SSL сертификатом и работу через https, получается работа веб-сервера на обычном 80 порту по http, но т.к. идет подключение через. onion то типа получается как буд-то по https, сам браузер пишет все ок, безопасное соединение, это очень странно. Другие(википедия) пишут что даже для. onion сайтов есть официальные сертифицированные сервисы выдающие сертификаты, и можно настроить работу через них. Так и не понятно в зашифрованном виде данные передаются по. onion, типа как по https, или нет, а...

Да прекрати. Не знаю как сейчас, но раньше провайдеры вставляли свою рекламу в сайты, которые грузились по http, а не по https. Любой сторонний.js, включая твою любимую метрику, ты тоже обязан мониторить 24/7 ? Или проверять после каждой обновы коды плагинов, движков сайта? Сайты ломают, аналогичный ссылочный спам внедряют. Всех тоже под суд?

Здравствуйте как в клауде настроить сайт так, чтобы клауд не блокировал проверку владения доменом для выдачи бесплатного сертификата SSL? в логах панели такая беда Return code: 403 Details: During secondary validation: 2a06:98c1:3121::1: Invalid response from https://**************: 403

В зависимости от суммы пополнения. 0,04 руб от 6000. Остальное тут;amp;tm=1731435568&tld=ru&lang=ru&la=1730185600&text=+price&url=https%3A//&l10n=ru&mime=html&sign=d058c07c52aa5164b73bb142c5ad7159&keyno=0 Наверное самое важное пока тоже на pr пока перетащу и подожду вдруг воскреснет

Насколько помню если сайт не доступен какое то время автоматически включается проксирование через cloudflare и заодно переадресация https на http. Зайдите в CF и включите Always Use HTTPS.

редирект http - https будет мешать. но зачем сертификат тот нужен, если сайт за клаудфларом? создайте на хостинге самоподписанный сертификат и все.