Перейти к содержимому

12

В закрытом загончике обсуждают работу сотрудников Яндекса, выполненную в рамках РОМИП:

Это ключевая публикация Яндекса в этом году. Можно считать, что Яндекс владеет технологией подавления заимствованного контента, т.е. сформированы предпосылки приоритета контента в поисковом продвижении.

Слишком высокие эпитеты для обычной обзорной статьи. Да, предложены новые методы, но, как отмечено немного ранее и в другом месте, эти алгоритмы решают только одну часть проблемы: когда один и тот же документ (с возможно небольшими модификациями) отдаётся по разным URL. Для случая злостного спамера, специально значительно коверкающего копируемые тексты, эти алгоритмы не работают, или работают много хуже.

Второй аспект: ну определит Яндекс, что два документа с разных серверов являются дублями друг друга, а дальше что ? У него же нет достоверного способа узнать первоисточник (кто автор), -- просто в технологиях HTTP и HTML (да собственно ни в каком более-менее широко используемом протоколе или формате файла) не предусмотрено гарантированного и подтверждаемого третьей стороной указания даты публикации. Принимать решение в такой ситуации все равно, что бросать монетку.

7

Индексируя по-маленьку (см. Вершки Рунета), обратил внимание, что некоторые вебмастера, стараясь украсить страницы подопечных сайтов, используют нестандартные символы, указывая их, согласно рекомендации HTML4, в виде числовых ссылок на символы (&#nnn;).

Проблема заключается в том, что хотя в спецификации HTML4, явно указано:

Numeric character references specify the code position of a character in the document character set.

И хотя Википедия (по крайней мере английская) не делает различия между Character Set (набор символов) и Character Encoding (кодировка символов), для HTML (и XHTML, и XML), как подмножества SGML, это разные понятия. Поэтому использовать для числовых ссылок на символов кодовые значения символов из выбраной кодировки символов, как послупает большинство вебмастеров, вкорне не верно. Должны указываться коды символов в UNICODE, именно этот набор символов принят в SGML по-умолчанию.

Честно говоря, мне ни разу не встрачался документ в вебе, где явно указывался набор символов (отличный от UNICODE), но порывшись в Гугле, удалось отыскать пример такого объявления:


<!SGML "ISO 8879:1986"

CHARSET "... formal name for EBCDIC ..."
...
>
<!DOCTYPE book>
<book>
...

Кстати, в Tutorial: Character sets & encodings in XHTML, HTML and CSS на сайте W3C по этому поводу сказано более чётко:

NCRs, or Numeric Character References, and entities are ways of representing any Unicode character in XHTML / HTML using only ASCII characters.

...

One point worth special note is that values of numeric character references (such as &#x01F5; and &#501; for ǵ) are interpreted as Unicode characters - no matter what encoding you use for your document.

35

Ранее сообщалось об открытии компанией Google исходников OCR Tesseract. С тех пор проект движка OCR вылился в новый, более глобальный, проект OCRopus, в котором Tesseract используется в качестве плагина-движка для распознавания латиницы. И хотя на данных момент это единственный подобный плагин в проекте OCRopus, компания Google надеется в будущем добавить плагины для распознавания текста в других системах письмености, таких как кирилица или иероглифы.

В официальном блоге Google сообщается, что вывод в HTML у OCRopus получается несколько лучше, чем у коммерческих систем распознавания. Правда с оговоркой правильного расположения на планшете сканера листа распозноваемого документа.

9

Компания Morfik, стартап с Тасмании (Австралия), запатентовал технологию компиляции в HTML и JavaScript с языков программирования высокого уровня.

Технология JavaScript Synthesis Technology, используемая в Morfik's WebOS AppsBuilder разрабатывалась более 6 лет, с 2000 года. Разработчики надеются, что эта технология позволит облегчить переход к Web 2.0 для крупных компаний с уже созданными информационными системами.

//Australian IT

27

Начав поближе разбираться с WordPress'ом сразу столкнулся с необходимостью руссификации его тем. Применение решения "в лоб" связанное с прямым переводом отображаемых слов в исходниках мне как-то не импонирует. А столкнувшись с приятной возможностью локализации в теме Binary Blue я понял, что это то что надо. Немного поигравшись с новыми возможностями, я перешёл к другой теме и попробовал таким же образом руссифицировать и её. Не тут-то было!

...читать далее "Руссификация тем WordPress’а"

10

На поисковых серверах «Весь интернет Сочи» и 43°с.ш. 39°в.д. произведён апгрейд поддержки спецификации OpenSearch до версии 1.1 Draft 2.

Теперь вы можете на страницах вашего сайта добавить атоопределение поиска по нему (если ваш сайт проиндексирован нашей поисковой машиной). Для этого необходимо в заголовок ваших HTML страниц добавить:


<link type="application/opensearchdescription+xml" rel="search"
                 href="http://sochi.org.ru/opensearch-en.oxml" />

10

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

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

С точки зрения электронного мозга поискового робота, суть страницы (о чём собственно эта страницы) определяется следующим образом: если страница начинается некоторыми словами, эти слова встречаются во всём тексте страницы, и этими же словаим страница заканчивается, - весьма вероятно этими словами и описывается то, о чём эта страница. Покажем на примере, как используя CSS можно максимально извлечь выгоду из такой схемы работы поисковых машин, и при этом не нарушая схему визуального расположения блоков на экране броузера.


<html>
<head>
Вставьте все ваши заголовки, включая ссылку на CSS аналогично указаному ниже
<link rel="stylesheet" type="text/css" href="file.css" />
</head>

<body>
<div id="content"> < !–Объяснение этому div ниже–>
<h1>Заголовок с ключевыми словами</h1>
<h2>Подзаголовок с ключевыми словами</h2>
<p>Место для вашего контента. Обратите внимание, насколько близко он расположен к началу кода вашей страницы, независимо от того, где он будет отображаться на экране броузера.</p>
</div> < !–This would be the end content div–>

<div id="nav"> < !–Пример div представляющего навигацию сайта–>
<p>Навигация может содержать как картинки-кнопки, так и текстовые сслыки, а может и то и другое. При табличном дизайне, обычно этот раздел располагается в HTML-файле выше контента, теперь же он ниже, где и должен быть.</p>
</div>

<div id="banner">
<p>Как следуюет из названия раздела, обычно он располагается на экране броузера в верху страницы, а при табличной вёрстке -- в самом начале файла. Т.к. зачастую этот раздел не содержит полезной для SEO информации, это опредленно не тот код, который поисковый робот должен видеть первым на вашей странице.</p>
</div>

<div id="summary">
< !–Этот div может содержать что угодно, дан здесь для примера–>
<p>Это пример, ислюстрирующий один из принципов SEO. Используйте здесь ваши ключевые слова, появляясь в конце страницы, они делают вашу SEO лучше.</p>
</div>

</body>
</html>

Далее покажем, как в фале file.css управлять раположением блоков. Для простоты показано только управление расположением, без указания шрифтов, цветов, размеров и прочего. В HTML коде выше задано четыре размела (div), мы можем указывать их расположените на экране в пиксела или процента. Будем использовать пикселы для простоты.


/*Начало CSS*/

#nav {position: absolute;
top: 0px;
left: 0px;
width: 200px;
height: 500px;
padding: 20px 10px 10px 20px;
}

/* Для наглядности, разделы в файле стилей указаны в другом порядке, нежели в фале HTML. Стиле разделов указываются в порядке построения структуры отображения документа на экране брооузера, это примерно соответсвет порядку следования блоков при табличной вёрстке страницы. Этот раздел навигации привязывается к левому верхнему углу окна броузера. Указаная ширина в 200 пикселей равна ширене ячейки таблицы при табличной верстке. Высота в 500 писелей выбрана произвольно для примера. Раздел summary, описаный ниже будет распологаться ниже того места, где заканивается раздел навигации. Вы должны убедиться, что все элементы оаздела помещаются в указаные вами размеры, и изменить эти размеры по мере необходимости. Также как и при табличной вёрстке, вы можете задавать отступы от края раздела, в примере выше - это 20 пикселей сверху и слева, и 10 писелей справа и снизу.*/

#summary {position: absolute;
top: 500px;
left: 0px;
width: 200px;
padding: 20px 10px 10px 20px;
}

/* Раздел summary начинается там, где заканчивается раздел навигации, в 500 пикселей от верхнего края. Остальные параметры указаны так, чтобы выравнивание было ровным. Высота не указана, поэтому размер будет подобран по содержимому аналогично ячейке таблицы при табличной вёрстке.*/

#banner {position: absolute;
top: 0px;
left: 200px;
width: 550px;
height: 150px;
padding: 20px 0px 10px 20px;
}

/* Заголовок распологается вверху страницы, но в 200 пикселях от левого края, там, где заканчиватся раздел навигации. Указывать высоту необязательно, но указав, можно задать, где будет начинатся основной контент страницы. Значение высоты в 150 писелей указано для пример. Отстут справа задан нулевым, т.к. остальная часть экрана правее будет пуста, т.е. отступать не от чего. Ширина задана исходя из того, чтобы всё умещалось в разрешении 800х600 (суммарная ширина 750 пикселей).*/

#content {position: absolute;
top: 150px;
left: 200px;
width: 550px;
padding: 10px 0px 10px 20px;
}

/* Наконец, контент начинается там, где заканчивается заголовок и навигация, в 220 пикселя от левого края и в 150 пикселях от верхнего.*/

/*Конец CSS*/

//SearchEngineJournal

50

Разгребая в очередной раз авгиевы страницы сочинcкого инета подумалось, а сколько сайтостроителей читало, к примеру, рекомендации Google для вебмаcтеров ? Явно же делают всё наоборот...

На всякий случай приведу некоторые из них.

Рекомендации по дизайну и контенту

  • Создавайте сайт с чёткой структурой и текстовыми ссылками. Каждая страница должна быть достижима хотя бы по одной статичной текстовой ссылке.
  • Создавайте для пользователей карту сайта. Если карта сайта содержит более 100 ссылок, разбивайте карту на страницы.
  • Создавайте полезный и информативный сайт; создавайте страницы чётко и аккуратно описавающие ваш контент.
  • Подумайте, по каким словам искали бы пользователи ваш контент и убедитесь, что страницы вашего сайта содержат эти слова.
  • Старайтесь использовать текст вместо картинок для вывода важных наименований, контента или ссылок. Помните, пауки Google не понимают текста, выводимого в изображениях.
  • Убедитесь, что ваши тэги TITLE и ALT наглядны и аккуратны.
  • Проверьте все ссылки, не биты ли они; проверьте HTML код ваших страниц.
  • Если вы решаете использовать динамические страницы (т.е. URL которых содержит '?'), учитывайте, что далеко не каждый поисковый робот воспринимает такие страницы также, как и статические страницы. Полезно давать параметрам динамических страниц короткие имена и постараться сохранить число параметров малым.
  • Число ссылок на странице должно быть разумным (менее 100).

Технические рекомендации

  • Используйте текстовый проузер, например Lynx, для проверки вашего сайта, так как большинство поисковых роботов видят сайт примерно таким, как он выглядит в Lynx. Если различные фичи вроде кук, JavaScript, фреймов, идентификаторов сессий, DHTML или Flash не позволяют полноценно просматривать ваш сайт в текстовом броузере, весьма вероятно поисковым роботам также будет затруднительно проиндексировать ваш сайт.
  • Позвольте поисковым роботам передвигаться по вашему сайту без использования идентификаторов сессий, переменных или кук, отслеживающих движение пользователей по сайту. Эти технологии полезны для отслеживания поведения обычных пользователей, поведение поисковых роботов совершенно другое. Они также могут привести к неполной индексации сайта, т.к. поисковый робот не сможет вычислить различные URL, указывающие на одну и ту же страницу.
  • Убедитесь, что ваш веб-сервер поддерживает HTTP заголовок If-Modified-Since. Эта фича позволит вашему веб-серверу указать роботу Google, изменилась ли ваша страница с момента предыдущего посещения. Что также умешит нагрузку на ваш сервер и сократит объём передаваемых данных.
  • Используйте файл robots.txt на вашем сервере. Этот файл говорит роботам какие директории могут или не могут быть проиндексированы. Также проверьте, не блокирует ли случайно текущая версия этого файла на вашем сайте его индексирование роботом Google. См. http://www.robotstxt.org/wc/faq.html как правильно составлять этот файл.
  • Если ваша компания покупает CMS (систему управления контентом), убедитесь, имеет ли эта система может выводить контент в доступном для поисковых роботов виде.
  • Не используйте параметр "&id=" в ваших URL, т.к. наш робот не индексирует подобные страницы.