Html loc index html

Имея более чем 10-летний опыт и наблюдая за 5 летними программистами и верстальщиками часто вижу что они все равно не разбираются в путях и урлах!!
И это действительно беда.

Поэтому решил написать данную статью чтобы расставить точки над i!

Для начала нужно разделить

(далее URL или урл) и

пути к папкам и файлам

на сервере (далее путь)!

1.html — может быть как путь так и ссылка
C:\webservershome est1.locwwwindex.php — это однозначно путь!
http://test1.loc/index.php — а это однозначно ссылка!

НАЧНЕМ С ССЫЛОК!

Сразу проясним про ссылки платформонезависимы, в отличие от путей. То есть не важно на маке или на линуксе или на винде, ссылки не зависят от ОС (в отличие от путей).

Рассмотрим пример самой простой ссылки, допустим на находимся по адресу: http://test1.loc/1.html и нам нужно сделать ссылку на файл 2.html, то в таком случае ссылку можно вполне указать таким образом:
2.html
Это называется относительная ссылка, потому-что она указывается относительно нашего местоположения.
Поясню:
— сейчас мы находимся по адресу: http://test1.loc/1.html а ссылка 2.html в итоге будет вести на адрес: http://test1.loc/2.html,
— если бы мы находились по адресу: http://test2.loc/1.html а ссылка 2.html в итоге будет вести на адрес: http://test2.loc/2.html,
— если бы мы находились по адресу: http://test2.loc/3/1.html а ссылка 2.html в итоге будет вести на адрес: http://test2.loc/3/2.html,
— если бы мы находились по адресу: http://test2.loc/3/4/5/6/1.html а ссылка 2.html в итоге будет вести на адрес: http://test2.loc/3/4/5/6/2.html,

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

Кстати не будем рассматривать адреса (ссылки) по протоколу file:// — это когда мы открываем html файл (он же верстка) для просмотра без сервера, например так выглядит ссылка на файл на рабочем столе:
file:///C:/Users/sympler/Desktop/мой-супер-проект/index.html
но никогда такие ссылки не надо вставлять и на практике я их пока нигде не применял, поэтому и в разъяснениях такие ссылки я не рассматриваю (то есть считаю исключением из правил).

Теперь вернемся к примерам:
— находимся мы по адресу: http://test2.loc/1.html и нужно указать ссылку на файл good.html который находится в папке ‘articles’, относительная ссылка будет выглядеть так: articles/good.html, а полная (абсолютная) ссылка http://test2.loc/articles/good.html
— находимся мы по адресу: http://test2.loc/articles/good.html и нужно указать ссылку на файл 1.html который находится на уровень выше, относительная ссылка будет выглядеть так: ../1.html, а полная (абсолютная) ссылка http://test2.loc/1.html

То есть чтобы подняться на уровень выше, нужно указать две точки со слешем: ../
Соответственно на 2 уровня выше: ../../
На три уровня выше: ../../../

Кстати относительные ссылки и удобны тем, что в них не указан адрес сайта и соответственно при смене адреса сайта не нужно будет везде менять ссылки. Отметим, что это очень актуально для домашних заданий наших учеников которые делают работу у себя локально на домене, например, x5.loc, а наставник у себя проверяет на домене x2000.loc и скрипт по этой причине может не работать, не говоря о случаях, когда ученик скрипт размещал в корне домена, а наставник в подпапке разместил.
Но тот же torrents.ru, который закрыли, и когда они купили новый домен rutracker.org — просто переносом файлов и заменой логотипа не обошелася, еще несколько дней они вручную меняли ссылки чтобы все работало, а вот проблем с переездом из kaliningrad.ru на newkaliningrad.ru я лично не заметил, хотя возможно им сделать было проще пробежавшись по всем файлам и записям в базе данных заменив старый адрес на новый.

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

Также обращаю внимание на рекомендуемые символы, которые можно использовать в ссылках:
цифры [0-9], латиница в нижнем регистре [a-z], точка[.], слеш [/], дефис [-], нижнее подчеркивание [_], вопрос [?], амперсанд [&]

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

И еще полезная статья, заодно немного проясните для себя задание по транслитерации.

ИДЕМ ДАЛЬШЕ

Cсылки (они же URL) вставляются в тег A, а точнее в его атрибут HREF, а пути сюда точно не вставляются!

кстати если начинать относительные ссылки со слеша, то они являются полуотносительными, но относительно адреса сайта, то есть ссылка /articles.html
в итоге будет конвертироваться в http://test1.loc/articles.html и не важно на каком мы сейчас уровне,
соответственно ссылка / (просто слеш) — это ссылка на главную страницу, то есть на адрес сайта без страницы: http://test1.loc/ — он же аналогичен адресу без слеша на конце.
Именно этот способ чаще всего используется при указании ссылок, то есть указываются полуотносительные ссылки.

Стоит заменить что есть ли слеш на конце урла или нет — большая разница, за исключением главной страницы, поскольку страницы: http://test1.loc/4444 и http://test1.loc/4444/ это разные страницы, если не включен mod_rewrite то первая ссылка ведет на файл 4444 (да, бывают файлы без расширения), а втором случае ссылка ведет на папку 4444, а точнее на файл index.html в папке 4444, то есть если указана папка, то открывается файл по умолчанию index.html, если его нет, то показывается список файлов в этой папке (если это не отключено из-за безопасности, на OpenServer отключено). Аналогично если указывается адрес сайта без файла: http://test1.loc то открывается файл http://test1.loc/index.html или http://test1.loc/index.php тут уж как настроен денвер (точнее его компонент apache)

В некоторых проектах (userCMS например) слеш на конце всегда убирается, в некоторых по этому поводу полная неразбериха и дублирование страниц (WordPress, Joomla).

НЕМНОГО О MOD_REWRITE

Модреврайт — это модуль апача, он переписывает урлы. То есть вводя адрес: http://test2000.loc/3333.html на самом деле может открываться файл 8888.html или 7777.php, ну то есть любой.
Чаще всего указываются такие правила:
-для ссылок вида xxxxx.html подгружать файл article.php?page=xxxxx
-для ссылок вида yyyyy/xxxxx.html подгружать файл article.php?dir=yyyyy&page=xxxxx

а еще чаще:
для любой ссылки подгружать index.php
Так реализовано в большинстве cms и cmf
Поэтому, когда видите адрес: site.ru/news/ — то скорее всего никакой папки news на сервере нет.

ПЕРЕХОДИМ К ПУТЯМ

Теперь настало время разобраться с путями.
Рассмотрим примеры (кавычки опущены для читабельности):

в данном случае мы обращаемся к файлу 1.txt — и путь к нему относительный, и относительно скрипта php из которого мы вызываем данную функцию.
Но иногда для линукс серверов правильнее будет обращаться так:

соответственно для файлов в папках:
file_get_contents(./dir/dir/1.txt);

Стоит заметить, что слеш тоже обратный, для линукс систем он родной, как и для мака, а вот в виндовс пути разделяются обратным слешем. Но при этом с прямым слешем тоже все работаем верно, за редким исключением.
В идеале конечно для полной совместимости существует константа: DIRECTORY_SEPARATOR которая в линуксе содержит / , а в Windows — , можно самому создать такую константу или переменную, обычно ее называют сокращенно: DS

Для перехода наверх, также как в ссылках используется две точки:

file_get_contents(../../dir/dir/1.txt);
opendir(‘../../articles/’);
fopen(‘../my.xml’);

ПОЛУОТНОСИТЕЛЬНЫЕ=АБСОЛЮТНЫЕ ПУТИ

а что же будет если мы укажем путь начиная со слеша:
file_get_contents(/1.txt);
Тогда система попытается открыть файл: C:\1.txt для виндовс систем и для OpenServer в частности, для линукс систем /1.txt

Соответсвенно попытка создать папку

mkdir(‘/articles’);
создаст ее в C:\articles
Правильно создавать:
mkdir(‘./articles’);

А попытка удалить папку
rmdir(‘/home’);
— это равноценно удалению C:\home- он же C:\home, а в линукс системе папка /home — аналогична папке C:\Users

РЕКОМЕНДАЦИИ

Как же делают в проектах?
Какой же способ самый верный и надежный?
На самом деле все просто, в каждом проекте в начале скрипта создается константа с полным путем до корневой папки, обычно ее называют: ROOT_DIR
вот так она создается:

а потом вот так все пути прописываются:

АНАЛОГИЧНО со ссылками

а потом вот так все ссылки прописываются (вставил лишние пробелы, думаю догадаетесь где):

Ввожу: http://html.loc/www/formadata.php
Выдает: Not Found
The requested URL /www/formadata.php was not found on this server.

Вы ошиблись при наборе URL в браузере. Вероятнее всего, сервер пытается найти файл X:/home/html.loc/www/www/formadata.php, которого не существует.

В случае использования CGI-скриптов, корректные пути к CGI-директориям следующие:

URL Куда указывает
http://***/cgi-glob/script.cgi /home/cgi-glob/script.cgi
http://***/cgi/script.cgi /home/***/cgi/script.cgi
http://***/cgi-bin/script.cgi /home/***/cgi-bin/script.cgi

Apache/2.2.4 (Win32) mod_ssl/2.2.4 OpenSSL/0.9.8k PHP/5.3.3 Server at html.loc Port 80

Ввожу:http://html.loc/formadata.php
Выводит:Not Found
The requested URL /formadata.php was not found on this server.

Вы ошиблись при наборе URL в браузере. Вероятнее всего, сервер пытается найти файл X:/home/html.loc/www/formadata.php, которого не существует.

В случае использования CGI-скриптов, корректные пути к CGI-директориям следующие:

В этом документе приведено описание XML-схемы протокола Sitemap.

Формат протокола Sitemap состоит из XML-тегов. Для всех значений данных в файле Sitemap должно использоваться маскирование. В файле необходимо использовать кодировку UTF-8.

• В начале поставьте открывающий тег , а в конце поставьте закрывающий тег .
• Укажите область имен (стандарт протокола) в теге .
• Включите запись для каждого URL-адреса как родительский тег XML.
• Включите дочернюю запись для каждого родительского тега .

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

Также все URL-адреса в файле Sitemap должны быть с одного узла, например www.example.com или store.example.com. Дополнительные сведения см. в разделе Расположение файла Sitemap

Пример XML-файла Sitemap

Ниже приведен пример файла Sitemap, в котором содержится только один URL-адрес и использованы все необязательные теги. Необязательные теги выделены курсивом.

Определения XML-тегов

Ниже описаны доступные XML-теги.

Атрибут	Описание
обязательный

Инкапсулирует этот файл и указывает стандарт текущего протокола.

обязательный

Родительский тег для каждой записи URL-адреса. Остальные теги являются дочерними для этого тега.

обязательный

URL-адрес страницы. Этот URL-адрес должен начинаться с префикса (например, HTTP) и заканчиваться косой чертой, если Ваш веб-сервер требует этого. Длина этого значения не должна превышать 2048 символов.

необязательно

Дата последнего изменения файла. Эта дата должна быть в формате W3C Datetime. Этот формат позволяет при необходимости опустить сегмент времени и использовать формат ГГГГ-ММ-ДД.

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

необязательно

Вероятная частота изменения этой страницы. Это значение предоставляет общую информацию для поисковых систем и может не соответствовать точно частоте сканирования этой страницы. Допустимые значения:

Значение"всегда" должно использоваться для описания документов, которые изменяются при каждом доступе к этим документам. Значение "никогда" должно использоваться для описания архивных URL-адресов.

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

необязательно

Приоритетность URL относительно других URL на Вашем сайте. Допустимый диапазон значений — от 0,0 до 1,0. Это значение не влияет на процедуру сравнения Ваших страниц со страницами на других сайтах — оно только позволяет указать поисковым системам, какие страницы, по Вашему мнению, более важны для сканеров.

Приоритет страницы по умолчанию — 0,5.

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

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

Маскирование символов

В файле Sitemap должна использоваться кодировка UTF-8 (обычно ее можно выбрать при сохранении данного файла). В XML-файлах для всех значений данных (включая URL-адреса) должно использоваться маскирование символов, перечисленных ниже в таблице.

Символ		Маскирование

Амперсанд & & Одинарные кавычки ‘ ‘ Двойные кавычки " " Больше > > Меньше

Кроме того, для всех URL (включая URL из вашего файла Sitemap) должны использоваться маскирование и кодировка для удобочитаемости веб-сервером, на котором они размещаются. Однако, если для создания своих URL Вы используете какой-либо вид скрипта, инструментального средства или журнала (любой способ кроме ввода их вручную), то маскировка и кодировка применяются автоматически. Убедитесь в том, что все URL-адреса соответствуют стандарту RFC-3986 для URI, стандарту RFC-3987 для IRI и XML-стандарту.

Ниже приведен пример URL-адреса, в котором используется символ, отличный от ASCI ( ü ), а также символ, для которого необходимо маскирование ( & ):

Ниже этот же URL-адрес приведен в кодировке ISO-8859-1 (для размещения на сервере, который использует эту кодировку) с маскированием:

Ниже этот же URL-адрес приведен в кодировке UTF-8 (для размещения на сервере, который использует эту кодировку) и с использованием маскирования:

Ниже приведен тот же URL-адрес, но с использованием маскирования:

Пример XML-файла Sitemap

В следующем примере показан файл Sitemap в XML-формате. Sitemap в этом примере содержит небольшое число URL-адресов, каждый из которых использует разное сочетание необязательных параметров.

Использование файлов индекса Sitemap (для создания группы из нескольких файлов Sitemap)

Можно предоставить несколько файлов Sitemap, однако в каждом из этих файлов должно быть не более 50000 URL, а размер каждого из этих файлов не должен превышать 50 МБ. При необходимости файл Sitemap можно сжать с помощью архиватора gzip, чтобы уменьшить требования к пропускной способности канала. Однако размер файла sitemap без сжатия не должен превышать 50 МБ. Если необходимо перечислить более 50000 URL-адресов, следует создать несколько файлов Sitemap.

Если требуется передать несколько файлов Sitemap, необходимо перечислить каждый из этих файлов в файле индекса Sitemap. В файле индекса Sitemap может быть перечислено не более 50000 файлов Sitemap. Размер этого файла не должен превышать 50 МБ (52 428 800 байт) и может быть сжат. У вас может быть несколько файлов Sitemap. Формат XML-файла индекса Sitemap очень похож на формат XML-файла Sitemap.

Файл индекса Sitemap должен:

• В начале поставьте открывающий тег , а затем поставьте закрывающий тег .
• Добавьте запись для каждого файла Sitemap как родительский XML-тег.
• Включите дочернюю запись для каждого родительского тега .

Необязательный тег также доступен для файлов индекса Sitemap.

Примечание. Файл индекса Sitemap может указывать только файлы Sitemap, которые находятся на том же сайте, что и файл индекса Sitemap. Например, файл индекса http://www.vashsait.ru/sitemap_index.xml может включать файлы Sitemap, размещенные на сайте http://www.vashsait.ru, но не на сайте http://www.primer.ru или http://vashkhost.vashsait.ru. Для файла индекса Sitemap, как и для файлов Sitemap, необходимо использовать кодировку UTF-8.

Пример индекса XML Sitemap

В следующем примере показан файл индекса Sitemap, который содержит два файла Sitemaps.

Примечание: для URL-адресов Sitemap, как и для всех значений в XML-файлах, должно использоваться маскирование .

Определения XML-тегов индекса Sitemap

Указывает местоположение файла Sitemap.

Этим местоположением может быть файл Sitemap, файл Atom, файл RSS или простой текстовый файл.

Указывает время изменения соответствующего файла Sitemap. Не соответствует времени изменения ни одной из страниц в этом файле Sitemap. Значение тега "lastmod" должно быть представлено в формате W3C Datetime.

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

Другие форматы файла Sitemap

Протокол Sitemap дает возможность обеспечить поисковые системы подробной информацией о страницах, и мы рекомендуем его использовать, поскольку при этом можно указать дополнительные сведения о страницах сайта, а не только их URL. Помимо протокола XML мы также поддерживаем каналы RSS и текстовые файлы, которые предоставляют более ограниченную информацию.

Канал синдикации

Вы можете предоставить канал RSS 2.0, Atom 0.3 или 1.0. Как правило, этот формат используется только в том случае, если на сайте уже есть канал синдикации. Обратите внимание, что в этом случае поисковые системы, возможно, не получат информацию обо всех URL на вашем сайте, поскольку данный канал предоставляет информацию только по последним URL. Однако поисковые системы могут использовать эту информацию, чтобы обнаружить другие страницы сайта, переходя по ссылкам на страницах канала в процессе обычного сканирования. Убедитесь, что канал расположен в каталоге самого высокого уровня, который должен сканироваться поисковой системой. Поисковые системы извлекают информацию из канала следующим образом.

• поле – указывает URL
• поле даты изменения (поле

для каналов RSS и дата для каналов Atom) – указывает, когда каждый URL был изменен в последний раз. Использовать поле даты изменения необязательно.

Текстовый файл

Вы можете предоставить простой текстовый файл, содержащий один URL в строке. Этот текстовый файл должен соответствовать следующим требованиям.

• В этом текстовом файле в каждой строке должен быть только один URL. Эти URL не могут содержать новые внедренные строки.
• Необходимо указать URL полностью, включая префикс http.
• Каждый текстовый файл может содержать не более 50 000 URL, и его размер не должен превышать 50 МБ (52 428 800 байт). Если сайт включает более 50000 URL, можно разделить этот список на несколько текстовых файлов и передать каждый файл отдельно.
• Для этого текстового файла необходимо использовать кодировку UTF-8. Ее можно задать при сохранении файла (например, в программе "Блокнот" она указана в меню "Кодировка" диалогового окна "Сохранить как").
• Этот текстовый файл не должен включать никаких других данных, кроме списка URL.
• Этот текстовый файл не должен содержать данных заголовка или нижнего колонтитула.
• При необходимости файл Sitemap можно сжать с помощью архиватора gzip, чтобы уменьшить требования к пропускной способности канала.
• Этому текстовому файлу можно присвоить любое имя. Убедитесь, что ваши URL-адреса соответствуют стандарту RFC-3986 для URI-адресов и стандарту RFC-3987 для файлов IRI.
• Загрузите этот текстовый файл в каталог самого высокого уровня, который должен сканироваться поисковой системой, и убедитесь, что в файл не внесены адреса URL, находящиеся в каталоге более высокого уровня.

Ниже приведен пример строк текстового файла.

Местоположение файла Sitemap

Местоположение файла Sitemap определяет набор URL-адресов, которые можно включить в этот Sitemap. Файл Sitemap, расположенный в каталоге http://primer.ru/catalog/sitemap.xml, может включать любые URL-адреса, начинающиеся с http://primer.ru/catalog/, но не должен включать URL-адреса, начинающиеся с http://primer.ru/images/.

Если у Вас есть разрешение на изменение файла http://primer.org/path/sitemap.xml, можно предположить, что у Вас также имеется разрешение на предоставление информации для URL с префиксом http://primer.org/path/. Примеры допустимых URL в http://primer.ru/catalog/sitemap.xml включают:

К недопустимым URL-адресам в файле http://primer.ru/catalog/sitemap.xml относятся следующие:

Это значит, что все URL-адреса, перечисленные в файле Sitemap, должны использовать один и тот же протокол (в данном случае — HTTP) и должны быть размещены на том же хосте, что и файл Sitemap. Например, если файл Sitemap расположен по адресу http://www.primer.ru/sitemap.xml, в нем могут быть указаны URL-адреса из субдомена http://subdomen.primer.ru.

URL-адреса, которые считаются недопустимыми, исключаются из дальнейшего рассмотрения. Настоятельно рекомендуется поместить файл Sitemap в корневой каталог Вашего веб-сервера. Например, если адрес Вашего сервера — primer.ru, Ваш файл индекса Sitemap должен быть размещен по адресу http://primer.ru/sitemap.xml. Возможно, в некоторых случаях нужно будет создать различные файлы Sitemap для различных путей на Вашем сайте (например, если полномочия доступа в Вашей организации установлены таким образом, что доступ с правом записи к различным каталогам предоставляется отдельно).

Если при передаче файла Sitemap используется путь, содержащий номер порта, необходимо включить этот номер порта в путь в каждом URL, перечисленном в файле Sitemap. Например, если Ваш файл Sitemap находится в http://www.primer.ru:100/sitemap.xml, то каждый URL, перечисленный в файле Sitemap, должен начинаться с http://www.primer.ru:100.

Файлы Sitemap и перекрестная отправка

Чтобы отправить файлы Sitemap на несколько узлов с одного, необходимо "подтвердить" владение узлом(-ами) для которого URL-адреса отправляются в файле Sitemap. Ниже приведен пример. Допустим, необходимо отправить файлы Sitemap на 3 узла:

Более того, необходимо разместить все три файла Sitemap на одном узле: www.sitemaphost.com. Таким образом, URL-адреса Sitemaps будут следующими:

По умолчанию это приведет к ошибке "перекрестная отправка", так как была произведена попытка отправить URL-адреса для узла www.host1.com через файл Sitemap, который расположен на узле www.sitemaphost.com (то же самое и для двух других узлов). Первый способ избежать этой ошибки — это доказать свое владение (например право изменять файлы) узлом www.host1.com. Это можно сделать, изменив файл robots.txt на узле www.host1.com, чтобы указать на файл Sitemap на узле www.sitemaphost.com.

В этом примере файл robots.txt на узле http://www.host1.com/robots.txt содержал бы строку "Sitemap: http://www.sitemaphost.com/sitemap-host1.xml". Изменив файл robots.txt на узле www.host1.com с указанием на файл Sitemap на узле www.sitemaphost.com, вы косвенно доказали, что являетесь владельцем узла www.host1.com. Другими словами, кто бы не управлял файлом robots.txt на узле www.host1.com, он доверяет файлу Sitemap на узле http://www.sitemaphost.com/sitemap-host1.xml на предмет содержания URL-адресов для узла www.host1.com. Эту же процедуру можно повторить для двух других узлов.

Теперь можно отправлять файлы Sitemap на узел www.sitemaphost.com.

Если в файле robots.txt указан определенный узел, например http://www.host1.com/robots.txt, это указывает на файл Sitemap или файл индекса Sitemap на другом узле. Скорее всего это означает, что для каждого конечного файла Sitemap, например http://www.sitemaphost.com/sitemap-host1.xml, все URL-адреса принадлежат узлу, который на них указывает. Это происходит потому, что, как было указано ранее, ожидается, что файл Sitemap будет содержать URL-адреса только с одного узла.

Проверка файла Sitemap

Для определения элементов и атрибутов, которые могут появляться в Вашем файле Sitemap, используются следующие XML-схемы. Эту схему можно загрузить с помощью приведенных ниже ссылок.

Ряд инструментов может помочь при проверке структуры файла Sitemap на основе этой схемы. Вы можете найти список инструментов для работы с XML-файлами в каждом из следующих местоположений:

Для проверки Вашего файла Sitemap или файла индекса Sitemap по этой схеме в XML-файл нужно добавить дополнительные заголовки, как показано ниже.

Sitemap:

Файл индекса Sitemap:

Расширение протокола Sitemaps

Протокол Sitemap можно расширить с помощью Вашего собственного пространства имен. Просто укажите это пространство имен в корневом элементе. Например:

Уведомления для сканеров поисковых систем

После того как файл Sitemap создан и размещен на веб-сервере, необходимо сообщить о местонахождении этого файла поисковым системам, поддерживающим этот протокол. Это можно сделать следующим образом.

Затем поисковые системы смогут извлечь файл Sitemap и разрешить своим сканерам доступ к URL-адресам.

Передача файла Sitemap с помощью интерфейса поисковой системы

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

Как указать местоположение файла Sitemap в файле robots.txt

Можно указать местоположение файла Sitemap, используя файл robots.txt. Для этого просто добавьте следующую строку:

Эта инструкция не зависит от строки агента пользователя, поэтому неважно, где она размещается в файле. При наличии файла индекса Sitemap можно включить местоположение только этого файла. Перечислять каждый отдельный файл Sitemap, указанный в файле индекса, не нужно.

Можно указать несколько файлов Sitemap для каждого файла robots.txt.

Передача файла Sitemap с помощью запроса HTTP

Чтобы отправить файл Sitemap с помощью HTTP-запроса (замените на URL, указанный поисковой системой), создайте запрос для следующего URL-адреса.

Например, если файл Sitemap находится в архивном файле http://www.primer.ru/sitemap.gz, URL-адрес будет следующим:

Добавьте кодировку URL для всех символов после /ping?sitemap=:

Можно отправить http-запрос, используя "wget", "curl" или другой механизм по выбору. Успешный запрос возвратит код отклика HTTP 200; если получен другой отклик, необходимо повторно передать запрос. Код отклика HTTP 200 указывает только на то, что поисковая система получила Ваш файл Sitemap, но это не значит, что сам файл Sitemap или содержащиеся в нем URL допустимы. Самый простой способ — создать автоматическое задание для регулярного создания и передачи файлов Sitemap.
Примечание. Предоставляя файл индекса Sitemap, необходимо инициировать только один http-запрос, который включает местоположение файла индекса Sitemap; отправлять отдельные запросы для каждого файла Sitemap, указанного в этом индексе, не нужно.

Атрибут	Описание
обязательный	Инкапсулирует информацию о всех файлах Sitemap в этом файле.
обязательный	Инкапсулирует информацию об отдельном файле Sitemap.
обязательный
необязательно