Serg_CS

Рейтинг
57
Регистрация
11.02.2013

Ты хоть на педивикии прочти что такое "хопы" и чем они занимаются. Я же ссылку дал.
Если не сможешь понять какое отношение они имеют к передаче http-заголовков, тогда ой.. Учиться то бишь. Читать не только педивикию.

Самое то смешное, что я слышу это от челика, который аппелирует такими терминами, как:

SeVlad:
спецификации HTML-протокола

применительно к URI. ИМХО, это показатель профнепригодности - не отличать HTTP от HTML 😂

Тут сеошый раздел, а не технический.

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

SeVlad:

Вот это поворот :) Про GET что ли покури.

А причем тут хопы, на которые вы ссылаетесь? Покурите модель стека TCP/IP. Хоп - это понятие, применимое только на уровне IP-протокола, когда речь идет о маршрутизации. Да и причем тут HTTP-метод, когда речь про ограничения на длину URI? Хоть POST или DELETE передавайте ;)

И в устаревшем еще в 2014 году RFC 2616, на который вы ссылаетесь, прямо сказано что никаких лимитов нет:

The HTTP protocol does not place any a priori limit on the length of a URI

А если переводить процитированный фрагмент и то, что чуть выше него, смысл такой - веб-сервер может сам вводить дополнительные ограничения на длину, тогда при её превышении он должен вернуть статус 414. А дальше идет предостережение, мол некоторые старые клиенты (на практике - времён 90х) могут сами иметь ограничения на длину урла. Собственно, подтверждение моих слов)


Найди 10 отличий: "255 байт" vs "255 characters"

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

Вернемся все-таки к сабжу. Разумеется, у поисковиков есть некий порог на длину URI, и если он превышается - индексатор такой урл пропустит. В качестве очевидного - если урл будет длиной в несколько мегабайт. Такое только экспериментально можно проверить.

SeVlad:
Если интересует безпроблемная доставка всем и всегда, то длина GET-запроса не должна превышать 255 байт (согласно спецификации HTML-протокола ). Что, грубо говоря, составляет около 200 ASCII символов в урле.
На практике многие хопы пропускают и больше, но надеяться на это я бы не рекомендовал. Мало ли что где когда может случится и на каком-нить хопе станут в старые дефолтные настройки.

Хопам нет дела до того, какие данные вы передаете в IP-пакетах, хоть HTTP/2 передавайте. Проблемы с длинными урлами могут быть только при использовании криво реализованных прокси-серверов, или таких же систем DPI, и только при использовании незащищенного http.

На канальном уровне есть некая максимальная длина передачи одного фрейма (MTU), на которую вы особо влиять не можете, т.к. это зависит от настроек устройств и используемой технологии, а на промежуточных узлах на MTU не может влиять даже ваш непосредственный провайдер. Если IP-пакет слишком большой, он просто фрагментируется на несколько фреймов, и собирается обратно на стороне принимающего.

Ограничение длины в 255 идет не на урл, а только на домен:


URI producers should use names that conform to the DNS syntax, even when use of DNS is not
immediately apparent, and should limit these names to no more than 255 characters in length
Ilnish:
Я вижу это так: я ИП, оказываю услуги и у меня нет наемных работников - значит по закону фз-54 до 2021 года я могу работать без онлайн кассы.

Отсрочка не по 54-ФЗ, а по ст. 2 ФЗ-129 от 6 июня 2019. С бланками строгой отчетности вот непонятки - типографские отменили, а автоматизированные уже попадают под ККТ. Похоже, что тоже не нужны.


Если будут вопросы с налоговой - можно будет сослаться на то, что до 2021 года, ИП без наемных работников имеют право оказывать услуги без онлайн кассы. Или все таки я что-то упустил?

Ну если будет все чисто в плане отсутствия сотрудников и налоговая не признает подрядные отношения трудовыми - тогда норм. Разве что обязательные взносы к пенсии можно вложить более удачно в случае самозанятых.

Если подключить яндекс.кассу, обязательно ли работать согласно ФЗ-54?

Если не хотите нарваться на крупные штрафы - обязательно. Технически - не обязательно интегрировать кассовый сервис с яндексом, можно отбивать чеки через сторонние API.

Может есть какие-то бесплатные способы отправлять онлайн чеки в налоговую, отправить 2-3 чека в месяц вручную, как бы не проблема

Бесплатных точно нет. Этот закон не предусматривает полностью программные решения (как например vECR в Словакии), поэтому и ценники соответствующие. Плюс необходимо платить по договору с ОФД.

Есть сервис Робочеки, который их будет отбивать за вас, выступая агентом.

Учитывая, что у меня клиенты (которым надо именно картой оплатить) есть, но их не особо много и средний чек 500-600 рублей, боюсь что мне это будет крайне не выгодно

Затраты на аренду онлайн-кассы примерно равны обязательным взносам за ИП. Если услуги оказываете лично вы, возможно выгоднее будет перейти на самозанятость, там нет ни взносов, ни требования использовать кассы.

timo-71:
буду признателен за идеи и критику со стороны гуру seo. А надо ли?

Не претендую на "гуру", но пока этот список слов из ваших моделей выглядит очень бесполезно, применительно к SEO-копирайтингу. Гораздо лучшего эффекта можно добиться простым подсчетом пересечений каждого слова между различными документами из топа и дальнейшей ручной отбраковкой неподходящих слов.

Применение LSI в том виде, в котором оно у вас, навскидку, такое - можно определять неоднозначные запросы, попробуйте на примере топов по запросам в яндексе "цезарь" или "наполеон" разбить пространство прямой линией на два класса - назовем их условно "кулинария" и "история". Если получится, значит есть-таки полезный кейс у "настоящего" LSI.

LazyBadger:
Я вижу тут некоторый бандл проблем и вопросов

Самый главный из них - что подразумевает большинство сеошников под LSI. То, что предлагается на практике, совершенно таковым не является. Это всё равно, что называть системник процессором.

LazyBadger:

1. Александр Сафронов - не разработчик, а "руководитель службы релевантности и лингвистики" (надо ли пояснять, что это две большие разницы)

https://moikrug.ru/alsafr вот тут подробная инфа из первых рук - он уже 9,5 лет уже как разработчик только в этом направлении, а сейчас еще и совмещает это с руководительской должностью.

Тут вопрос в том, что вы понимаете под этим. Если спеца, который непосредственно реализует (на C/C++) просчёт факторов ранжирования или хранение поискового индекса (что близко к специальности data engineer), то его в первую очередь интересует производительность, ресурсоемкость и отказоустойчивость поискового движка, а не влияние ранжирующих факторов факторов на качество выдачи. А вот руководитель такой службы вполне может играть роль data scientist, который формирует гипотезы и дает техзадание своим подчиненным, и он же в итоге принимает решение, какой алгоритм выкинуть в помойку, а какой выкатить в прод. Data scientist всегда ближе к разработчику. Уж точно, это не менеджер, который не разбирается в матчасти, а только рисует диаграммы Ганта и считает KPI.

LazyBadger:

2. Он высказывает свое личное частное мнение, а не официальную позицию компании

Но источник всё равно более авторитетный, чем статьи сомнительных авторов из SEO комьюнити, называющих вещи не своими именами.

LazyBadger:

3. Это видео - от июня 17 года, после которого нас уже накрыло и Королевым, и (особенно) Андромедой, так что как минимум - информация устаревшая на пару алгоритмов
4. В этом фрагменте он говорит про БМ25, который несколько иная песня, чем LSI
Нет, как раз про него (+- лапоть)
RTFM, dude

В видео упоминается Палех, и кроме того, на следующем же слайде, среди "работающих" методов идет DSSM, лежащий в основе как Палеха, так и Королева. Королёв, как известно, это почти Палех, только расширенный с тайтла+заголовков на весь текст документа, и вычисляемый теперь не в рантайме, а фоново при индексировании. Андромеда вообще никак не соотносится с текстовой релевантностью, это просто маркетинговое название для нескольких фич (значки для сайтов, быстрые ответы и т.п.). Если прослушать еще дальше - там будет как раз про выделение "значимых" для ранжирования слов, но не по LSI, а по поведенческим факторам (больший вес словам, которые присутствуют на страницах с лучшим CTR в выдаче - положительная обратная связь, по факту).

Поисковые алгоритмы - это не то, что делается и выкатывается за короткий срок - это могут быть годы экспериментов и поиска рабочего решения. Вот маркетинговые названия очередным алгоритмам могут придумать достаточно быстро - сегодня Королёв, завтра какой-нибудь Циолковский.

BM25 там употребляется в контексте того, что авторы всех этих чудо-алгоритмов в своих академических работах любят сравнивать с ним результаты, полученные этими алгоритмами. Т.е. типа "наша модель работает лучше, чем BM25, на столько-то процентов". Но на практике ничего из этого не используется в реальных системах. Тоже самое можно сказать про кучу простых ML-алгоритмов, таких как k-means, decision trees, svm - всё это хорошо для обучения начинающих DS, работает на специально отобранных датасетах, а стоит только попытаться сделать на базе этих методов что-то практическое - результат сильно разочарует.

Есть ряд очевидных ограничений, почему LSI в чистом виде не может применяться поисковиками.

Во-первых, необходимость жестко задавать количество тем - а это в масштабах поисковой системы попросту невозможно - темы практически безграничны и ежедневно появляются новые. Суть алгоритма LSI вкратце: исходно есть матрица слово-документ в масштабах корпуса, LSI её сжимает по количеству документов до жестко зашитого числа документов, которые обзывает темами. DSSM это тоже по сути сжатие с потерями, но оно сохраняет больше информации за счет наличия нелинейных связей. Связи, выдаваемые LSI, получаются всегда линейны. И никакой магии - LSI не в состоянии определить реальное количество тем в корпусе - можно лишь прогнать алгоритм с несколькими жестко заданными значениями и попытаться выбрать наилучшую модель исходя из каких-то метрик качества.

Во-вторых, в любом маломальски крупном тексте упоминается множество разных тем, даже в рамках одного абзаца. А ранжировать на соответствие запросу нужно целые документы.

И наконец, метод очень вычислительно тяжелый. Сложность пропорциональна квадрату количества документов в степени количества тем. Для масштаба веб-корпуса не применимо в принципе. Зато в различных публикациях на искусственных корпусах в десяток тыщ документов считаются и хвастают, как обгоняют по качеству bm25. Кроме того, авторы этих работ редко берут веб-корпус, обычно ограничиваются литературными документами. Особенность веб-корпусов - не всегда правильно с точки зрения языка строятся фразы, и не всегда можно правильно извлечь абзацы (пример - карточки товара, там нет абзацев как таковых), да еще и спамный контент может подпортить всю статистику.

Про RTFM посмешило, учитывая что поисковики не особо где разглашают внутренние детали реализации своих алгоритмов. Но совет дельный, если применять его к тем, кто употребляет аббревиатуру LSI не к месту :)

Говоря о понимании поисковиком смысла, надо сначала договориться об определениях. Навскидку, чтобы роботу понять смысл фразы "салоны красоты рядом", вычисленная модель LSI или даже DSSM для этого будет бесполезна - нужен переколдунщик, который оттригерится на слово "рядом" в запросе, возьмет регион выдачи, услугу и поищет организации в базе знаний, в том же яндекс.справочнике или на картах.

ezon:
Роль LSI фраз велика, так как с помощью них поисковые системы понимают смысл вашего текста.

Да ладно? А вот тут один из разработчиков поиска утверждает, что LSI не применим на практике 🤣 https://youtu.be/QkUmCnDe3xI?t=1715

И LSI это уж точно не про "смысл" текста.

SHLADKOV:

Собственно дополню. Сайт скорее всего под фильтром, поздравляю... http://joxi.ru/bmovLNbS3dwqdr

Этот сервис и по habr.com показывает, что "санкции обнаружены" 🤣 скрин: https://ibb.co/xfQrV5d

После закрытия тулбара тИЦа корректные данные по санкциям можно только в панели вебмастера увидеть.

SHLADKOV:
Но проблемы у домена явно есть

Проблемы могут быть и у Google. Примерно с полгода назад у них был баг с деиндексированием страниц, о котором активно писали в буржунете. Баг официально признали, потом объявили, что исправили, но по факту не у всех всё восстановилось.

JOHNY2010:
КК снимает все виды частотностей

Видимо он про wordstat как источник данных для КК говорил, но тоже вышла неточность 😂

На самом деле, не все виды частотностей можно снять через "прогноз бюджета" в директе, с которым КК также работает. Например, там нет оператора квадратных скобок для фиксирования порядка слов в запросе и фильтрации показов на десктоп/мобилки, и еще имеются ограничения на количество слов и длину запроса. Но у wordstat другой минус - нельзя пробить больше одной фразы за один раз.

Всего: 134