noindex

@denisco, есть задача для seo стилизовать h3 под текст. Чтобы начало абзаца начиналось с h3 и без видимого разделения продолжалось в виде обычного текста.

Вы намекаете на то что не пройдет html вадидация?

@flector,

относительно недавно поисковики стали требовать к индексации и стили и скрипты

IMHO, это для защиты с другого фронта, когда в отданном сервером HTML ссылок нет, а через JS они подставляются. Ссылки это как частный случай, там могут быть и редиректы и вирусы и т.д., в общем всё нежелательное что можно подтянуть через клиента не засвечивая в отданом HTML.
+ сейчас отдельные боты поисковиков оценивают качество сайта (пользовательские факторы, оптимизация картинок скриптов и т.д.), поэтому им уже нужно обрабатывать клиентскую часть как обычному браузеру. При этом они работают параллельно с ботами, которые клиентскую часть игнорят.

Поэтому в максимуме нужно постараться угодить всем ботам.

Тем временем я маленько переделал HTML/CSS по своей проблеме.
Получилось HTML:

<h1 class="show">Museums,<br/> Galleries, Exhibition Halls</h1>
<div class="h1Area"></div>

CSS

.content .mosaic .h1Area {
	float:left;
	height:100%;
}
.content .mosaic h1.show {
	margin:0;
	font-family:"MullerBold", Arial, "Helvetica CY", "Nimbus Sans L", sans-serif;
	font-size:30pt;
	line-height:30pt;
	color:#fff;
	letter-spacing:4px;
	text-transform:uppercase;
}
@media screen and (min-width: 971px) {
	.content .mosaic h1.show{
	position:absolute;
	right:100%;
	top:0;
	padding:25px 35px 16px 0;
	white-space:nowrap;
	word-wrap:normal;
	-webkit-transform-origin:100% 0;
	-moz-transform-origin:100% 0;
	-o-transform-origin:100% 0;
	transform-origin:100% 0;
	-ms-transform-origin:100% 53%;
	/* Переворачиваем текст */
	-webkit-transform:rotate(-90deg);
	-moz-transform:rotate(-90deg);
	-o-transform:rotate(-90deg);
	transform:rotate(-90deg);
	-ms-transform:rotate(180deg);
	}
}
@media screen and (max-width: 970px) {
	.content .mosaic .h1Area {
	display:none;
	}
	.content .mosaic h1.show{
	padding:0 0 16px 0;
	font-size:20pt;
	line-height:20pt;
	}
}

Всё вроде работает как нужно, но смущает конструкция

@media screen and (min-width: 971px) {...}
.....
@media screen and (max-width: 970px) {...}

Есть ощущение что не очень изящная конструкция.

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

У меня была мысль собрать этот набор CSS в одно условие, но этот код писал довольно опытный программист, и он даже с использованием @media screen max-width оставил 2 заголовка + на jQuery происходят не до конца понятные мне вещи.
Есть опасение что не всё так просто.

@flector, на сколько я понимаю, поисковики в массе своей игнорируют всё что происходит на клиенте (CSS/JS).
Соответственно он видит то что ему отдал сервер, а это 2 заголовка с указанием классов, что там с этими классами происходит, поисковику знать не нужно.

но вообще верстальщик херню сотворил, зачем было 2 заголовка то химичить, если можно в media запросы разные стили для одного заголовка запихнуть?

Черт его знает, может болел… 😉

В общем мысль я понял, попробую всё в одно условие загнать.

@flector, ну так-то да, многое от самого плагина зависит…

@flector, при чем тут база?
1. Память жрет wp-db.php, который отвечает за работу с базой
2. Тут субъективно конечно и я могу ошибаться, но данный плагин с файлами ничего на делает, значит деактивация привела только к изменению базы.

Итого = после изменений в базе, начал жрать память скрипт по работе с базой.
Такая вот нехитрая, но возможно ошибочная логика.

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

Господа, проблема решена.
Пришел настоящий программист, понаступав часок на мои грабли, догадался покурить сайт хостера (Мастерхост)….

В итоге заработало так (может кому в будущем пригодится):

RewriteEngine On
RewriteCond %{HTTP:PORT} !^443$
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

@flector, еще разок.
В какой момент и сколько раз нужно обновлять пермалинки и как?
Я уже раз 5 обновлял и пермалинки (нажимал кнопку «сохранить») и основную страницу настроек.
При ручном вводе HTTPS все ссылки работают корректно.
В пермалинках такая картина: http://prntscr.com/ew27yn
В основных настройках такая картина: http://prntscr.com/ew29a6

@flector, конечно нелогично.
Закачиваю на домен статичный сайт из 3-х php файлов, без базы.
Закачиваю туда такой htaccess

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Проверяю работу по HTTPS — всё ок.
Захожу на HTTP, получаю редирект на HTTPS — всё ок.

Какая в данном случае проблема у хостера?
Её нет — логично?

Закачиваю WP.
В htaccess добавляю строки, которые требует WP, в итоге получаем такой htaccess:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Проверяем сайт по HTTPS — все ок.
Заходим на HTTP — получаем циклический редирект.
Что изменилось в отличие от статично сайта?
Поставили WP и дописали в htaccess строки, которые он требует.
Вывод — проблема в связке «WP — директивы htaccess» — логично?

@yube, я конечно могу ошибаться, но разве в случае нормальной работы со статичным сайтом это важно?

Не подумайте что мне жалко, просто не понимаю какая может быть разница в какой переменной лежит признак HTTPS если без WP циклического редиректа нет, значит Apache понимает что юзер УЖЕ на HTTPS.
Скрин из phpinfo — http://prntscr.com/ew1e4x