Что такое файл robots.txt? – iSEO

Файл robots.txt («роботс тэ-экс-тэ») – текстовый файл, который представляет собой основной способ управления сканированием и индексацией сайта поисковыми системами. Размещается строго в корневой папке сайта. Имя файла должно быть прописано в нижнем регистре.

Зачем нужен robots.txt?

Поисковый робот, попадая на сайт обращается к файлу robots.txt, чтобы получить информацию о том, какие разделы и страницы сайта нужно игнорировать, а также информацию о расположении XML-карты сайта и другие параметры.

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

Для создания robots.txt достаточно воспользоваться любым текстовым редактором. Его необходимо заполнить в соответствии с определенными правилами (о них расскажем далее) и загрузить в корневой каталог сайта.

Если файла robots.txt на сайте нет или он пустой – поисковые системы могут пытаться сканировать и индексировать весь сайт.

Основные директивы в robots.txt

Комментарии

В файле robots.txt можно оставлять комментарии – они будут игнорироваться поисковыми системами. Комментарии помогают структурировать файл, указывать какие-то важные пометки и т. п. Строка с комментарием должна начинаться с символа решетки – #.

Пример:

# Это комментарий

User-agent

Указывает для какого робота предназначены следующие за ней инструкции. Файл robots.txt может состоять из нескольких блоков инструкций, каждая из которых предназначена для определенной поисковой системы. Каждый блок начинается с директивы User-agent и состоит из следующих за ней инструкций. Каждая инструкция – с новой строки.

Наименования роботов для User-agent можно найти, например, в справке поисковых систем. В Рунете чаще всего используются три:

• * – указывает, что следующие инструкции предназначены для всех роботов. Если робот не найдет в файле robots.txt секции конкретно для него, то будет учитывать эту секцию.
• Yandex – робот Яндекса.
• Googlebot – робот Google.

Примеры:

# Секция для всех роботов, которая разрешает индексировать весь сайт
User-agent: *
Disallow:

# Секция для Google, которая запрещает индексировать папку /secret/
User-agent: Googlebot
Disallow: /secret/

Disallow и Allow

Основные директивы, которые указывают, что можно и что нельзя индексировать:

• Disallow – запрещает индексацию
• Allow – разрешает

Поскольку, изначальная стандартная функция robots.txt это именно запрещать индексацию, то чаще используются директивы Disallow. Директива Allow появилась позднее и её могут поддерживать не все поисковые системы. Но Яндекс и Google – поддерживают.

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

В каждой из директив указывается префикс URL (т. е. начало адреса страницы), для которого должно применяться это правило. Также есть специальные символы:

• * – любая последовательность символов (в том числе, пустая). В конце инструкций ставить этот символ не нужно, т. к. по умолчанию директивы интерпретируются так, что как будто он там уже есть.
• $ – конец строки. Отменяет подразумеваемый символ * на конце строки.

Если в файле используются одновременно директивы Allow и Disallow, то приоритет будет иметь та, префикс URL у которой длиннее. Правила применяются по возрастанию длины префикса.

Пример:

# Секция для Яндекса, которая запрещает индексировать папку /secret/
# но разрешает индексировать страницу /secret/not-really/
# при этом не разрешает индексировать всё остальное в папке /secret/not-really/
User-agent: Yandex
Disallow: /secret/
Allow: /secret/not-really/$

# Секция для всех роботов, которая запрещает индексировать весь сайт
User-agent: *
Disallow: /

# Секция для Google, которому можно индексировать только страницы с параметрами в URL
User-agent: Googlebot
Disallow: /
Allow: /*?*=

Clean-param

Директива, которую поддерживает Яндекс. Используется для указания параметров в URL, которые следует игнорировать (т. е. считать страницы с такими параметрами одной и той же страницей).

Синтаксис:

Clean-param: param1[&param2&param3&..&paramN] [path]

Где param1…paramN это список параметров, разделенных символом &, а [path] это опциональный префикс URL для которого нужно применять это правило (по аналогии с Allow/Disallow).

Директив может быть несколько. Длина правила – не более 500 символов.

Пример:

# Разрешить Яндексу индексировать всё
# кроме страниц с параметром session_id в папке /catalog/
User-agent: Yandex
Disallow:
Clean-param: session_id /catalog/

Sitemap

Указывает на расположение XML-карт сайта. Таких директив может быть несколько.

Директива Sitemap является межсекционной – не важно в каком блоке User-agent или месте файла она будет указана. Все роботы будут учитывать все директивы Sitemap в вашем файле robots. txt.

Пример:

Sitemap: https://www.site.ru/sitemap_index.xml

Host

Межсекционная директива для указания основного хоста. Раньше поддерживалась Яндексом. Теперь поддерживается только роботом поиска Mail.ru. Ее наличие в файле не является какой-то ошибкой, но и пользы от нее немного, т. к. доля органического трафика с поиска Mail.ru обычно очень низкая (порядка 1%).

Пример:

Host: https://www.site.ru

Crawl-delay

Устаревшая директива, которая использовалась для указания задержки между обращениями робота к сайту. Теперь управлять нагрузкой робота на сайте можно в Яндекс Вебмастере и Google Search Console. Директиву Crawl-delay не поддерживает ни Яндекс, ни Google.

Что еще важно знать про robots.txt

• Регистр букв имеет значение. Папки /aaa/ и /AAA/ это разные папки и для них нужны разные директивы.
• Кириллица – не поддерживается. Как она не поддерживается в URL и в названиях доменов. В файле robots.txt кириллические папки/файлы и названия доменов должны быть указаны в закодированном виде.
• Google считает, что файл robots.txt управляет сканированием, а не индексацией. На практике это значит, что если какие-то страницы сайта Google уже нашел и проиндексировал (например, на них были ссылки с других сайтов), то запрет их индексации в robots.txt не поможет исключить их из индекса. Для этого нужно применять метатег robots на самой странице. При этом, чтобы Google это тег увидел и учёл – страница не должна быть закрыта в robots.txt. Звучит это довольно абсурдно, но работает именно так, к сожалению.
• Прежде чем залить файл на «боевой» домен – проверьте его правильность с помощью соответствующих инструментов в Яндекс Вебмастере и Google Search Console.

Подробнее о файле robots.txt в справке поисковых систем:

• https://yandex.ru/support/webmaster/controlling-robot/robots-txt.html
• https://developers. google.com/search/docs/advanced/robots/intro?hl=ru

настройки сканирования без бубна — SEO на vc.ru

Как показывает практика, база технического SEO – файл robots.txt, – многими вебмастерами не только заполняется неправильно, но и без понимания, зачем этот файл и как он работает. Статей на эту тему – объективно, тонны, но есть смысл расставить некоторые акценты.

7941
просмотров

Для чего вообще нужен robots.txt

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

robots.txt предназначен для единственной цели: управлять сканированием сайта на базе «Стандарта исключений для роботов». Это не инструмент для управления индексацией, и если вы попытаетесь управлять с его помощью попаданием ваших страниц в индекс, неизбежно получите ошибки и проблемы. И чем больше и сложнее ваш сайт – тем больше будет ошибок. Для управления индексацией используйте предназначенные для этого инструменты:

С его помощью можно указать поисковым роботам, какие URL не должны сканироваться, а какие сканировать можно и нужно. Это не команды: поисковые роботы могут проигнорировать запрещающие и разрешающие директивы, если получат более весомые сигналы это сделать. Простой пример: если на страницу ведёт достаточное количество ссылок, она появится в выдаче – хотя саму страницу поисковик скачивать и не будет.

Важно понимать: robots.txt – не закон для роботов, а просто список пожеланий с достаточно противоречивой историей. Несмотря на необязательность директив, например, гуглобот не станет сканировать ваш сайт, если сервер ответит технической ошибкой на запрос «роботс». И вместе с тем, легко проигнорирует запреты, если получит сигналы о важности какого-то URL в рамках сайта (наличие ссылок, настройка перенаправлений, постоянный пользовательский трафик и т.п.).

Что не нужно сканировать

• Системные папки на сервере

• Дубли: сортировки, UTM-метки, фильтры и прочие URL с параметрами

• Страницы пользовательских сессий, результаты поиска по сайту, динамические URL
• Служебные URL
• Административная часть сайта

К чему должен быть обязательный доступ

• Посадочные страницы

• Служебные файлы, отвечающие за рендеринг страницы (js, css, шрифты, графика)

Особое внимание обращу на обязательное наличие разрешений на сканирование JS и CSS. Если поисковые системы не смогут отрисовать страницы сайта в том виде, в каком их получает посетитель-человек, это приведёт к следующим проблемам:

Зачем нужны отдельные секции для поисковых роботов

Оставлять единый блок директив для всех поисковых роботов – плохая идея, и вот почему.

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

• Яндекс плохо работает с метатегами robots и каноническими адресами. Директивы в robots.txt для него важнее. Если вы разрешите ему сканировать то, что не должно попасть в индекс, он с большой степенью вероятности проигнорирует всё остальное, и может начать ранжировать вовсе не то, что вам надо. Скажем, нецелевую страницу пагинации — просто потому, что ему что-то не понравилось на целевой странице.

• Яндекс использует директивы, которые не признаёт Google, например, Clean-param. Есть и директивы, которые понимает только гуглобот.
• Хорошая идея — минимально блокировать сканирование для гуглобота, индексацией управляя только на уровне страницы. Таким образом Гугл будет лучше понимать ваш сайт, а алгоритмы там достаточно умные, чтобы и без вашего участия разобраться, что к чему. Если же по логам вы отмечаете ненормальную активность гуглобота там, где не надо – это повод подумать, что не так с сайтом.
• Если гуглобот зайдёт на сайт и не сможет скачать robots.txt, он уйдёт. Яндекс-бот в такой придирчивости не замечен.

Общий принцип: открывайте для Яндекса по необходимости. Для Гугл – по необходимости закрывайте.

Для Яндекса вы должны понимать, что у вас должно быть в индексе. Для Гугл – наоборот, чего в индексе быть не должно.

Активность Яндекс-бота в рунете кратно превышает активность гуглобота, которая в принципе лимитирована. Это ещё одно условие, которое надо учитывать при составлении директив для robots.txt.

Можно ли блокировать на уровне robots.txt зловредных ботов и парсеры

Каждый сайт посещает множество роботов, и не все они вам нужны. Это могут быть роботы-парсеры, которые используют ваши конкуренты для извлечения информации, многочисленные SEO-сервисы, которые могут предоставлять информацию о вашем сайте конкурентам и т.п. Пользы для сайта от них нет, а нагрузку на сервер они создают. Стоит ли пытаться запрещать им сканирование в robots.txt?

Нет. Набор инструкций на базе стандарта исключений имеет рекомендательный характер, и фактически ограничить ничего не может. Если вы хотите заблокировать посторонних роботов – делать это надо на уровне сервера. Чаще всего в robots.txt пытаются заблокировать самых известных официальных ботов типа AhrefsBot, MJ12bot, Slurp, SMTBot, SemrushBot, DotBot, BLEXBot и т.п. Смысла это не имеет, но вы можете попробовать.

Что будет, если robots. txt не заполнен или заполнен неправильно

Недоступность файла с директивами по техническим причинам (ошибки 5**) может привести к тому, что гуглобот не станет сканировать сайт. Отсутствие же файла приведет к тому, что роботы будут обходить всё подряд и накидают в индекс тонны мусора. Чаще всего это не очень страшно. А вот ошибки в директивах могут привести к достаточно широкому спектру проблем. Вот типовые:

• Поисковая система не сможет отрисовать адаптивную вёрстку вашего сайта, потому что не может получить доступ к файлам шаблона, и решит, что сайт не подходит для просмотра на смартфонах.

• Часть контента или оформления не будет просканирована или учтена, если выводится она средствами JS, а доступ к ним заблокирован.
• Если в robots.txt запрещено сканирование страниц, которые вы хотели бы удалить из индекса, деиндексированы они не будут – робот просто не увидит ваших указаний в рамках страницы, а в панели вебмастеров вы увидите соответствующее уведомление («Проиндексировано, несмотря на блокировку в файле robots. txt»).
• Без запрета на сканирование определенных страниц (пользовательских, с параметрами) поисковая система будет вносить в индекс явный мусор, который через время будет выбрасывать. В случае Яндекса это может быть чревато переклейкой запросов на нецелевые страницы, рост страниц, рассматриваемых как некачественные, и как следствие – снижения доверия к сайту на уровне хоста.

Ошибки в настройках сканирования – и вот уже поисковому роботу недоступен целый блок, куда выводится портфолио веб-студии.

Простенькие сайты на той же «Тильде» чаще всего вообще не нуждаются в правках robots.txt – там разрешено всё, и нет никаких проблем ни с отрисовкой сайта, ни с попаданием в индекс поискового мусора. Интерпретаторы современных ПС довольно снисходительно относятся к возможным ошибкам, однако надеяться на это не стоит.

Основные правила

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

• Файл может называться только «robots.txt» с названием в нижнем регистре, быть в кодировке UTF-8 без BOM, и находиться в корне сайта.

• Никакой кириллицы в robots.txt быть не должно! Если вы используете домен в зоне РФ или кириллические адреса – для настроек robots.txt используйте конвертацию таких URL в пуникод. Например, директива Sitemap в данном случае будет выглядеть примерно так:
  Sitemap: http://xn--80aswg.xn--p1ai/sitemap.xml
• Каждая новая директива начинается с новой строки.
• Блок директив для каждого User-agent отделяется от других блоков пустой строкой. Пустая строка между директивами обрывает список, после пустой строки начинается новый блок.
• Все запрещающие или разрешающие директивы относятся только к боту, указанному для заданного блока.
• Порядок размещения разрешающих и запрещающих директив особого значения не имеет. В настоящий момент это свойственно и роботам Яндекса, и Google.

Регулярные выражения и подстановочные знаки

Регулярные выражения и подстановочные знаки значительно упрощают процесс настройки сканирования. Официально они не поддерживаются стандартами, и тем не менее, понимают их все роботы. Ваша задача – составить регулярное выражение, блокирующее сканирование всего поискового мусора и разрешить необходимые URL, а не вносить туда десятки и даже сотни URL (как иногда пытаются делать). Отдельные URL, ненужные в выдаче по каким-то причинам, нужно просто запрещать индексировать метатегом.

Пример заполнения robots.txt в стиле «Знай наших» школы SEO-кунгфу «Раззудись плечо» — и это ещё не весь список

Для формирования регулярных выражений в рамках «роботс» используется всего два знака: * и $.

Знак * означает любую последовательность символов, «что угодно». Примеры.

User-agent: *
Disallow: /*?

Это означает, что для любого робота (если для него нет отдельного набора директив) запрещено сканирование любых страниц фильтров.

User-agent: *
Allow: */*.jpg*

Разрешено сканирование файлов JPG с любым названием в любой доступной папке сайта, включая кэшированные файлы.

Знак $ соответствует концу заданного URL. Те URL, что содержат какие-то знаки после знака $, могут быть просканированы. Пример:

User-agent: *
Disallow: */*.pdf$

Эта директива запрещает сканировать любой файл в формате PDF в рамках сайта. Ещё один пример:

Disallow: */ofis$

Будет заблокирован URL https://сайт-ру/catalog/muzhchinam/ofis

Но URL https://сайт-ру/catalog/muzhchinam/ofis?sort=rate&page=1 будет доступен.

Как составить правильный robots.txt для своего сайта

Как уже было сказано выше, гуглобот не станет сканировать сайт, если не найдёт robots.txt, поэтому для начала можно использовать даже шаблонный «роботс» (как многие и поступают). Однако это явно не оптимальный вариант.

Чтобы составить правильный robots.txt для своего сайта, вы должны чётко понимать два момента:

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

На второй же вопрос вам поможет ответить парсер сайта, способный эмулировать заданных поисковых роботов, показать наглядно, как поисковых робот отрисовывает страницу по актуальным правилам, справляется ли он с рендерингом адаптивной версии сайта и т.п. С этой целью я использую Screaming Frog SEO Spider. Думаю, эти возможности есть и у его конкурентов.

Полноценный рендеринг сайта позволит вам увидеть его глазами поискового робота

Можно начинать парсинг. По окончании запустите Crawl Analysis, и можно приступать к изучению результатов.

Поскольку нас в данном случае интересует список проблем с файлом robots.txt начнём с вкладки Rendered Page — там можно посмотреть, как видит робот выбранную страницу.

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

Как вариант – контент может быть в основном доступен, просто без ожидаемого дизайна, дырками на месте картинок и т. п. Здесь же можно сразу посмотреть, что именно заблокировано и мешает роботу увидеть сайт так, как видите его вы. Если в списке заблокированных ресурсов вы видите js, css, файлы изображений, веб-шрифты – вносите их в список разрешающих директив.

В левом окне мы видим заблокированные папки, содержащие файлы шаблона. Их отсутствие приводит к тому, что робот видит сайт так, как показано в правом окне.

Внимательно изучите все страницы, которые так или иначе помечены как дубли – по тайтлам, по сходству контента и т.п. Вероятно, среди них действительно могут оказаться дубли и поисковый мусор. Дубли могут быть как чисто техническими (например, товары могут выводиться плиткой, а могут списком), а могут быть и качественными, когда полезного контента на странице недостаточно, и она похожа на другие страницы, такие же некачественные с точки зрения ПС. В данном случае вам предстоит решить, что делать: закрыть мусор от сканирования, запретить индексацию метатегом, или оперативно внести правки и отправить URL на переобход.

На следующем шаге вам предстоит изучить данные из панелей вебмастеров. Достаточно удобно и наглядно это реализовано в Яндекс-Вебмастере. Заходим в «Индексирование», «Страницы в поиске», вкладка «Исключенные» – и внимательно оцениваем URL, помеченные как неканонические, дубли, а также МПК. Среди них, как правило, большую часть представляют страницы сортировок, фильтров, пагинации и т.п. Их чаще всего можно смело вносить в список для запрета на сканирование.

Инструменты для тестирования

Любые внесенные правки должны проверяться с помощью соответствующих инструментов поисковых систем.

• В Гугл – https://www.google.com/webmasters/tools/robots-testing-tool

• В Яндексе – https://webmaster.yandex.ru/tools/robotstxt/

Принцип действия прост: вы видите актуальную кэшированную версию файла, анализатор, инструмент проверки заданных URL. Если URL заблокирован – вы увидите строку, которая его блокирует.

Заключение

Подытожим основные тезисы.

UPD. Для настроек индексирования сайта рекомендую использовать метатег Robots, HTTP-заголовок X-Robots-Tag, настройки тега Canonical, а также вполне традиционные средства – редиректы, sitemap.xml и т.п.

Ubuntu Manpage: urls.txt — база данных URL для регрессионного тестирования

Предоставлено: siege_3.0.8-1_amd64

ИМЯ

         urls.txt  — база данных URL для регрессионного тестирования
 

ВВЕДЕНИЕ

       Файл urls.txt по умолчанию устанавливается в /etc/siege/urls.txt. Когда вызывается осада
       без ссылки командной строки на URL-адрес, то по умолчанию он ищет URL-адреса в этом файле.
       Преимущество использования файла urls.txt состоит из двух частей: во-первых, вы освобождаете вас от повторного ввода
       URL при каждом вызове. Во-вторых, это позволяет провести полную регрессию сайта. 
       тестирование.
       Когда используется файл urls.txt, siege считывает все URL-адреса в этом файле в память и запускается
       через список одним из двух способов, последовательно или случайным образом. Запуск по умолчанию
       последовательно от начала до конца и обратно до тех пор, пока параметр --reps или --time не будет
       был удовлетворен. Если выбрана опция -i/--internet, осада проходит через файл
       случайным образом имитируя стресс, применяемый сообществом пользователей Интернета.
       Параметр -f/--file позволяет вам выбрать файл, отличный от файла urls.txt по умолчанию. Ты
       также может указать Siege использовать другой файл с директивой «file» в .siegerc,
       т. е. «файл = /usr/local/etc/urls.txt»
         Вы можете устанавливать и ссылаться на переменные внутри файла urls.txt. Все переменные должны быть
       объявляются ДО того, как на них ссылаются. Переменные объявляются с помощью оператора "=",
       ПЕРЕМЕННАЯ = ЗНАЧЕНИЕ. Затем на них ссылаются внутри $() или ${}, например: $(HOST), ${HOST}
        ХОСТ=joey. joedog.org
       http://${HOST}/browse.jsp?size=5
       http://${HOST}/admin.jsp?name=ralph
 

ПРИМЕР ФАЙЛ

       Это пример файла urls.txt. Строки, начинающиеся с решётки (#), являются комментариями и игнорируются.
       осадой.
       #
       # Пример файла urls.txt
       # база данных URL для осады
       #
       http://www.хаха.com/index.html
       http://www.haha.com/howto/index.html
       http://www.haha.com/cgi-bin/howto/display.cgi?1013
       www.haha.com/cgi-bin/fm.cgi?first=j.&last=fulmer
       https://www.haha.com/index.shtml
       https://www.whoohoo.com/my_whoohoo.jsp
       # Данные POST требуют директивы POST
       www.haha.com/cgi-bin/foo.cgi POST first=bart&last=simpson
       www.haha.com/hoho.jsp POST name=jeff&pass=secret
       # POST содержимое файла с помощью
       # символ ввода строки "<"
       http://www.haha.com/my.jsp ОТПРАВИТЬ 
 АВТОР 
       Джеффри Фулмер  org> и др.
 
 ОШИБКИ 
       Сообщайте об ошибках по адресу [email protected]. Дайте подробное описание проблемы и сообщите
       версия осады, которую вы используете.
 
 АВТОРСКОЕ ПРАВО 
       Copyright © 2007 Джеффри Фулмер и др.
       Эта программа является бесплатным программным обеспечением; вы можете распространять его и/или изменять в соответствии с условиями
       Стандартная общественная лицензия GNU, опубликованная Free Software Foundation; или
       версии 2 Лицензии или (по вашему выбору) любой более поздней версии.
       Эта программа распространяется в надежде, что она будет полезна, но БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ;
       даже без подразумеваемой гарантии КОММЕРЧЕСКОЙ ПРИГОДНОСТИ или ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ.
       Дополнительные сведения см. в Стандартной общественной лицензии GNU.
       Вы должны были получить копию Стандартной общественной лицензии GNU вместе с этой программой;
       если нет, напишите в Free Software Foundation, Inc. , 675 Mass Ave, Cambridge, MA 02139.,
       США.
 
 НАЛИЧИЕ 
       Самая последняя выпущенная версия siege доступна по анонимному FTP с
       ftp.joedog.org в каталоге pub/siege.
 
 СМ.   ТАКЖЕ 
       осада(1) siege.config(1) закладкаосада(7)
 
 python — Поиск и извлечение URL-адреса из текстового файла 
 спросил
  4 года, 2 месяца назад 
 Изменено
 4 года, 2 месяца назад
 Просмотрено
 885 раз
 Я хочу получить URL-адрес, начинающийся с http:// или https://, из текстового файла, который также содержит другой несвязанный текст, и передать его в другой файл/список.
 деф тест():
        с open('findlink.txt') в качестве входного файла, open('extractlink. txt', 'w') в качестве исходящего файла:
            для строки в файле:
                если "https://" в строке:
                    outfile.write(строка[строка.найти("https://"): строка.найти("")])
            распечатать("Готово")
 
 В настоящее время код ничего не делает.
 Редактировать: я вижу, что за это проголосовали отрицательно, как обычно, могу ли я что-нибудь добавить?
 Это не дубликат, пожалуйста, внимательно перечитайте.
 питон
 питон-3.x
 13
 Вы можете использовать  re  для извлечения всего URL-адреса.
 В [1]: st = '''https://regex101.com/ ha the hkj adh erht https://regex202.gov
   ...: h euy ashiu fa https://regex303.com aj feij ajj ai http://regex101.com/'''
В [2]: ул.
Out[2]: 'https://regex101.com/ ha the hkj adh erht https://regex202.gov h euy ashiu fa https://regex303.com aj feij ajj ai http://regex101.com/'
В [3]: импорт ре
В [4]: ​​a = re. compile(r"https*://(\w+\.\w{3})/*")
В [5]: для i в a.findall(st):
   ...: напечатать (я)
regex101.com
regex202.gov
regex303.com
regex101.com
 
 Для переменной tld и пути:
 st = '''https://regex101.com/ ha the hkj adh erht https://regex202.gov h euy ashiu fa https://regex303.com aj feij ajj ai http://regex101.com/ ie fah fah http://regex101.co/ ty ahn fah jaio l http://regex101/yhes.com/'''
a = re.compile(r"https*://([\w/]+\.\w{0,3})/*")
для i в a.findall(st):
    печать (я)
regex101.com
regex202.gov
regex303.com
regex101.com
regex101.co
regex101/yhes.com
 
 3
 9\s]+)", строка).group("url")
 outfile.write(url)
 кроме AttributeError:
 проходить
 распечатать("Готово")
 5
 Вот почему в настоящее время код ничего не делает:
 
 outfile.write(line[line.find("https://"): line.
This entry was posted in Популярное