- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Чудо, как ты редирект симлинкой организуешь?
А зачем редирект? Или сцылки динамические?
А зачем редирект? Или сцылки динамические?
Читайте, чучело:
Господа, переезжаю с Джумлы 1,0 на 1,7, старые урлы сохранить нельзя.
Специально для дебилов выделил ключевой для Вашего вопроса фрагмент. Для ликбеза про то что такое HTTP редирект и зачем он нужен - рекоммендую обратиться к rfc 2616.
покажите пару примеров тех что "были" и тех что "будут"...
вполне возможно удастся обойтись одним-двумя правилами под mod_rewrite и скриптом на php на десяток-другой строк
ловить можно и какие-либо закономерные "старые" линки, либо 404 (но осторожно)
Читайте, чучело:
Специально для дебилов выделил ключевой для Вашего вопроса фрагмент. Для ликбеза про то что такое HTTP редирект и зачем он нужен - рекоммендую обратиться к rfc 2616.
Слушай сюда, чудо, чучело и дебил. Написано что при апгрейде старые ссылки перестают работать - особенности апгрейда. Тем не менее есть внешние ссылки и они должы продолжать работать. А теперь расскажи мне, чудо, чучело и дебил, почему симлинки не будут работать исходя из начальных условий
почему симлинки не будут работать исходя из начальных условий
Потому что сохранятся старые URL.
Потому что сохранятся старые URL.
Это нам ТС расскажет, почему "старые УРЛ сохранить нельзя", то ли из-за апгрейда джумлы она их теряет, то ли другие причины есть
Это нам ТС расскажет, почему "старые УРЛ сохранить нельзя", то ли из-за апгрейда джумлы она их теряет, то ли другие причины есть
при смене версии движка сменились урлы внутренних страниц, какой смысл держать дубли контента?
при смене версии движка сменились урлы внутренних страниц, какой смысл держать дубли контента?
ТС ищет самый быстрый с точки зрения сервера способ "удержать" старые ссылки. Можно дать апачу обрабатывать стопяцот редиректов. Можно организовать через симлинки - но действительно с точки зрения ПС появится дубли. Что бы избежать санкций от ПС нужно будет указать через canonical что считать оригиналом.
Я сильно сомневаюсь что можно придумать что-то, что работало бы быстрее с токи зрения сервера, чем симлинки
ТС ищет самый быстрый с точки зрения сервера способ "удержать" старые ссылки.
Во-первых, что "ищет" ТС - он вполне ясно написал в первом посте. Осилили все, кроме Вас.
Второе. "Самый быстрый" - будет актуально, когда будет не 1k редиректов разных страниц, а по десятку редиректов для _одного_ запроса. Устроите такую клоунаду - задумывайтесь о "быстроте".
Можно дать апачу обрабатывать стопяцот редиректов. Можно организовать через симлинки
Через симлинки нельзя реализовать редиректы. Будет просто дубль контента.
Что бы избежать санкций от ПС нужно будет указать через canonical что считать оригиналом.
"Есть только гугл и яндекс" (который, кстати, только недавно "узнал" про этот нестандартный тег)?
http://www.conversationmarketing.com/2009/02/3-reasons-to-use-rel-canonical.htm
You have no other choice.
Не плюйте на стандарты и не используйте инструменты не по назначению.
Я сильно сомневаюсь что можно придумать что-то, что работало бы быстрее с токи зрения сервера, чем симлинки
Вы помярять эту "разницу" для такого ничтожного действа просто не сможете. 99% времени вообще займет какой-нибудь тупой запрос к БД...
Во-первых, что "ищет" ТС - он вполне ясно написал в первом посте. Осилили все, кроме Вас.
Вы за всех не всекайте. ТС написал что есть проблема, ее можно решить с редиректами, есть ли другие решения. Я предложил другое решение, в том ключе, которые и спрашивал ТС.
похоже только Вы и не поняли.
Второе. "Самый быстрый" - будет актуально, когда будет не 1k редиректов разных страниц, а по десятку редиректов для _одного_ запроса. Устроите такую клоунаду - задумывайтесь о "быстроте".
во-первых, не известна структура сайта. В худшем случае, если ТС положит редиректы в корень или все файлы лежат в одной директории - будет выполняться 1.5К регексов на каждый запрос (в худшем случае - не обязательно только html). В лучшем случае 1.5К регексов на запросы старых УРЛ. Т.е. надо еще и приготовить htaccess правильно.
во-вторых, ничего не сказано о нагрузке на сервер. может у ТС восемь ядер на 10 уников в сутки, а может 10К уников на слабом VDS.
Поэтому - мимо, т.к. через симлинки всегда быстро, с редиректом - при выполнении определенных условий.
Через симлинки нельзя реализовать редиректы. Будет просто дубль контента.
а кто говорит что можно? Только Вы и талдычите почему-то. Есть жизнь за МКАДом и есть жизнь за пределами редиректов.
"Есть только гугл и яндекс" (который, кстати, только недавно "узнал" про этот нестандартный тег)?
для рунета - однозначно да. Меня мало интересует как Байду индексирует мои сайты.
А еще я не оптимизирую сайты под Lynx, eLinks и пр., да-да.
http://www.conversationmarketing.com/2009/02/3-reasons-to-use-rel-canonical.htm
вы сами читали статью-то? все (!) 4 минуса высосаны из пальца.
Не плюйте на стандарты и не используйте инструменты не по назначению.
Вы помярять эту "разницу" для такого ничтожного действа просто не сможете. 99% времени вообще займет какой-нибудь тупой запрос к БД...
я не знаю какая нагрузка у ТС, я не знаю есть ли у него вообще БД. Разницу померять будет очень просто - страницы 100% будут загружаться медленнее, просто потому что броузеру придется 2 раза обращаться к серверу за ответом.
что я знаю
1) документация по апачу:
2) я знаю что сысоев не стал идти по пути апача в плане, а сделал свою систему, которая зачастую действительно быстрее чем апачевская, если правильно готовить. и дело не в "волшебных" библиотеках регекса в nginx.
htaccess - очень мощный и гибкий инструмент, но нужно понимать как инструмент работает, как им пользоваться и что за все надо платить.