Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - FOX

Страницы: [1] 2 3 ... 5
1
на 5 сайте полоса под шапкой привязана к левому краю и при больших разрешениях съезжает.

2
Общие вопросы / Re: Фиксирована ширина сайта
« : Апреля 03, 2012, 04:00:52 pm »
А где должен быть блок поиска и какой текст сполз?
Если Вы планируете менять дизайн, то без элементарного знания CSS ничего не получится. Либо нужно учить, либо обратиться к тем кто выучил!

3
Общие вопросы / Re: Фиксирована ширина сайта
« : Апреля 03, 2012, 03:30:20 pm »
Замените в #container - width: 100%; на  width: 1000px; и все, будет фиксированный ;)

4
Общие вопросы / Re: Фиксирована ширина сайта
« : Апреля 03, 2012, 01:12:48 pm »
У вас резиновый макет, а на примере http://shop.4x4tet.ru/ - фиксированный.
Сформулируйте конкретнее вопрос, что значит подстраиваться под размер изображения? Ниче ж не понятно!

5
Черт его знает. Это уже может попадать под определение клоакинга, т.к. мы пользователю и роботу будем отдавать разные страницы. В данном случае /404/, но можно ведь и другую.....

6
У меня подобное сделано на  PHP + если в url присутствует верхний регистр возвращаем "404"

if((!isset($_GET['searchstring'])) and ($_SERVER['REQUEST_METHOD']=="GET"))
{
$reqUrl=$_SERVER['REQUEST_URI'];
$reqUriLen=strlen($reqUrl);
$lasSymb = $reqUrl[$reqUriLen-1];

if (preg_match("/[^a-z,0-9,\/,\-,\_]/", $reqUrl))
{ header("HTTP/1.0 404 Not Found");
header("location: /404/");
exit; }

if($lasSymb!="/"){ header("HTTP/1.1 301 Moved Permanently"); header("location: $reqUrl/");
exit;
}
}

7
Думаю основное это работа над контентом, статьи обзоры, описание интересное, не гуглу! набитое тупо ключевиками, а для людей. тем более что поговаривали(правда ещё летом) о интелектуальном распознавании контента поисковыми системами. хотя это, пожалуй, понты, обычный просчёт плотности ключевых слов.
ну как то имхо моЁ жизневиденье.
За это и боремся! Чтобы написанная статья была в единственном экзампляре, на одной единственной странице, а не 20-ти дублях. К тому же наличие дублей сильно снижает скорость переиндексации всего сайта в целом и вхождения нового контента в индекс в частности. Так, что сам контент это не единственное над чем нужно задумываться, ИМХО!
В панели вебмастеров Гугл кричит:" У вас повторяющиеся страницы! Надо шо-то решать!" Но при этом, сам пихает в индекс кучу мусора и зубами его от туда не вырвешь!
По поводу интеллектуального распознавания контента - не верю! У моих конкурентов прямых вхождений ключей до 30% доходит, текст вообще не возможно читать! Сплошной <strong>! И при этом, что Яша, что Гугл держит их в ТОП-1,2,3. Хотя там тоже движки не без проблем и дубли можно плодить пачками, но в индексе их нет!
Кстати заметил такую штуку - два сайта на одинаковых движках могут вести себя по разному. Один индексируется как по нотам, а на другом сплошная хрень лезет. ХЗ, объяснить это никак нельзя.

9
Решил создать отдельную тему, т.к. вопрос очень важный и объемный.
Последние исследования на основании своих сайтов, которые подтверждаются многими вебмастерами, показывают, что Гугл напрочь игнорирует robots.txt. Для него этот файл носит не более чем рекомендательный характер, но не как не запрещающий роботу какие либо действия на сайте. Действительно, кто мы такие, что бы управлять самим Google?

Это подтверждает и сама ПС. Вот цитата из справки для вебмастеров от Google:
Цитировать
Google больше не рекомендует блокировать доступ поисковых роботов к повторяющемуся контенту с помощью файла robots.txt или иных способов. Если поисковые системы не имеют возможности сканировать страницы с повторяющимся контентом, то они не смогут автоматически определять, что разные URL имеют одинаковый контент, и будут обращаться с ними как с уникальными страницами. Наилучший выход из этого положения – разрешить поисковым системам сканировать все URL, предварительно отметив их как повторяющиеся с помощью элемента link rel="canonical", функции обработки параметров URL или переадресации 301. Если на вашем сайте очень много страниц с повторяющимся контентом, рекомендуется настроить скорость сканирования в Инструментах для веб-мастеров.
Наличие на сайте повторяющегося контента не является основанием для принятия каких-либо мер по отношению к нему. Такие меры применяются только в том случае, если это сделано с целью ввести пользователей в заблуждение или манипулировать результатами поиска. Если у вас возникают проблемы из-за повторяющегося контента, но вы не последовали приведенным выше советам, то мы выберем версию контента для показа в результатах поиска на свое усмотрение.
Зявление о том, что дублированый контент не является основанием для принятия мер, думаю, можно поставить под сомнение!

Что мы в итоге имеем?
Google питается собрать о сайтах всю доступную информацию, а не только то, что ему отдают вебмастера.
Это мотивируется кагбэ, тем что сайты могут распространять вирусы и прочие прелести, направленые на принесения вреда или обман пользователя, а для ПС такие сайты белые и пушистые.  Т.о. при индексации Гугол не смотрит ни на   robots.txt  ни на rel="nofollow". Это канешно хорошо, но почему мои технические разделы должны попадать в индекс???

Что делать?
По сути остается единственный способ закрытия не подлежащих индексации разделов, блоков, ссылок и контента является Jawascript. Такой подход нельзя расценивать как клоакинг т.к. и пользователям и ПС предоставляется одинаковое содержимое, просто ПС не может его проиндексировать.
Есть еще rel="canonical", но он опять таки носит не более чем рекомендательный характер, хотя использовать его все же стоит.

По Jawascript. я уже поднимал вопрос. Я пока еще мало разбираюсь в технических моментах реализации этого дела.
Но решать вопрос нужно! Причем всем!

11
Спасибо

12
Подскажите как,  прописать нормальные мета теги в /news/

13
меня интересует именно LiqPay. Вот ссылка на то, что нужно прикрутить https://liqpay.com/?do=pages&p=cnb12

14
я так понимаю что речь о LiqPay
Насколько проблематично такое прикрутить? Сейчас пытаемся наладить работу с Приватом и они требуют установить оплату через эту штуку.

15
А вам не кажется, что лучше придумать как реализовать этот момент на уровне PHP? А то .htaccess итак не маленький и каждое новое условие, которое нужно проверять, будет все больше тормозить движок!

Страницы: [1] 2 3 ... 5