smscat

smscat
Рейтинг
50
Регистрация
23.02.2006
A&J:
Подскажите плиз кто знает. Сайт раньше был в кодировке win 1251, а сейчас сайт перекодирован в UTF8. Как это может отразиться на продвижении. Поисковики его нормально будут читать?
И вобще какие могут быть подводные камни?

Заранее благодарен за ответы.🙄

если кодировка указанна корретно, то прблем не будет. (как пример _aratta.ua_)

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

Newbie:
Ну вообще-то, это каталог Гугла, там не все сайты можно просмотреть :) Тем более там нет сайта http://rezba.h16.ru/ 🚬

конечно. но ведь я отвечал на

Newbie:
А можно узнать, где это на странице Гугла показывают ПР? Может сервис какой-то? Так он не Гугловский.

и ответил точно - тулбар это Гугловский сервис, и страницы Гугла, показывающие ПР существуют.

Если на страницах каталога можно найти не все сайты, то тулбар, произведённый гуглом показывает значения взятые им легально из сервиса на ДЦ предназначенного специально для этого. Ниужели можно ожидать более надёжный источник? Или вы считаете, что тулбар предназначен для обмана SЕО? =)

Newbie:
BigDaddy - это программное обновление, которое должно помочь улучшить качество поиска. Практически все датацентры уже перешли на него, оставшиеся перейдут до следующей недели. (с) Matt Cutts

Во первых про то, что это чисто програмное обновление ничего небыло, в том числе у Катса.

Во вторых поменять "чисто программу" очень быстро даже в их масштабах.

В третьих я тоже читал у него неделю назад, что апдэйты ещё на 2 недели, но результаты показали, что уже неделю как все ДЦ откатили на старую неточную базу с глюками, что вкупе с временем обновления говорит об изменениях структуры, а не только алгоритма.

А Мэт человек публичный и не подписывался давать точную инсайдерскую информацию - неделю мог взять про запас, чтобы не пеняли в отставании от графика если что. =)

Sergey T:
Т.е. алгоритм формирования результатов поиска не поменялся? Изменилась форма хранения информации?

этот вопрос открыт. если CVS действительно имеет место, то алгоритм наверняка поменялся. некоторые изменения выдачи были заметны ещё когда запустили первые 3 BigDeady но сфрмулировать разницу трудно. пока маловато информации.

cims:
И делать сайты как мне кажется надо проще и удобнее для пользователя, т.е. не перегружать излишними скриптами. К тому же в простоте кода заложена и быстрая правильная индексация ваших страниц.

включение стороннего javascript индексацию не ухудшает, а вот ваш пример

width:expression((document.documentElement.clientWidth||document.body.clientWidth)<950?'950px':'auto');

работает только в IE.

вы имхо зря рубите с плеча не разобравшись. я сам не сторонник ставить лишние javascript, но в некоторых случаях выбора нет - как например _ostrov.zp.ua_ , где в основе использован XHTML + CSS, а ширина регулируется через javascript и это работает в большинстве браузеров (не везде было возможно проверить)

транслит и киргуда (набор не в той раскладке) яндексом отлавливались чуть ли не с самого начала. там стоит сложная машинка, которая примеряет слова в разных вариантах по словарю - включая киргуду, когда путаешь букву "с"

проверьте на любом транслите - всё станет понятно.

по отрывочным сведениям сложилась следующая картина:

1. BigDeady это апаратно-программный комплекс построенный на AMD-64 и соответствующем доработаном релизе линукса. (соответствующий шум про закупку 200к этих процессоров гуглом был в прессе)

2. поменялась структура кэша - блоки с 64M изменились на какое-то бОльшее значение (узнать его не удалось). но прямая конвертация старого кэша у них не получилась, откуда и нынешние глюки.

3. есть информация, что они попытались использовать постреляционную модель храниения кэша - что-то типа CVS. пока не удалось определить запросы на получение истории кэша, так что это лишь вилами по воде.

4. поменялась структура работы центра google-toolbar и возможно данные этой уилиты используют в алгоритме ранжирования (пока не проверено)

a.fatman:
Все бы хорошо, да самый популярный браузер не понимает это свойство.

правда. потому мне и пришлось юзать яваскрипт. зато обошёлся без таблиц.

a.fatman:
Когда-то у меня на сайте была возможность выбора ширины -- данные сохранялись в cookie.

конечно это дело вкуса, но я против навязывания пользователю размера страницы. считаю, что динамический выбор в зависимости от ширины окна - самое правильное решение.

a.fatman:

Это вообще просто -- две таблицы стилей и переключатель, хоть на php, хоть на js.

php это на стороне сервера - легко не попасть. вот яваскрипт действительно гибче.

psylosss:
smscat, какой нафиг бан? вы о чем?
всем роботам и браузерам по дефолту он выдает один и тот же мета. А меняет он его в зависимости от выбора пользователя.

а зачем пользователю мета? 😆

зато модеры яндекса легко увидят разницу в индексе и в браузере и примут меры - будьте спокойны.

psylosss:
Раз уж на то пошло, что, по-вашему, один и тот же урл не может выдавать разные данные? А как же POST-переменные или куки? :)

а вы видели индексированными такие страницы?

или вы просто хотите чтобы проиндексированным был ОДИН язык, а остальные поисковик не видел?

вот специально для поисковика с его ботом, который ничего кроме своего имени не передаёт ЖЕЛАТЕЛЬНО делать все публичные страницы доступными через GET иначе смысл теряется (мы ж на форуме оптимизации, а ваш рецепт делает данные недоступными поисковику)


$keyword = url_decode('%F8%ED%E5%EA');
.....
sub url_decode{
my $s=shift;
$s =~ s/%([0-9A-Fa-f][0-9A-Fa-f])/chr hex $1/ge;
$s =~ s/\&.*//;
$s =~ s/\+/ /g;
return $s;
}

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

Всего: 307