четверг, февраля 4

Получаем курсы валют (класс для PHP)



В очередном проекте встала тривиальная задача вывода курсов валют на страницах сайта. Но стандартные информеры курсов валют очень портили дизайн сайта, вследствие чего я решил написать парсер курсов валют с сайта Центрального Банка Российской Федерации.

В последнее время, я перешел на разработку проектов на Zend Framework, поэтому представленная реализация заточена для использования в PHP приложениях на ZF.

Итак, начнем с самого класса. Здесь все просто:
  • есть public метод getValuta, который принимает буквенный код валюты и выдает ее курс относительно рубля
  • он обращается к защищенному методу getXML, который инициализирует объект класса Zend_Rest_Client для обработки XML данных с курсами валют
  • getXML проверяет наличие закэшированной копии данных и в зависимости от результата проверки создает новый кэш данных и читает оттуда курсы, либо обращается к существующему; делается это с помощью методов getNewXML и getOldXML соответственно.
Исходный код файла Kursi.php
  1. /**
  2. *
  3. * @author Jacob Akulov (Яков Акулов)
  4. * @desc Модель получения курсов валют по данным ЦБ РФ
  5. *
  6. */
  7. class Kursi {
  8. protected $_name = 'Kursi';
  9. protected $valutaClient;
  10. // определяем допустимые коды валют
  11. protected $valutaCodes = array(
  12. 'R01235'=>'USD',
  13. 'R01239'=>'EUR',
  14. 'R01035'=>'GBP',
  15. 'R01090'=>'BYR',
  16. 'R01335'=>'KZT',
  17. 'R01375'=>'CNY',
  18. 'R01720'=>'UAH'
  19. );
  20. //контруктор класса
  21. public function __construct() {}
  22. // получение курса вылют по коду
  23. public function getValuta($code) {
  24. self::getXML(); // получаем данные в виде XML (заносятся в объект Zend_Rest_Client, $this->valutaClient)
  25. // проверяем допустимость кода валюты
  26. if (!in_array($code, $this->valutaCodes)) {return false;}
  27. else {
  28. if($this->valutaClient) {
  29. $values = $this->valutaClient->key('Valute')->get()->Value(); // получаем значения курсов всех валют
  30. $codes = $this->valutaClient->key('Valute')->get()->CharCode(); // получаем их коды
  31. $currency = array_combine($codes, $values); // совемещаем все это в один масссив
  32. return $currency[$code]; // и выдаем результата
  33. }
  34. else {
  35. return false;
  36. }
  37. }
  38. }
  39. // создание клиента для обработки XML с курсами валют
  40. private function getXML() {
  41. // проверяем наличие кэшированной XML
  42. if(file_exists('public/kursi/valuta-'.date('Y-m-d').'.xml') && file_exists('public/kursi/metall-'.date('Y-m-d').'.xml')) {
  43. self::getOldXML(); // берем данные из кэша
  44. }
  45. else {
  46. self::getNewXML(); // иначе загружаем данные с сайта ЦБ РФ и кэшируем их
  47. }
  48. }
  49. // получение данных с сайта ЦБ РФ и создание локального кэша
  50. private function getNewXML() {
  51. $val = file_get_contents('http://www.cbr.ru/scripts/XML_daily.asp'); // читаем данные из ЦБ РФ и пишем их в кэш
  52. file_put_contents('public/kursi/valuta-'.date('Y-m-d').'.xml', $val);
  53. // создаем REST клиента и получаем данныые
  54. $this->valutaClient = new Zend_Rest_Client('http://sitename/public/kursi/valuta-'.date('Y-m-d').'.xml');
  55. }
  56. // получение данных из кэша
  57. private function getOldXML() {
  58. $this->valutaClient = new Zend_Rest_Client('http://sitename/public/kursi/valuta-'.date('Y-m-d').'.xml');
  59. }
  60. }
* This source code was highlighted with Source Code Highlighter.


В данной реализации время обновление кэша будет в полночь по времени веб-сервера. Я не знаю, когда там Центробанк обновляет курсы, поэтому решил оставить так. Также в моем классе не предусмотрено удаления старых кэш копий XML файлов, т.к. в моем проекте есть сборщик мусорных файлов, который запускается по cron-у.

Дальше, после создания модели (класса) в реализации на Zend Framework мы создаем контроллер и вьюху (просто для наглядног представления результата). Они очень простые и не требует дополнительных пояснений:

Контроллер:
  1. class KursiController extends Zend_Controller_Action
  2. {
  3. function init() {
  4. $this->config = Zend_Registry::get('config');
  5. // загружаем класс для получения курсов
  6. Zend_Loader::loadClass('Kursi', $this->config->path->models_dir);
  7. // создаем его объект
  8. $this->kursi = new Kursi();
  9. }
  10. // экшн
  11. function indexAction() {
  12. // передаем во view сразу значения валют
  13. $this->view->assign('USD',$this->kursi->getValuta('USD'));
  14. $this->view->assign('EUR',$this->kursi->getValuta('EUR'));
  15. }
  16. }
* This source code was highlighted with Source Code Highlighter.





View:
  1. <ul class="kursi">
  2. <h3>Курсы валютh3>
  3. <li><span>$ Доллар СШАspan> <b>=$this->USD?>b>li>
  4. <li><span>€ ЕВРОspan> <b>=$this->EUR?>b>li>
  5. ul>
* This source code was highlighted with Source Code Highlighter.




В результате при обращении к созданному контроллеру получаем такой вывод:


Вы также можете скачать класс Kursi.php. С удовольствием приму ваши замечания и улучшения для описанного скрипта.

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

среда, января 27

Результаты эксперимента с хостингом картинок



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


И простой поиск по тому же запросу ("румба в тумбочке"):


Везде выше в поиске ранжируется страница, на которой размещена картинка, которая хостится на самом сайте. А страничка с картинкой, которую я залил на Яндекс.Фотки (т.е. внешний хостинг) в поиске оказалась ниже.

Вот собственно и весь эксперимент с его результатами.


Кстати, я сменил место работы - теперь я занимаюсь честным продвижением сайтов :-)

четверг, декабря 3

Где хостить картинки для сайта?

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



Так как встретился с проблемой high-load проектов, которые при этом должны быть грамотно спроектированы с точки зрения SEO, то решил проверить все в очередном эксперименте:
на известном нам подопытном сайте сделали две странички:
1. про
блюдо румба в тумбочке,

На первой странице иллюстрация грузится на сайт с моего аккаунта Яндекс.Фоток, а на второй - с самого сайта.

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

Для чистоты эксперимента я постарался сделать страницы одинаково релевантные и взял картинки по возможности не относящиеся к запросу никак, прописал одинаково релевантные альты и сделал изображения одного размера.

понедельник, июня 8

Первые результаты эксперимента с формами и SEO


Есть первые результаты эксперимента с использование атрибутов alt и title в тегах input, расположенных в формах на страницах. Результат подтвердил предположения того, что поисковики могут учитывать текст в таких атрибутах при ранжировании результатов поиска.

Такая вот выдача присутствует в Яндексе на данных момент:

На первом месте страница, где были использованы атрибуты alt, на втором - title, а на третьем страница, где не использовались атрибуты у тегов input. В атрибутах встречалось слово механизм, что и повлияло на выдачу.

Для чистоты эксперимента теперь переставим атрибуты alt на третью заявку, а title - на первую, тогда как вторая заявка останется без атрибутов. И после переиндексации страниц посмотрим на изменения в выдаче.

Далее еще планируется поэкспериментировать с тегом label

воскресенье, июня 7

Результаты эксперимента по <H1>, <H2>


В эксперименте мы задались вопросом о том, как правильно с точки зрения SEO располагать теги заголовков на страницах, ну и стоит ли их вообще использовать.

Результаты выдачи по исследуемому запросу приведен ниже.
На первом месте стоит страница, где тег H1 стоит внизу, после тегов H2. На втором страница с последовательным использованием заголовков. На третьем ожидаемо - страница без заголовков.

Также хочется отметить особенности формирования сниппета. Обратите внимание на первую позицию: в сниппете два пассажа, один из которых не содержит ни одного ключа (вероятно он попал в описание из-за того, что выделен жирным). А если взглянуть на саму страницу, то мы увидим такую картинку:
Очевидно, что заголовок H1 содержащий только фразу "Трассировка нечеткого графа" выделен Яндексом в одельный пассаж (хотя и не отделен разделителем). Но данный пассаж не включен в сниппет, скорее всего из-за того, что в большой степени повторяет title страницы, или еще из-за того, что не содержит других слов, кроме как слов поискового запроса (или слов, содержащихся в title).

Если посмотреть на сниппеты других страниц, то видно, что там пассажи, содержажиеся в заголовках H2 включены в сниппет - они содержат слова, которые не содержутся в title страницы (или в запросе).

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

суббота, июня 6

<strong>, <b>, <i>


Есть рузультат эксперимента с тегами выделения ключевых слов. Яндекс таким образом распределил результаты:

Если вы взлянете на код страничек, то найдете следующий порядок следования тегов:
<strong>, <b>, <i>

Я не думаю, что открыл здесь Америку, все это было известно и до меня. Просто такой вот наглядный опыт.

Региональная выдача в Яндексе


Много воды утекло после знаменитого Арзамаса Яндекса и появления его новой региональной выдачи. Теперь результаты поиска различаются для пользователей системы из разных регионов России. Все это здорово переполошило сеошный мир - многие оптимизаторы начали терять трафик с Яндекса из-за резко изменившейся региональной выдачи, искать пути обхода нового алгоритма.

Смысл нового алгоритма Яндекса заключается в том, чтобы выдавать пользователю результаты поиска релевантные не только самому запросу но и "подходящие" ему по его региональной принадлежности. Но как оказалось на поверку, новый алгоритм поисковика очень и очень слабо справляется с этим определением "подходящности" сайта по региону. Практически по всем коммерческим запросам на своих позициях в региональной выдачи остались "раскрученные" московские сайты.

Но вот мое недавнее обнаружение: сайт www.proland63.ru, предлагающий услуги ландшафтного дизайна в Самарской области (точнее в Тольятти) неожиданно появился в топ-10 Яндекса по запросу "ландшафтный дизайн" при поиске из региона. Хотя при поиске в остальных регионах, вот пример из Москвы, сайт отсутствует даже в топ-100.

и выдача по Самаре:
Что интересно, вот тот же поиск, но с галочкой "в Самаре":
Сайта нет в этой выдачи, т.к. он просто не привязан к региону Самара. При вязан он к региону Тольятти:
Но по поиску Арзамаса остается в топ-10 как при поиске из Самары, так и при поиске из Тольятти (без галочек). Правда, говоря сайт можно найти при поиске "ландшафтный дизайн в Самаре" (сечас на 13 позиции).

А теперь - САМОЕ интересное наблюдение (слева запрос):

ландшафтный дизайн (по региону Тольятти):






ландшафтный дизайн в Тольятти:







ландшафтный дизайн в Самаре:



Обратите внимание, всюду, рядом с www.proland63.ru присутствует floradiz.ru. Оба эти сайта продвинуты примерно одинаково, имеют сопоставимые позиции в ПС, находятся в одном разделе ЯК. Но при поиске по запросу "ландшафтный дизайн" без привязки к региону (но из региона "Самара" или "Тольятти") сайт proland63.ru присутствует в выдаче (причем высоко), а floradiz.ru невозможно найти в даже первой сотне.

В чем же различие между двумя сайтами?

С первого взгляда видно, что proland63.ru оптимизирован явно под запросы с поиском в Тольятти: "ландшатный дизайн в Тольятти", "озеленение в Тольятти" и т.п. Сайт floradiz.ru внутренне оптимизирован под общие запросы, а внешне также под запросы ".. в Тольятти", и в выдаче выдается как "найден по ссылке".

Но это не главное отличие - основным и, как мне кажется, решающим фактором, является различие в методах поискового продвижения. Попробуйте поискать ссылки на сайт floradiz.ru - вы найдете много (более сотни), достаточно много для продвижения в посути неконкурентной тематике, ссылок. И практически все они с каталогов. Да, каталоги тематические - это хорошо для продвижения, но асолютное большинство каталогов характерны тем, что не привязаны к региону, или привязаны, но не к тому, в котором продвигается сайт.

Теперь ищем ссылки на proland63.ru - хорошо, если вы смогли найти более 10 сайтов. Потому что на данный момент на него ссылается всего 15 сайтов (по данным Яндекс.Вебмастер). Зато почти все эти ссылки из статей. Причем, стоит обратить внимание, что статьи размещены пусть не на самых тематических сайтах, но зато подходящих для продвижения именно по региону. 14 из этих 15 сайтов привязаны либо к региону Тольятти, либо к Самаре.

Наверное, это один из способов более эффективного продвижения в Арзамас. Пока это один из всего лишь нескольких успешных примеров, но, мне кажется, в этом есть перспектива. Похоже, статьи действительно рулят. И региональный сайт вполне можно поднять в топ по очень конкурентным запросам для своего региона. Правда складывается впечатление, что здесь есть доля случая, да и в зависимости от конкурентности запроса, статей, подобных тем, что сделаны для proland63.ru необходимо разместить от 50 до 100 штук на региональных сайтах - что зачастую очень накладно.

В завершении скажу, что хоть сайт по запросу "ландшафтный дизайн" выдается в топе только по Самарской области, но уже одно это повысило трафик на сайт с Яндекса на 70%.

Будем продолжать эксперименты и наблюдения. Желаю всем удачи в продвижении сайтов в регионах.

----

Попробуем подняться повыше :) - ландшафтный дизайн.


Пример персонализированного поиска Google


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

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

На днях обнаружил яркий пример персоналированной выдачи. Вот пример поиска через аккаунт Google и без него:

обратите внимание, что Google не говорит, что результаты изменены поисковиком для меня. Просто изменяет выдачу. Мы видим, к примеру сайт www.allcement.ru присутствует на первой странице при поиске с историей и отсутствует при простом поиске (точнее находится только на второй странице). Есть и другие небольшие изменения.

В чем причина таких изменений?

Обратите внимание на данный скрин.
Здесь мои запросы к Google, связанные с запросом "цемент оптом". Так, например сайт www.allcement.ru более релевантный большинству из этих запросов (цемент Самара, цемент Казань и т.п.), чем остальные сайты в выдаче по запросу "цемент оптом". Возможно поэтому, данный сайт в выдаче по запросу "цемент оптом" выводится на первой странице при использовании моей истории поиска и на второй без истории.

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

Что это означает для оптимизатора?

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

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

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

Буду рад вашим мнениям по данной теме.


Постоянные читатели