Иван Петров

Готовой страницы предоставить не могу (низя), но ходят слухи, что можно:
1. Создать любые виды капчей в console.yandex.cloud.
2. Создать обычную html страничку, разместив ее на любом техническом домене.
3. Вставить код капчей из п1. в п2, дополнительно указав test: true, чтобы второй этап капчи активировался всегда.
4. Закрыть от индексации и убрать из п2. все слова по типу капча/captcha итп, чтобы боты не тренировались на вашем персональном полигоне.

Все бесплатно, даже хостинг для статических файлов и технический домен, лимит бесплатной капчи - 10000 запросов/мес.

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

Поисковые запросы по-прежнему проще всего кластеризовать по топу поисковой выдачи с расчётом на то, что результаты такой кластеризации потом придётся доводить до ума вручную (или с помощью вспомогательного инструментария). Смысл простой: по списку интересующих запросов снимается статистика из поисковой выдачи, в результатах ищутся пересечения по сайтам. Традиционно для этого я использовал KeyCollector, он годен для этой задачи и сейчас (если речь идёт о Яндекс).

Второй подход - взять пару эталонных сайтов (максимально похожих на свой, целевой) и выгрузить структурирование из инструментов наподобие keys.so. Это даже быстрее, а результаты проще контролировать.

Есть и более сложные и затратные по ресурсам способы:

а) Кластеризация на базе поисковых интентов, исходя из контента. В этом случае отталкиваемся не от лексики (то есть ключевых слов) и поисковой статистики, а от семантики и поисковых намерений целевой аудитории. Условно, исходим из базового намерения ("прямые поставки асфальтного оборудования из Китая"), пробиваем разветвления запросов (подтемы, напрямую связанные с этим намерением), и уже на этой базе прорабатываем и структуру сайта (постранично и комплексно), и ключевые слова, которые должны присутствовать в каждой группе.

б) Кластеризация на векторах. В этом случае каждый запрос прогоняется через достаточно сложный классификатор, использующий LLM, кластеризуется чем-то наподобие HDBSCAN, и выявляются максимально близкие запросы и те, что явно вылетают за пределы заданных смыслов. Этот способ не учитывает поисковую статистику и годен только как вспомогательный, для углубленных проработок - сама по себе семантика никак не связана с пользователями, и основывается только на статистике слов. С другой стороны, поисковая статистика тоже очень однобока, а при нынешних алгоритмах сильно "шумит". Отмечу, что для проработки тех подзапросов, что никогда не попадают в статистику того же "Вордстат", но должны присутствовать в кластере, замены этому способу нет.

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

Просто так покупать ссылки, "чтобы было" смысла практически нет. А задачи бывают разные: поднять авторитетность хоста, привлечь аудиторию, раскачать запросный индекс, качнуть по ключу определенную страничку и т.п.

Наиболее реальная схема - многоуровневый ссылочный профиль. Он подразумевает, что первый уровень - это хорошо собранная PBN и серьёзные авторитетные хосты, а также аутрич. Там - никакого спама, всё по-белому (кроме того, что PBN это всё же серьёзная манипуляция, за которую может и прилететь).

Второй уровень - это биржевые ссылки. Тут выбор большой, надо внимательно смотреть на доноров. Ссылки с этого уровня - только на первый, не на целевой сайт. Хотя, конечно, можно и напрямую, если донор действительно хорош. Скажем, сайты региональных СМИ - вполне годная идея (и для первого уровня).

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

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

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

На данный момент, я бы для ребенка выбрал следующую схему:
1. Универ на программиста + параллельное изучение java (максимальный спрос).
2. С третьего курса - бесконечные попытки устроиться на стажировку java разрабом в финтех.
3. Затем (у него уже есть теплое место и достаточно денег), он самостоятельно выберет другое направление по душе, если понадобиться.

Может есть какие то ресурсы где будет описана конкуренция и тенденция? Заранее спасибо за ответы.

Основной сайт для поиска работы (как индикатор) подойдет? Я как раз делал подборку 2 недели назад по nodejs, php и python, вроде данные не сильно изменились.

P.S. В резюме указаны лишь те, кто "активно ищет работу".

Вакансии (backend):
- NodeJS (Express/Nest): 57 вакансий.
- PHP (Laravel/Symfony/Yii): 295 вакансий.
- Python (Django/FastAPI/Flask): 365 вакансий.
- .NET: 364 вакансий.
- Java: 719 вакансий.

Резюме (backend):
- NodeJS (Express/Nest): 2111 резюме.
- PHP (Laravel/Symfony/Yii): 4392 резюме.
- Python (Django/FastAPI/Flask): 9957 резюме.
- .NET: 3808 резюме.
- Java: 9932 резюме.

Соотношение вакансий к резюме (backend):
- NodeJS (Express/Nest): 1/37.
- PHP (Laravel/Symfony/Yii): 1/15.
- Python (Django/FastAPI/Flask): 1/27.
- .NET: 1/10.
- Java: 1/13.

----------------------------------

Вакансии (fullstack):
- NodeJS (Express/Nest): 132 вакансий.
- PHP (Laravel/Symfony/Yii): 410 вакансий.
- Python (Django/FastAPI/Flask): 416 вакансий.
- .NET: 451 вакансий.
- Java: 787 вакансий.

Резюме (fullstack):
- NodeJS (Express/Nest): 2307 резюме.
- PHP (Laravel/Symfony/Yii): 4257 резюме.
- Python (Django/FastAPI/Flask): 4951 резюме.
- .NET: 3100 резюме.
- Java: 6852 резюме.

Соотношение вакансий к резюме (fullstack):
- NodeJS (Express/Nest): 1/17.
- PHP (Laravel/Symfony/Yii): 1/10.
- Python (Django/FastAPI/Flask): 1/12.
- .NET: 1/11.
- Java: 1/9.

Итог:
- NodeJS (Express/Nest) - очень мало вакансий и самая большая конкуренция за рабочее место (в этой подборке), в среднем, в 1.5-2 раза больше, чем в PHP/Python/.NET/Java.
- Python (Django/FastAPI/Flask) - самое большое число вакансий. Конкуренция за рабочее место в сравнение с PHP в 1.5-2 раза больше. Стоит отметить колоссальную разницу в соотношении вакансий к резюме между backend и fullstack разработчиками - 27 и 12, очень похоже на тех самых "вкатунов", которые "долбят" лишь одно направление, "рисуют" 1-3 года опыта и вперед.
- PHP, .NET и Java имеют примерно равную конкуренцию.

(лево ИЛИ право) ИЛИ (верх ИЛИ низ)

// Левое ИЛИ правое значение.
type OffsetHorizontal =
  | { left: number; right?: never; }
  | { right: number; left?: never; }

// Верхнее ИЛИ нижнее значение.
type OffsetVertical =
  | { top: number; bottom?: never; }
  | { bottom: number; top?: never; }

// Горизонтальные значения, с запретом использования с вертикальными.
type OffsetHorizontalOnly = OffsetHorizontal & {
  top?: never;
  bottom?: never;
}

// Вертикальные значения, с запретом использования с горизонтальными.
type OffsetVerticalOnly = OffsetVertical & {
  left?: never;
  right?: never;
}

// OffsetHorizontalOnly ИЛИ OffsetVerticalOnly.
type Offset = OffsetHorizontalOnly | OffsetVerticalOnly;
  
// Верно:
// { left: 100 }
// { right: 100 }
// { top: 100 }
// { bottom: 100 }

// Неверно:
// { left: 100, right: 100 }
// { top: 100, bottom: 100 }
// { left: 100, top: 100 }
// { right: 100, top: 100 }
// { left: 100, bottom: 100 }
// { right: 100, bottom: 100 }

Если понадобиться вариант с И/ИЛИ между осями, то можно так реализовать:

// Левое ИЛИ правое значение.
type OffsetHorizontal =
  | { left: number; right?: never; }
  | { right: number; left?: never; }

// Верхнее ИЛИ нижнее значение.
type OffsetVertical =
  | { top: number; bottom?: never; }
  | { bottom: number; top?: never; }
  
// OffsetHorizontal И/ИЛИ OffsetHorizontal.  
type Offset =  
  | OffsetHorizontal  
  | OffsetVertical  
  | (OffsetHorizontal & OffsetVertical);
  
// Верно:
// { left: 100 }
// { right: 100 }
// { top: 100 }
// { bottom: 100 }
// { left: 100, top: 100 }
// { right: 100, top: 100 }
// { left: 100, bottom: 100 }
// { right: 100, bottom: 100 }

// Неверно:
// { left: 100, right: 100 }
// { top: 100, bottom: 100 }

данные формы не поступают в таблицу.

Что значит "не поступают"? Что делаете и что при этом происходит? В консоли что? Пока придется гадать...

const pool = mysql.createPool

Вижу подключение к бд, но проверок успешно ли установлено соединение - нет.

app.post("/two.html", urlencodedParser, function (req, res) {

Вижу использование urlencodedParser для обработки данных формы, но не вижу его объявления, попробуйте так (express 4.16.0+):

// Подключение к бд
const urlencodedParser = express.urlencoded({extended: false});
// app.post эндпоинт

if(!req.body) return res.sendStatus(400);

Больше инфы:

console.log("req.body);
if (!req.body) return res.status(400).send("Данные не были отправлены");

if(err) return console.log(err);

Больше инфы:

if (err) {
  console.error('Error:', err);
  return res.status(500).send('Server error');
}

const name = req.body.name;
const usluga = req.body.usluga;
const tel = req.body.tel;

Так симпатичнее:
const {name, usluga, tel} = req.body;

< form action="/two.html" method="post">

Возможно, в будущем, будет лучше указать другой эндпоинт для приема данных с формы?
<form action="/submit-form" method="post">
Ну и на всякий, в вашем случае, two.html должен лежать рядом с server.js.

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

UPD: Интересно, что вторую половину ответа почему-то удалили. Видимо в русторе сомневаться низя :)

Можно ли это сделать?

Можно, законом не запрещено.

Нужно получить все возможные пары элементов.

В каком виде? Предположу, что в виде пары в массиве (['a', 'b'], ['a', 'c'] итп), тогда можно так:

const arr = [ 'a', 'b', 'c', 'd', 'e' ];

const pairs = arr.flatMap((x, i) =>
  arr
    .map((y, j) => i !== j ? [ x, y ] : [])
    .filter((pair) => pair.length),
);

console.log(pairs);

/*
[
  [ 'a', 'b' ], [ 'a', 'c' ],
  [ 'a', 'd' ], [ 'a', 'e' ],
  [ 'b', 'a' ], [ 'b', 'c' ],
...
]
*/

- В 15 годах писал похожий парсер, используя node, fetch и axios, но сейчас часть сайтов возвращает html без таблиц с ценами, почему?

- Для чего нужны selenium, playwright и puppeteer, если я могу через fetch и axios все получить?

Скорее всего проблема в динамическом формировании этих данных на странице. Тут сразу 2 правильных ответа, можете и не можете единовременно:
- Можете - в инструментах разработчика браузера смотрите, с какого адреса приходят данные и затем дергайте данные напрямую, минуя сам сайт, в таком случае можно продолжать использовать fetch.
- Не можете - если вариант выше сложен, то вам нужен инструмент, который сможет выполнять js на странице. fetch/axios возвращают первый ответ сервера, т.е. js на тот момент еще не выполнился на странице, соответственно данные не были подгружены. Вопрос рендера js на странице решают инструменты по типу selenium, playwright и puppeteer.

- Если все же использовать selenium, playwright и puppeteer, что из них лучше на данный момент?

Вначале нужно определить, что понимается под "лучше":
- Можно использовать критерий современности, тогда puppeteer отпадает (playwright написала команда puppeteer).
- Можно использовать критерий производительности, тогда selenium проигрывает playwright сразу по 2 пунктам, по прожорливости и отклику на действия.
- Можно использовать критерий обнаружения анти-бот системами, тогда selenium (с учетом undetected_chromedriver) проигрывает playwright тем, что имеет явную дополнительную задержку в ~100-300мс при выполнении CDP команд, что прям заметно. Playwright такой задержки либо не имеет вообще, либо она в рамках погрешности.

Можно ли их с nodejs использовать?

Selenium написан на java, но так же имеется возможность использования его с nodejs. Playwright вообще написан на ts, все примеры документации и сопутствующие библиотеки с большей вероятность будут писаться под ts по умолчанию.

- Часто вижу о упоминание CDP в контексте парсинга, это зачем и для чего нужно?

CDP (Chrome DevTools Protocol) грубо говоря - это некие "низкоуровневые" команды для "chromium based" браузеров, который позволяют этим браузером управлять. В playwright так реализованы большинство "высокоуровневых" команд, например: при использовании playwright мы пишем await locator.getAttribute(name), а playwright использует аналогичную команду из CDP DOM.getAttributes или DOM.describeNode.

- Что использовать для отправки сообщений в телегу?

Если речь идет об nodejs, то Telegraf.

Как можно легально отбить стоимость этого сервера?

Если коротко, то никак. Чуть подробнее - если у вас будет в 10 или 100 раз больше серверов, то овчинка на таких объемах выделки не стоит, не то что ваш 1 сервер.

Если все таки решитесь, то первое, о чем стоит беспокоиться - это закон (149-ФЗ), и как случайно не стать прокси сервером для разных тематик, с которых легко рубятся палки.

Ну и гуглежка обычно быстрее, чем написать вопрос:
Как монетизировать сервер / Не уходить в минус?
Как монетизировать домашний сервер?
Как заработать на своём сервере?
Можно ли заработать на своем домашнем сервере?

Относительно недавно начал заниматься парсингом. Использую tor.

Жестко.

Попробовал достаточно много способов из инета, но ip так и не меняется

Но нам вы их конечно же не показали.

Хотелось бы узнать работает ли вообще сейчас базовый парсинг с помощью tor

Технически - работал, работает и будет работать. Функционально - не работал и не будет работать, т.к. ip выхода тора палятся так, как не палятся спам-ip дата-центров, ну и про скорость и стабильность работы тора не стоит забывать.

либо же нужно искать обходные пути?

- Если денег нет - использовать публичные списки ip проксей.
- Если денег почти нет - использовать не публичные списки ip проксей.
- Если деньги есть - использовать мобильные прокси.
- Если деньги ЕСТЬ! - использовать резидентские прокси.