Flash / HTML архитектура: последствия для SEO? - PullRequest
2 голосов
/ 10 июня 2011

У моего клиента есть полнофункциональный Flash-сайт и HTML-сайт (WordPress).В настоящее время сайт HTML находится на http://www.domain.com,, а сайт Flash - на http://www.domain.com/flash (обнаружение swfobject на http://www.domain.com перенаправляет пользователей Flash на URL-адрес флэш-памяти).Клиент не совсем доволен этим соглашением с точки зрения SEO, так как ссылки на его сайт иногда указывают на http://www.domain.com, а иногда на http://www.domain.com/flash.

Через несколько недель клиент будетразвертывание новой версии их Flash-сайта, который включает в себя, помимо прочего, диплинкинг.Вместо того, чтобы жить в своей собственной папке вне домена, сайт с полной версией Flash будет «прогрессивно улучшенной» версией сайта HTML, поэтому, если пользователь поддерживает Flash, весь контент HTML будет заменен содержимым Flash.

После запуска нового сайта каждая страница / URL на сайте Flash будет иметь соответствующую HTML-страницу / URL;например, содержимое Flash на http://www.domain.com/#/about/clients соответствует содержимому HTML на http://www.domain.com/about/clients.

Мы собираемся реализовать перенаправление 301, чтобы старый / флэш-путь указывал на сам домен, номы не уверены, как действовать в отношении перенаправлений между HTML и Flash-версиями сайта.Одной из возможностей будет простое обнаружение возможностей на стороне клиента и перенаправление пользователя на соответствующую версию;в этом сценарии клиент, не поддерживающий Flash, который пытается посетить http://www.domain.com/#/about/clients, будет перенаправлен JS на http://www.domain.com/about/clients,, а клиент, поддерживающий Flash, который будет посещать http://www.domain.com/about/clients, будет JS-перенаправлен на http://www.domain.com/#/about/clients.

Это разумный подход?Существуют ли какие-либо потенциальные красные флаги SEO, о которых нам следует знать, прежде чем продолжить?

Спасибо за внимание!

1 Ответ

1 голос
/ 13 июня 2011

Перенаправление с /#/about/clients на /about/clients звучит разумно, но применение обратного может вызвать проблемы - если ваше определение Flash не работает должным образом (возможно, Flash заблокирован и т. Д.), То вы можете отправить пользователя в бесконечностьЦикл перенаправления.

Лично я бы порекомендовал, чтобы ссылки без хэш-функции всегда загружали свое содержимое, как и ожидалось, статическим образом.Если пользователь затем перемещается, вы можете либо получить URL-адрес типа /about/clients#/ (если он перешел на домашнюю страницу) (это не должно быть проблемой, так как сканеры никогда не будут посещать его таким образом), или вы можете иметьих перенаправляют на / в следующий раз, когда они переходят.

ИМХО, я бы сказал, что простым решением JavaScript для решения проблемы хеш-функции было бы легче управлять, поскольку уже есть много хороших примеров этого.

Также рассмотрите возможность использования #! вместо # - эта технология 'хэш-бэнг' используется Google как способ идентифицировать для поисковых систем, что ваш хэш важен и что его содержимое отличается от того, что вы увидитебез хеш-части.Google уже может указывать на определенные части страницы, используя #, и если вы будете использовать технику хэширования на стороне клиента и сервера, она сможет индексировать ваши ссылки AJAX / Flash так же, какобычные ссылки ( см. подробности реализации и требования, которые необходимо выполнить ).

...