Почему мы называем html страницу index html

Простой вопрос. Как назвать страницы сайта.

Подскажите знающие люди. Главную страницу всегда называем index.html с этим понятно, остальные не важно как назвать, с этим тоже понятно. Я в своем случае назвал главную — index1.html, остальные index2.html, index3.html и дт. Вопрос: С точки зрения поисковой оптимизации есть разница между названием главной страницы index.html и index1.html Т.е. отличие в цифре»1″ если она будет присутствовать в название главной странице, это ведь никак не повлияет или повлияет ?

eTarget 2011:Панельная дискуссия «Стратегия и планирование рекламной кампании в интернете»
eTarget 2011: Круглый стол «Реклама в онлайн-видео»
Могут ли «плохие» входящие ссылки привести к ухудшению ранжирования?

На сайте с 02.04.2009
18 августа 2012, 15:23

Webmaster START:
Вопрос: С точки зрения поисковой оптимизации есть разница между названием главной страницы index.html и index1.html

Нету. Но с точки зрения веб-сервера главную, индексный файл, лучше назвать просто index.html

На сайте с 03.08.2012
18 августа 2012, 15:27

siv1987:
Нету. Но с точки зрения веб-сервера главную, индексный файл, лучше назвать просто index.html

Да я так и сделал.

Просто как то не очень красиво получалось, что index2.html есть, а index1.html отсутствует. Думал переназвать что ли, ну тогда лучше оставлю как есть.

На сайте с 18.05.2010
18 августа 2012, 16:19
Webmaster START:
остальные не важно как назвать, с этим тоже понятно

ошибаетесь — ключевик в урле тоже нужен

Телеграмм канал о партнерках с инвайтами (https://t-do.ru/bablonetorig)
На сайте с 03.08.2012
18 августа 2012, 16:26
pipez:
ошибаетесь — ключевик в урле тоже нужен

Я так понимаю, главная всегда index.html, остальные из название сайта взять, к примеру: сайт на финансовую тематику и название с кредитами связано, в этом случае, credit2.html, credit3.html и тд. Правильно ?

На сайте с 03.11.2008
18 августа 2012, 16:47

Webmaster START:
Просто как то не очень красиво получалось, что index2.html есть, а index1.html отсутствует.

Ага, неаккуратненько как-то 🙂

Пациент заходит в кабинет к врачу.
— Доктор, у меня ТАМ проблемка!
— Раздевайтесь.
Пациент снимает туфли.
— Доктор, я тут туфельки поставлю аккуратненько?
— Да-да, как Вам будет угодно.
Снимает брюки.
— Доктор, можно я повешу брючки на спинку кресла аккуратненько?
— Да-да, конечно.
Снимает трусы.
— А можно трусики положить тут аккуратненько?
— Кладите-кладите.
Пациент, обнажив необходимую часть тела, подходит к врачу.
— Доктор, видите, у меня одно яичко немного ниже, чем другое.
— Ничего страшного, это абсолютно нормально!

— Но это неаккуратненько как-то .

Вопрос / ответ

Панель управления хостингом

E-Mail

Управление E-mail аккаунтами
MX-записи
Почтовый веб-клиент: Roundcube
Перенаправления
Автоответчики
Списки рассылок
Черный список E-Mail
Сообщения об отсутствии
Универсальный почтовый адрес

Базы данных MySQL

phpMyAdmin
Создание базы данных
Удаление базы данных
Добавление пользователей
Изменение пароля базы данных

SSL защита сайта

Установка сертификата Let’s Encrypt
Установка купленного сертификата
Использование сертификатов сервера
Создание самоподписанного сертификата
Загрузка файлов на защищенный сайт

Управление DNS

DNS записи
Изменение параметров DNS
Информация для новичков

FTP аккаунты

Создание FTP аккаунта
Изменение и удаление FTP аккаунтов
Создание FTP аккаунта с доступом к конкретному поддомену

Поддомены

Создание поддоменов
Удаление поддоменов
Статистика поддоменов
Лог использования и лог ошибок
Создание FTP аккаунта с доступом к конкретному поддомену

Резервные копии

Создание резервной копии
Хранение резервных копий
Выбор того, что необходимо сохранить в резервной копии
Восстановление из резервной копии

Менеджер файлов

Навигация
Загрузка файлов
Создание новых папок и файлов
Копирование и перемещение файлов
Редактирование файлов
Переименование файлов
Изменение прав доступа к файлам
Удаление файлов и папок

Загрузка файлов сайта на сервер

Структура директорий
Загрузка через FTP
Загрузка с помощью файлового менеджера
Основной файл сайта (index)

Статистика сайта

Дисковое пространство
Системные логи
Статистика Webalizer
Информация об аккаунте

Выполнение скриптов

Программные пути
PHP скрипты
CGI скрипты
Установленные модули Perl
Общие сведения о правах доступа

С чего начать

Вход в панель управления
Выход из панели управления

Разное

Дополнительные домены
Перенаправление сайта
Доменные указатели
Cron задачи
Страницы ошибок
Запароленные папки
Mime-типы
Обработчики Apache
Ключи входа

Технические вопросы

SSH, FTP, SFTP

Подключение по SSH
Подключение по FTP
Подключение по SFTP
Установка composer

Базы данных MySQL

Хост для подключения к MySQL
Подключение к MySQL извне
Подключение на внешний сервер Mysql
Логин/пароль для входа в PhpMyAdmin

Почта

Настройка отправки писем с сайта
Пересылка почты
Адрес авторизации в почте
Сайт рассылает спам
Лимит на отправку писем
Статистика отправки писем
Настройка почтового клиента
Настройка заголовка From

Memcached

Как заказать Memcached сервер
Использование Memcached
Memcached и WordPress
Memcached и Joomla
Memcached и Bitrix

Почтовый хостинг

SSL-сертификаты

Подтверждение сертификата

Домены

NS сервера

Оплата услуг, тарифы

Изменение тарифного плана

CMS хостинг

WordPress хостинг
1С хостинг

Партнерская программа

Бухгалтерия, документы

Заключение бумажного договора
Акты выполненных работ
Отказ от услуг

БелГИЭ

Регистрация сайта в БелГИЭ
Изменение данных о сайте
Удаление сайта из БелГИЭ
Регистрация субдоменов

Другие вопросы

Чем открыть файл PDF

Основной файл сайта (index)

index.html — файл по умолчанию для любой веб-папки. Это означает, что когда посетитель переходит по адресу http://site.by, в действительности сервер открывает файл http://site.by/index.html. Это актуально для любой общедоступной папки, включая поддомены.

При загрузке основного файла веб-сайта, не забудьте назвать его index.html. Могут использоваться и другие расширения для главного файла index (index.php, index.shtml и др.), в зависимости от того какой язык используется.

Нет серверным веб-приложениям

В 1993 году, когда появилась Всемирная паутина, World-Wide-Web, веб-страницы были представлены статическими HTML-файлами, содержащими ссылки на другие такие же файлы. Но вскоре, благодаря таким технологиям, как CGI, Perl и Python, веб-сайты стали оснащать динамическим функционалом, который серьёзно расширил их возможности.

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

Недавно я пришёл к выводу о том, что я делал всё неправильно. Я собираюсь прекратить писать серверные веб-приложения, а в этой статье хочу объяснить причины, по которым вам стоит принять такое же решение.

Прекратите писать серверные веб-приложения

Веб-запрос: путь позора

Рассмотрим типичный веб-запрос. Некто переходит по ссылке. Браузер выполняет запрос к серверу. Веб-сервер выполняет какой-то код и определяется с тем, что именно хочет увидеть посетитель, и что именно нужно отрендерить. Сервер загружает из базы данных нужную информацию и наполняет ей шаблон страницы. Сервер, наконец, рендерит то, что отправит в ответ на запрос, то есть — HTML-код, и отправляет это браузеру. Выглядит это всё довольно просто. Правда?

Как вам, возможно, известно, любое приложение, вышедшее за пределы «Hello World», очень быстро начинает сильно усложняться. Часто один запрос инициирует несколько обращений к базе данных или к другим внешним API. А чем больше обращений к базе данных и к различным службам — тем выше сетевая задержка. На разных уровнях информационных систем могут присутствовать кеши, нацеленные на решение проблем с производительностью, но усложняющие устройство систем. То, что мы называем «сервером», на самом деле, может быть представлено несколькими серверами, находящимися за балансировщиком нагрузки, что усложняет развёртывание систем.

Веб-запрос: путь позора

Обычно монолитные серверные приложения превращаются в монстров. А разбиение монолитного приложения на микросервисы означает необходимость выполнения больших объёмов работы. Это, кроме того, ещё сильнее усложняет информационные системы и плохо отражается на величинах задержек. Что же делать веб-разработчикам?

Веб-разработчикам стоит присмотреться к JAMstack

В последнее время то и дело встречаешься с понятием «JAMstack». Может, и вы что-то об этом слышали? Если предельно просто объяснить суть этого понятия, то окажется, что в JAMstack используются генераторы статических сайтов, с помощью которых создают страницы, содержащие HTML, CSS, JavaScript и другие материалы, а потом размещают это всё на CDN (Content Delivery Network, сеть доставки контента).

«Но это же… статический HTML? Это — всё равно, что размещать на серверах простые HTML-файлы? Шутите, что ли?»

На первый взгляд JAMstack выглядит как шаг назад. Правда?

Когда я впервые услышал о JAMstack, я подумал: «Этот подход к разработке веб-сайтов, возможно, хорошо подойдёт для страниц документации, для маркетинговых лендинговых сайтов и для блогов. Но не для настоящих веб-приложений. Спасибо, конечно, но я буду пользоваться моим собственным стеком технологий».

В общем, я попросту сбросил JAMstack со счетов. Прошу вас — не поступайте так, как я.

Правда о JAMstack

Серверы быстрее всего отвечают на запросы браузеров тогда, когда браузеры запрашивают у них обычные файлы. Что-то более сложное требует, в лучшем случае, обработки некоей информации процессором сервера, а в худшем случае всё сводится к «пути позора», о котором мы говорили выше. Быстрее всего клиентам отдаются файлы, которые размещены на CDN, так как файлы, благодаря распределённой природе сетей доставки контента, оказываются, в физическом смысле, ближе к тем, кому они нужны. CDN-провайдеры, кроме того, очень хорошо знают о том, что такое «масштабирование ресурсов», необходимое для поддержания работоспособности систем в моменты пиковых нагрузок и позволяющее предотвращать DDoS-атаки.

Самый быстрый и безопасный код — это его отсутствие

Буквы «JAM» в слове JAMstack — это сокращение от JavaScript, API и Markup (заранее отрендеренная разметка). За JAMstack стоит сравнительно простая идея. Абсолютно всё, что можно, нужно превратить в заранее отрендеренную разметку. Затем, после того, как эта разметка достигнет браузера, нужно, прогрессивно используя JavaScript и обращения к различным API, сделать приложение настолько динамическим и персонализированным, насколько это соответствует нуждам конкретного проекта. Подход к созданию сайтов, реализуемый в рамках JAMstack, перемещает вычисления, необходимые для приведения приложения в работоспособное состояние, с сервера в браузер.

В последнее время генераторы статических сайтов стали чрезвычайно функциональными. Они поддерживают массу возможностей, которые способны удовлетворить широкому спектру потребностей разработчиков. Кроме того, для тех, кому нужны простые инструменты для управления содержимым сайтов, появился новый рынок CMS (Content Management System, система управления контентом) без пользовательского интерфейса. Такие системы отлично дополняют подход к разработке проектов, применяемый в JAMstack. В ходе выполнения сборки проекта генератор статических сайтов может обращаться к API, к базам данных, к CMS, имеющим API, или к чему угодно другому, необходимому для максимизации объёма заранее отрендеренной разметки.

Если вам интересна тема JAMstack — то вот и вот — полезные статьи, а вот — хорошее видео об этом. Здесь можно найти большую коллекцию генераторов статических сайтов.

Лучшее из двух миров

Веб-разработчик может писать код JAMstack-приложений, пользуясь любимым языком и любимыми платформами! Только теперь фокус его внимания будет смещён на создание как можно более качественных API для его приложений. Навыки разработчика, кроме того, можно использовать в деле автоматизации генерирования статических ресурсов и развёртывания проектов.

Чем больше я узнавал о JAMstack — тем лучше я понимал то, какие именно преимущества этот подход даёт тому, кто его использует:

Упрощение архитектуры проектов.
Использование лучших API сторонних разработчиков.
Применение возможностей CDN.
Возможность уделять больше внимания удобству приложений для пользователей и соответствию веб-проектов нуждам заказчиков приложений.

Я уверен в том, что фронтенд- и бэкенд-разработчиков ждёт светлое будущее — будущее, где никому больше не придётся писать серверные веб-приложения.

Пользуетесь ли вы JAMstack?

JAMstack
веб-разработка
ruvds_переводы

Адаптация html-шаблона

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

Таким образом всё, что вам нужно сделать — заказать у дизайнера макет, у верстальщика — шаблон и далее заняться внедрением шаблона на сайт. Также вы можете воспользоваться уже готовым html-шаблоном. В этом случае, при поиске, именно такой запрос вам нужно писать в поисковой системе («html-шаблоны», «html-templates» и т.д.). Этим способом воспользуемся и мы.

Для написания данного урока и продолжения построение нашего сайта на CMS NetCat, нами был выбран бесплатный html-шаблон под названием «Shop Around».

Наш шаблон выглядит следующим образом:

Внедряемый html-шаблон

Рис.1 — Внедряемый html-шаблон

Данный шаблон легко может быть использован для небольшого интернет-магазина.

Сейчас давайте ненадолго перейдём в административный раздел NetCat и посмотрим, где должен находиться шаблон нашего сайта. На сайте под управлением NetCat вы можете использовать любое количество макетов (шаблонов). Мы будем использовать только один шаблон. Итак, управление макетами находится в разделе «Разработка: Макеты дизайна»:

Рис.2 — Раздел с существующими макетами

Как вы видите, у нас уже существует «Стандартный макет», но мы создадим новый.

Для создания нового макета необходимо нажать на пиктограмму с зелёным крестиком: у соответствующего раздела-родителя. Заметим, что у макетов, как и у разделов, так же существует иерархия и вложенность. Мы же в данном случае выбираем самый верхний пункт «Макеты дизайна»:

Рис.4 — Родительский пункт

При нажатии на кнопку добавления откроется стандартное окно добавления нового макета, оно же управление макетом.

Рис.5 — Окно для управления макетом

Структурированно наш макет должен делиться на:

Хедер (шапка). Верхняя часть сайтас логотипом, навигацией и т. п.
Контентная часть. Всё содержимое нашего сайта
Футер (подвал). Нижняя часть сайта со счётчиками, копирайтами и т. д.

Теперь давайте посмотрим на то, какие поля присутствуют в макете дизайна:

Название макета. Название используется только для разработчика и визуально на самом сайе никак не отображается.
Шаблоны вывода навигации. Данное поле содержит массивы, используемые при построении меню, путь по сайту («хлебные крошки») и т. п. Поле так же позволяет добавлять некоторый php или js скрипт, который может участвовать в составлении макета.
Верхняя часть страницы (Header). Собственно, название говорит само за себя. В данное поле помещается всё то, что должно отображаться в хедере вашего сайта.
Нижняя часть страницы (Footer). В данное поле помещается всё то, что будет отображаться в подвале вашего сайта.
Настройки отображения макета дизайна в разделе. Данные настройки содержат массивы задаваемых разработчиком переменных/полей, которые задаются один раз, и далее в них просто прописываются необходимые значения. Пример того, как выглядят подобные настройки мы рассматривали при настройке компонента «Обратная связь» в визуальных настройках.
Дополнительные поля. По-умолчанию добавлено только одно поле «Таблица стилей», но вы можете добавить свои поля по необходимости, перейдя в раздел «Разработка: Системные таблицы: Макеты дизайна». Свои поля вы сможете использовать в макете дизайна. Использование существующего поля (CSS) в качестве хранения стилей возможно, но не желательно. Дело в том, что значения, которые будут сюда записаны, попадут прямиком в исходный код шаблона, что увеличит размер страницы. Всё же рекомендуется выносить все CSS стили в отдельный файл.

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

Рис.6 — Шаблон с разделёнными осставляющими

Для удобства, нами были выделены цветом 4 зоны для внедрения в макет. Давайте рассмотрим их начиная с верхнего:

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

Теперь переходим к файлам нашего шаблона и начинаем подготовку к его внедрению. В папке с шаблоном будут находиться все необходимые нам файлы.

Папка с изображениями скачанного нами шаблона находится внутри папки стилей. Исправляю эту неточность и переношу её в корень шаблона. Теперь наша папка с файлами выглядит как и нужно:

Нам будет необходимо отредактировать два файла: index.html и style.css. Открывайте их в текстовом редакторе.

Все пути в файлах советуем сделать относительными.

Рис.9 — Замена путей к файлам

Точно так же меняем пути к картинкам, js скриптам и т.д. После того, как вы поменяете все пути на абсолютные, работа с шаблоном до внедрения на сайт продолжится только в текстовом режиме.

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

Рис.10 — Редактирование файла со стилями

Теперь нам необходимо в файл index.html внедрить специальные переменные, функции и команды. Воспользуемся стандартным шаблоном и скопируем оттуда всё, что нам необходимо.

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

 ' /> ' /> NC_CHARSET?>' />

Дальше наш шаблон разделяем на составляющие: хедер, футер и контентная часть. Верхняя часть заканчивается в том месте, где начинается вывод контентной части:

Рис.11 — Добавление комментариев

В это место мы вставляем функцию NetCat и заключаем контентную часть в комментарии:

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

Так же вы можете скопировать папки «css», «images» и «js» в корневой каталог вашего сайта. Для того, чтобы установить добавленный вами макет дизайна, нужно в настройках сайта назначить его основным:

Рис.12 — Установка макета дизайна

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

Рис.13 — Тестирование макета дизайна

Узнать номер макета дизайна вы можете в администраивном разделе:

Рис.16 — Номер макета дизайна

Теперь остаётся добавить материалы на титульную страницу и далее приступать к настройке меню, к созданию разделов и т. д. Для титульной страницы мы создадим отдельный макет дизайна и скопируем в него оставшуюся часть нашего html-шаблона. Учтите, что все остальные макеты, которые вы будете создавать для одного сайта, желательно делать дочерними родительскому макету:

Рис.17 — Добавление дочернего макета

Называем новый макет «Титульная страница». Так как мы создали макет для титульной страницы дочерним от основного, то он может наследовать значения полей футера, хедера и шаблонов вывода навигации. Для того, чтобы данные из основного макета отображались также на титульной странице, существуют макропеременные %Header и %Footer, которые заменяют копирование кода. То есть вставка макропеременной %Header в соответствующее поле будет равна всему тому коду, который вы добавили в родительском макете дизайна.

Таким образом, в верхнюю часть страницы нам нужно вставить макропеременную %Header и всё то, что осталось в нашем html-шаблоне. В нижнюю часть страницы мы вставляем ТОЛЬКО макропеременную %Footer.