Один сайт, один домен, но две разные технологии?

Мне нужен совет.

Я унаследовал сайт, который существует уже давно. Сайт получает много органического трафика от Google. Владелец бизнеса и веб-сайта обновляет сайт, чтобы сделать его содержимое более управляемым. На данный момент на CMS wordpress работает половина сайта. Физические HTML-страницы составляют остальную часть сайта. Вот краткое изложение:

1) Раздел руководства, который состоит из блога на основе php wordpress, который можно найти по адресу http://mysite.com/guide. Отдельные страницы в разделе руководства имеют такие URL-адреса, как http://mysite.com/guide/4930-hello-world или http://mysite.com/guide/489-welcome-to-my-site. Владелец бизнеса потратил 2 месяца на заполнение этих страниц и не хочет отказываться от них для другой системы.

2) Раздел электронной коммерции, который состоит из тысячи статических/физических страниц продукта. Страницы продуктов НЕ управляются динамически, и правила перезаписи URL-адресов не используются. Страницы имеют такие URL-адреса, как http://mysite.com/products/239123-sofa.html и http://mysite.com/products/23-office-desks.html

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

Раньше я никогда не работал с ERP или CRM. У меня есть несколько вопросов:

1) Хорошо ли иметь один веб-сайт в одном домене, управляемом двумя разными технологиями? Wordpress управляет такими страницами, как http://mysite.com/guide/4930-hello-world в то время как приложение Microsoft управляет такими страницами, как http://mysite.com/products/239123-sofa.html. Как упоминалось ранее, владелец бизнеса не хочет отказываться от wordpress, потому что он приложил значительные усилия для его заполнения.

2) С какими проблемами я столкнусь при реализации правил перезаписи URL-адресов (поскольку это две технологии в одном домене, но в разных подкаталогах)? Мне нужно убедиться, что веб-сайт сохраняет свой Page Rank и положительные стороны SEO.

3) Какие проблемы с конфигурацией сервера возникнут?

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

Спасибо


crm legacy erp
person John    schedule 29.12.2009    source источник
comment
Независимо от того, чем была заполнена ваша база данных WordPress, ее можно сбросить во все, что вы хотите использовать. У вас действительно нет вопросов, которые были бы достаточно конкретными, чтобы иметь ответы.   -  person Azeem.Butt    schedule 29.12.2009

Ответы (2)


arrow_upward
1
arrow_downward

Вы можете придумать конфигурацию, в которой у вас есть отдельные логические/физические внутренние серверы для каждой системы. Затем у вас может быть внешний прокси-сервер (например, Apache с mod_proxy), обслуживающий все запросы и разделяющий их между различными серверными частями. Это также будет работать как «брандмауэр» на уровне приложения, защищая вас от нежелательных запросов, поскольку вы будете пересылать только те URL-адреса, которые распознаете.

person naivists    schedule 29.12.2009
comment
Или еще лучше, nginx вместо громоздкого ресурса Apache;) - person KingRadical; 29.12.2009

arrow_upward
0
arrow_downward

Что касается №1:

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

Что касается №2:

Если вы используете ASP.NET, вы можете написать реализацию, если IHttpHandler для перенаправления URL-адресов с отправкой HTTP 301 (перемещено навсегда) чтобы Google знал, куда был перемещен контент. Я полагаю, что другие технологии имеют аналогичные возможности.

Что касается №3:

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

person Josh Kodroff    schedule 29.12.2009