Какой-то жутко странный ап.
Там где сайтами не занимаюсь давно и они уже почти в утиль пошли, ни трафика ни интереса - ИКС вверх до 33%.
Те сайты, которые наоборот, вроде как более популярны и интересны посетителям и все окей - минус почти до 67%.
И лишь один сайт худо бедно из всех подрос правильно, но всего на 10%.
Не удивлюсь, если перекрутили и откатят. А иначе прям аж задуматься будет над чем )---------- Добавлено 30.07.2019 в 20:32 ----------
Даже с учетом этого - теперь ИКС вообще не бьет в сравнении с реальным положением дел на сайтах. Где интерес пользователей выше - икс значительно ниже, где интереса вообще нет и сайт уже умирает - ИКС вверх. Моя не понимать логику.
Выше верно указали, удалить необходимо только кэш. Он содержит настройки редиректов, в том числе. Куки и данные файлов удалять при этом не требуется. Сам этим периодически пользуюсь.
Только в моей последней версии меню выглядит чуть иначе, ну и перегружать браузер не требуется, достаточно перегрузить страницу где был редирект. Полагаю, что это уже чисто вопрос установленной версии.
Добавлю отдельной строкой. Бывают такие изображения, когда они сами по себе осмысленны и их можно использовать отдельно от контента. Ну, для примера, всякие разные цитаты на изображениях, инструкции или еще что-то схожее. Такие изображения имеет смысл отдавать под основным доменом. Нередки случаи, когда пользователи делятся ссылками непосредственно на картинку, что учитывается в обратных ссылках. Не знаю насколько этот вес велик, но при большом распространении изображений - получается неплохой их обратный приток.
С тех пор как ПС жестко урезали трафик с картинок - это дело вообще не имеет большого значения. Да и когда не был урезан трафик - я держал картинки на отдельных серверах и все было отлично.
По факту я работаю по такой схеме:
1) Отдельный сервер с изображениями
2) В большинстве случаев это поддомен основного домена, типа img.maindomain
3) cname я не использую, поскольку для хранилища использую обычные виртуалки и настраиваю прямую запись, но можно и через cname, при необходимости
4) Ничего обратного не настраиваю, незачем. На картиночном нет ни индекс страницы, ни каких-либо еще. Ничего никуда не редиректит.
5) SSL на сервере изображений не суть важен, но если вы хотите зеленый замочек в строке браузера на своем сайте вместо желтого предупреждения - да, ssl нужно ставить. Я устанавливаю, это 10 минут дела.
6) Нужен ли отдельный SSL сертификат - зависит от того, какой у вас ssl-сертификат сгенерирован, если он распространяется на все поддомены - можно и нужно использовать его же в настройке, если не включает - сгенерировать для поддомена. У меня отдельно сгенерированные.
Разницы влияния от того где у меня живут картинки и прочий медиа-контент не замечаю. Чисто вопрос удобства.
Вот это уточнение, как по мне - самое важное.
Ибо одно дело, когда ру-трафик, и ищут по наименованию на русском или англ - не суть важно. Или даже ищут перевод, как пример - сайты с переводами текстов песен - там все на одной странице и это правильно.
И другое дело, когда у вас довольно приличная часть ищет на другом языке - логичнее, что им будет выдана страница на их языке, а не мешанина.
Так что да, логичнее было бы сделать разные страницы под разноязычных пользователей.---------- Добавлено 28.07.2019 в 19:28 ----------
Так вроде неплохо, на мой взгляд. Может быть еще стоило бы вынести в отдельный поддомен, типа en.karoqs. Но, хотя бы для англоязычного пользователя уже будет хорошо - текст на его языке, а не мешанина.
VDS тоже является "DS" - выделенным сервером. Написали бы "дедик", было бы понятнее. Не ждите на общем форуме идеальных формулировок, пишите проще и вас будут лучше понимать. На то эти сокращения и нужны.
Разговор велся за качество хостера, потому, о каких бы услугах речь не шла: хостинг, виртуалка, дедик и даже колокейшн - вы все равно завязаны на то, какое качество услуг они предоставляют. Начиная от виртуального окружения и заканчивая обслуживанием физических серверов и коммуникаций. И потому не имеет серьезного значения, дедик это или виртуалка - выделенный сервер так или иначе завязан на работу хостера. Что в виртуалке может быть проблема, что физический дедик подсунут убитый, что в колокейшн поставите свое оборудование, но вам остальные коммуникации подведут через ж - вы всегда зависите от качества хостера. Так что, что бы вы не имели ввиду - это не панацея.
По хостингу - не замечал разницы, если скорость и качество работы сайта в норме. Теоретически, можно попасть на плохой ip, находящийся в спам-базах, но у меня где бы клиенты не хостились - явных проблем замечено не было. И так, чтобы перенесли сайт с хостинга на хостинг и вдруг стало хуже или лучше - тоже не замечал.
Может у кого есть иная практика - тоже было бы интересно послушать.
А вот https однозначно - влияет. После переезда наблюдается прирост с Яндекса. Одна беда - с Гугла проседает )) У всех по-разному, но влияние однозначно есть.
Скажем так, от хостера вы по-любому зависите. Просто это будет не хостинг, а виртуалка, к примеру, если конечно это не дедик. А виртуалка все равно работает в общем окружении и, зачастую, если хостер так себе, то это самое окружение может быть каким угодно. Не раз попадал уже так, что, к примеру, моя виртуалка значительно начинает тупить из-за того, что кто-то еще в этой ноде сильно нагружает контейнер. У нормального хостера такого быстро прижмут даже без жалоб, а у так себе - или надо сообщать, или даже с него по итогу переезжать.
Ну и опять же, если сайтов даже пусть 10, но у них трафика по 100 человек - то 5к на обслуживание этого всего при стоимости хостинга на тот же объем в 500 рублей - нецелесообразно.
Ну и по факту, на практике получается так, что абсолютно у всех хостеров бывают затупы и проблемы. Вопрос лишь только в том, как часто. Никакой тестовый период или отзывы не помогают, только долговременное использование покажет. Лучше, конечно, брать у тех, кто работает давно и меньше жалоб в инете или на профильных сайтах как этот серч, а дальше зависит от проекта и требований. Я для себя выбрал пару за многочисленные периоды и худо-бедно доволен.---------- Добавлено 27.07.2019 в 16:58 ----------
Так это может вопрос в нестабильности плагина, а не проблема с хостингом?
По сути еще раз указали кодировку базы.
Ну да ладно, главное, что нашли решение.
Перед CREATE TABLE IF NOT EXISTS ...
Будет
SET NAMES 'utf8'; CREATE TABLE IF NOT EXISTS ...
А, только там может быть по строке проблема с кавычками, тогда без них, просто
SET NAMES utf8; CREATE TABLE IF NOT EXISTS ...---------- Добавлено 26.07.2019 в 19:37 ----------Посмотрел, там для загрузки распарса другая команда:
$@ --local-infile=1 -e "USE $database; TRUNCATE $table; LOAD DATA LOCAL INFILE
Так что нужно в нее добавить names:
$@ --local-infile=1 -e "USE $database; TRUNCATE $table; SET NAMES utf8; LOAD DATA LOCAL INFILE ..
Попробуйте так изменить скрипт.---------- Добавлено 26.07.2019 в 19:42 ----------Ну и последнее, на самом деле импорт может быть проходит как положено. А вот выводится неверно. Часто на сайте для вывода используется указание этой же SET NAMES utf8; в сессии перед получением данных. Т.е. сначала открывается коннект к базе, затем указание кодировки, затем сам select данных.
