estic

Рейтинг
128
Регистрация
01.10.2017
ronibestplay #:
Имеете ввиду сразу странице canonical на себя проставлять?
Да.
ronibestplay #:
Дак весь прикол то в том, что для любого сайта site.ru/?chetotam открывается.
Для любого - это сильно сказано. Кроме того, вы можете не замечать разницы при наличии на странице ошибки 404 идентичного содержимого, например при открытии сайта у меня в подписи по адресу https://acme.p20.ru/? содержимое будет идентично главной странице, но это страница ошибки 404 (на содержимое файла robots.txt не обращайте внимания - сайт полностью закрыт от индексации).


Показанное выше - это действительно редкость. Обычно страница ошибки представлена наглядно, например: https://p20.ru/?

Форум исключает вопросительный знак из адресов показанных ссылок. Если хотите посмотреть мои примеры, дописывайте вопросительный знак вручную.

ronibestplay #:
Оно не то что бы не помогает я не знаю в чем там дело точно. Просто он сперва признал канонической, потом что-то типа она не каноническая через 3 дня прислал, потом мол опять...может со временем как то это устаканится, но такие танцы с бубнами напрягают если честно.

Если бы сразу было настроено, то таких "плясок" не было бы.

ronibestplay #:
Атрибут я не убрал, но закрытие роботс для данной проблемы намного эффективнее
Намного эффективнее использовать программные каркасы, не допускающие дублей. Директивы robots.txt лучше использовать для существующих уникальных страниц, которые не должны индексироваться. Причем опять-таки директивы добавляются сразу при создании таких страниц, а не потом, чтобы пытаться их "исключить".
ronibestplay #:
не помогает исключать такие страницы
Да, это все нужно делать сразу. Т.е. это средства не "исключения", а "недопущения". Даже статус 404 не всегда помогает. Именно для "исключения" есть специальный статус 410.
ronibestplay #:
Просто я про роботс мало что знал и не думал что можно запретить все, что после определенного знака.
Кто ж знал, что вы "мало что знали". Если решили самостоятельно разобраться в вопросе, нужно сначала ознакомиться с основами, прежде чем задавать вопросы на форуме.
ronibestplay #:
Никакие cannonical и гет параметры не помогают. Жаль что никто мне не подсказал Disallow: /?* Кучу времени бы сэкономил.

"canonical" помогает, если писать без ошибок (с одной "n"). И про Disallow давно вам написал:

estic #:
Нужно использовать rel="canonical" или Disallow для адресов со строкой запроса.
Mazai_Nika #:

Вопрос: Какой код для связки старых id с урлами нужен? 

Каких старых id? В общем случае вам нужна таблица соответствия старых адресов и новых.

Это можно делать и целыми разделами, но, как выше написали, здесь нужна полнейшая конкретика.

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

Слэш в конце тега - это из XHTML. В HTML5 допустимо, но избыточно.

Полный адрес главной включает слэш, т.е. правильно https://estic.ru/, но для главной допустимо и без слэша, чего не скажешь о внутренних - там это разные адреса, т.е. нужно указывать тот, который является основным.

Что касается rel="canonical" "на себя", действительно это избыточно, но по-другому в статическом сайте вы не сделаете, т.к. потребуется условное добавление этого тега. Практика такова, что этот тег добавляют "всегда" (в кавычках, т.к. исключения, конечно, есть, например я редко использую этот тег), потому что проблемы с дублями имеются и в широко распространенных программных продуктах, и с условным добавлением тега не хотят возиться.

pegs #:
Ещё один фактор, влияющий на более дорогие домены у наших регистраторов/хостеров - НДС.  Это практически +20% к цене.
Упомянутые мной в предыдущем сообщении цены тоже включают НДС. 3360 или 4400 руб. - это почти или более чем в два раза выше.

Это слишком "мусорные" адреса, чтобы с них делать переадресацию. Все основные решения я описал в предыдущем сообщении.

От статических сайтов нужно отказываться. Не хотите использовать полноценную CMS, можно использовать программный каркас только для "головной" части сайта. А содержимым управлять "по старинке" в менеджере файлов (FTP не рекомендую в виду его незащищенности), в оболочке для работы с СУБД и т.п.

Всего: 1182