Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (2)

Наибольший вклад в теги

Все теги (23)

Лучшие ответы пользователя

Все ответы (40)
  • Google начал удалять из поиска заведомо несуществующие страницы?

    @granty
    Самое интересное, что:

    1. Судя по вашей же карте сайта и кэшу Google(см запрос ниже) на сайте никогда не было url: /soderzhanki-2-sezon-3-seriya и /soderzhanki-2-sezon-2-seriya

    2. Судя по whois дата регистрации домена 2020-01-23, то есть сайт - свежак, и ещё даже не проиндексировался поисковиками. Из ~25 страницы, имеющихся на сайте:
    - 10 страниц в индексе Google
    - 3 страницы в индексе Яндексе, (одна появилась в выдаче позавчера, и две - 8 часов назад)

    3. Судя по информации с вашей же карты сайта:
    - 2 сезон 3 серия была выложена 2020-02-13, то есть только сегодня.

    Не объясните, как вы успели получить на неё DMCA?

    spoiler
    Потому, что, есть у меня сомнение, что ты, мил человек, просто спамер, и пытаешься накрутить себе посещаемость, "поведенские факторы", и получить ссылку с qna.habr.com.


    PS: Хотя жалоба DMCA болтается в выдаче по запросу вашего сайта, но она на сериал "Фитнес", и вашего сайта в ней нет. Я не поленился, и запросил из lumendatabase.org полный список url по жалобе...



    UPDATE: В комментариях топикстартер частично реабилитировался и смог предоставить правильный DMCA, соответствующий критериям заданного им вопроса, правда, на другой сайт - mazhor3.ru. Поэтому появилась возможность проверить ситуацию и ответить по существу вопроса.

    На сайте mazhor3.ru, действительно нет некоторых страниц, указанных в жалобе DMCA (пришлось повозится, ибо автор топика редиректами уже сменил структуру URL на сайте, чтобы формально выйти из-под DMCA)

    Это не ошибка Google - он не проверяет url-ы, присланные правообладателем в жалобе. Эти url могут быть вообще не в индексе Google, сайт может использовать клоакинг по IP. Поэтому Google не тратит свои ресурсы на расследования, а просто блокирует присланные url-ы, не проверяя существуют они или нет.
    Правообладатели иногда злоупотребляют этим, и присылают "url на будущие серии". Они знают, что встречную жалобу на них подавать не станут (ведь у этого вебмастера на сайте полно нелегального контента, и таких сайтов у него целая сетка).
    Ответ написан
  • Как и для чего используется php://input?

    @granty
    Данные и так передаются по POST (или GET), но есть нюансы их обработки на стороне сервера.

    1. POST и GET данные в виде parameter=value&param2=val2 автоматически обрабатываются сервером и заполняются глобальные массивы $_POST/$_GET/$_REQUEST:
    $_POST['parameter'] = value;
    $_POST['param2'] = val2;

    GET-параметры при этом ещё и автоматически декодируются по urldecode().
    Через php://input можно получить "сырые" необработанные данные.

    2. Методом POST можно прислать, например, объект JSON, указав 'Content-type: application/json; charset=utf-8'. При этом массив-обёртка $_POST будет пуста, тк не присылается Имя_Параметра, а присылается только Значение_Параметра, и сервер не обрабатывает такие данные автоматически.
    Получить такие данные можно только через php://input, так как глобальные массивы $_POST/$_GET будут пустыми.
    Ответ написан
  • Как узнать откуда был загружен iframe?

    @granty
    Откуда был загружен iframe никак не узнать (узнать-то можно, но в вашем случае это не поможет).

    1. яваскрипт не сработает, тк политика «Одинакового источника» (Same Origin Policy) запрещает доступ из ифрейма к window.top.location.href, если они имеют разные происхождения (грубо говоря - разные домены).
    Проверить window.top != window.self браузер даёт, а доступ к фактическому url из window.top - нет.

    2. на сервере проверять переменную $_SERVER['HTTP_REFERER'] (кто запросил загрузку страницы) смысла тоже нет - если у ифрейма установлен атрибут referrerpolicy:
    <iframe referrerpolicy='no-referrer'>
    реферер не будет прислан (будет, но только в IE/Edge и Safari_IOS).


    Но сделать то, что вы хотите - можно легко. На странице надо издать HTTP-заголовок CSP с директивой frame-ancestors:
    header( "Content-Security-Policy: frame-ancestors https://ваш_сайт.ru http://ваш_сайт.ru https://www.facebook.com https://facebook.com https://www.google.com https://google.com;" );

    это разрешит открывать эту страницу в ифрейме с собственного домена ваш_сайт.ru(без поддоменов!) по http:/https:.
    И сайтам facebook.com и google.com с www или без (но только если фэйсбук/гугль загружены по https: - а их и невозможно загрузить по http:).

    PS: если ваш сайт доступен и по www - добавьте в "волшебную" строку:
    https://www.ваш_сайт.ru http://www.ваш_сайт.ru
    Ответ написан
  • Как лучше разбить заголовок H1 по правилам SEO?

    @granty
    С точки зрения "old school" SEO:
    - Тег < br> (и все блочные теги) разрывает пассаж (Lexical Spans в терминологии Яндекса).
    - Если два слова запроса находятся в разных пассажах, это увеличивает расстояние между ними.
    - Слова ищутся в пределах всего документа, но в зависимости от расстояния между словами, они вносят разный вклад в конечную общую релевантность.

    Раньше даже перенос слова через дефис '-' рвал пассаж - Яндекс просто не понимал этого слова. Но он правильно понимал переносы по & shy;

    spoiler
    Раньше точное вхождение запроса в пассаж проверяли по подсветке слов в кэше Яндекса, но потом Яндекс стал обманывать сеошников.
    Также, Яндекс делает переколдовку (переформулировку) реального запроса с использованием синонимов и расширением запроса (добавлением новых слов) - это сильно затрудняет анализ вхождений.
    До того, как Яндекс объявил войну сешникам, переколдовку, веса слов и их "контрастность" можно было посмотреть. Возможно "старые" сеошники знают как посмотреть вхождение запроса в пассажи, но они больше не выносят это в паблик.

    Можно, конечно, "запилить" эксперимент (он займёт пару месяцев), но проще тупо не использовать < br> в заголовке. Задействуйте CSS для этих целей.
    Ответ написан
  • Как правильно перенаправлять на мобильную версию?

    @granty
    Есть 3 Способа адаптации сайта для мобильных устройств:
    1. Адаптивный дизайн
    2. Динамический показ
    3. Разные URL

    Первые два не требуют перенаправления на мобильную версию. Третий - требует.

    Какой способ из трёх лучше - тема холливарная, поэтому я ограничусь ссылками на Хабр:
    Сравнение методов создания мобильных версий сайтов
    Делать ли мобильную версию? 5 распространенных про...

    И на рекомендации поисковых систем как делать мобильные версии сайта и правильное перенаправление на мобильную версию:
    Индексирование Яндексом мобильной версии сайта на ...
    Сайты для мобильных устройств, рекомендации Яндекса
    Рекомендации Google если мобильная/декстопная верс...

    Если коротко - Гугль для 3-го способа рекомендует прописывать теги:
    На странице для компьютеров (http:// www.example.com/page-1) добавьте следующий код:
    <link rel="alternate" media="only screen and (max-width: 640px)"
     href="http://m.example.com/page-1">

    На мобильной странице (http:// m.example.com/page-1) аннотация должна быть такой:
    <link rel="canonical" href="http://www.example.com/page-1">


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