Комментарии 70
Забыли упомянуть: прикрепить сайт к Яндекс.Вебмастер и Google Webmaster Tools
Если сайт компании:
Зарегистрировать в Яндекс.Адресах и Гугл.Адресах, добавить на Wikimapia.org
В принципе это подпадает под «Проверить форматирование сайта в результатах выдачи поисковиков», но, думаю что тут стоит расшифровать поподробнее
Если сайт компании:
Зарегистрировать в Яндекс.Адресах и Гугл.Адресах, добавить на Wikimapia.org
В принципе это подпадает под «Проверить форматирование сайта в результатах выдачи поисковиков», но, думаю что тут стоит расшифровать поподробнее
+15
Первым пунктом я бы написал «Подумать, нужен ли этот сайт кому то, кроме меня», после этого остальной чеклист может оказаться ненужным, за одно избавимся от кучи ежедневно захламляющих интернет "СуперМегаВебДваНульСоциальныхСетейДляСамыхКрутых" :)
+32
Думаю стоит заменить предложений пункт тем что — «Будет ли он кому то полезен вообще, хо тебе тебе»…
Иногда ресурс который делаешь только для себя, сначала становится интересным для твоих друзей, а потом и для масс интернета приходится открывать )))
Иногда ресурс который делаешь только для себя, сначала становится интересным для твоих друзей, а потом и для масс интернета приходится открывать )))
+3
Я не отрицаю, тут вкусы людей решают, а они у всех разные. А вообще я считаю не стоит каждый раз надеяться на случай — «а вдруг понравиться!», и не полениться подумать, а «нужно ли». Ведь экономите не только пространство на хостинге, но и в первую очередь свое время, которое вы смогли бы потратить на более полезные/нужные вещи.
+1
Насколько я понял это регламент перед непосредственным запуском — думать нужен ли этот ресурс или нет надо было на этапах планирования, утверждения, финансирования.
+5
Может быть, но некоторые пункты все же, наводят на мысль, что тут смешаны эти этапы.
Да и «чеклист запуска сайта», я лично для себя, могу растолковать в нескольких контекстах.
Ну и если даже так, может этапы «планирования, утверждения и финансирования» прошли на бодром дыхании энтузиазма и радости от идеи, а в таком состоянии люди иногда не видят/не хотят видеть свои ошибки, а посмотреть назад никогда не было зазорным, вдруг все таки всё это было ошибкой? :)
Да и «чеклист запуска сайта», я лично для себя, могу растолковать в нескольких контекстах.
Ну и если даже так, может этапы «планирования, утверждения и финансирования» прошли на бодром дыхании энтузиазма и радости от идеи, а в таком состоянии люди иногда не видят/не хотят видеть свои ошибки, а посмотреть назад никогда не было зазорным, вдруг все таки всё это было ошибкой? :)
0
Кратко этот пункт называется «Определить целевую аудиторию». Делается это, кстати, ещё на этапе проектирования сайта, определения его видения, но никак не создания.
0
Судя по тому, что сейчас происходит в рунете, я сомневаюсь что кто то знает про этот пункт, и этапы планирования видимо у них тоже галопом пробегают :)
Я чуть выше и написал, что у нас почему то, почти у всех, принято делать «на эмоциях», а не по-плану.
Я чуть выше и написал, что у нас почему то, почти у всех, принято делать «на эмоциях», а не по-плану.
0
Я вообще не понимаю когда мне приводят в доводы запрос в поисковике на «данную фразу», если там есть ответ, это совсем не значит что «вся та масса людей о которой я говорил выше», читает это, и блюдет :)
Я могу привести в пример запрос на тексты из латыни, это же не значит что вся страна у нас знает латынь и интересуется ею :)
В общем мы уже от темы отходим, так что если желаете продолжить полемику на данную тематику, то пишите в личку ;)
Я могу привести в пример запрос на тексты из латыни, это же не значит что вся страна у нас знает латынь и интересуется ею :)
В общем мы уже от темы отходим, так что если желаете продолжить полемику на данную тематику, то пишите в личку ;)
0
А что места в Интернете уже не хватает?
0
ну этот пункт больше подходит для момента проектирования сайта, а не запуска. Я так понял, что автор описывает как-раз тот момент, когда крутость проекта и его нужность уже была определена ранее. Этот список может служить как частичный ориентир в плане проведения завершающих работ по сайту, а то о чем говорите Вы, это делается на этапе проектирования еще или даже на этапе осмысления идеи :)
0
этот вопрос нужно задавать перед началом разработки ТЗ на сайт (или самого сайта, если разработчик надеется обойтись без ТЗ).
кучу времени сэкономит :)
кучу времени сэкономит :)
0
Интересная идея, можно еще добавить поля с датой начала и датой когда поставил галочку )
+1
НЛО прилетело и опубликовало эту надпись здесь
Это скорее ради интереса, проверить будет ли оно хоть как-то смотреться. Кроме того, иногда на таком тесте видно, что в резине не выставлена минимальная ширина, что делает из сайта уродство на низких разрешениях. А так хоть скрол.
+2
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А пользователей нетбуков вы как таргет аудиторию не рассматриваете?
0
Небольшая опечатка, эту статью по этому списки не прогонял )
● Заголовки страниц очень важны; убедиться, что они осмысленны и содержат важныЕ ключевые слова
● ПрОверить и реализовать кеширование где это необходимо
ну и возможно еще есть
● Заголовки страниц очень важны; убедиться, что они осмысленны и содержат важныЕ ключевые слова
● ПрОверить и реализовать кеширование где это необходимо
ну и возможно еще есть
0
Такое ощущение, что я это уже читал где-то с месяц назад…
+2
Спасибо за рерайт, но — ё-маё, ну не на хабре же!
+5
НЛО прилетело и опубликовало эту надпись здесь
Пардон, того топика я не видел в апреле. Что ж, если вылезет на главную, значит не я один его не читал. Кроме того, здесь есть PDF-ка.
+2
А ссылка на источник и автора?
0
Присутствует в конце статьи. Это не rewrite вышеназванного топика, а самостоятельная версия.
0
Мне больше кажется, что это самостоятельная версия на основе оригинала. На вашем сайте даже стиль таблицы такой же, как на сайте оригинала: www.boxuk.com/blog/the-ultimate-website-launch-checklist VS drupaldance.com/blog/website-launch-checklist
+1
НЛО прилетело и опубликовало эту надпись здесь
ff → ff, ffi → ffi, ffl → ffl и т.д. (http://en.wikipedia.org/wiki/Typographic_ligature)
Я так и знал, что будет упрек на счет точек в конце, но они не поставлены специально, ибо от них рябит в данном конкретном списке.
Я так и знал, что будет упрек на счет точек в конце, но они не поставлены специально, ибо от них рябит в данном конкретном списке.
-1
Безопасно использовать только fi и fl, они вроде бы есть во всех системных шрифтах (по крайней мере в Windows). ff, ffi и прочие ffl могут отображаться совсем не тем шрифтом, которым планировалось, или вообще квадратиками.
0
Черт, меня таращит от этой картинки — ручка, пишущая в воздухе.
+2
Вы это все делаете прямо перед запуском?
+1
Это как Дед Мороз — добрая сказка для детей младшего школьного возраста =) Все понимают, что выдумка, но послушать новогодние истории любят ;))
+2
Суть даже не в том что все это хорошо бы сделать перед выгрузкой, просто многое из перечисленного стоит делать в процессе разработки, а некоторое и на ее ранних этапах.
Расставлять индексы в базе потому что так положено по чеклисту, ну извините. Если сайт не держит планируемую нагрузку то и так задумаешься о их расставлении, а если держит то смысл?
Тестировать на совместимость в браузерах и под разными разрешениями перед самой выгрузкой? А может это стоит сделать сразу после разработки верстки?
И такого много.
Расставлять индексы в базе потому что так положено по чеклисту, ну извините. Если сайт не держит планируемую нагрузку то и так задумаешься о их расставлении, а если держит то смысл?
Тестировать на совместимость в браузерах и под разными разрешениями перед самой выгрузкой? А может это стоит сделать сразу после разработки верстки?
И такого много.
0
Конечно =) Я, например, во время верстки по частям просматриваю сайт во всех браузерах и сразу все выверяю — как стоит шапка, как сайдбары держатся… а то в конце потом полная каша в ИЕ6 вылезает! Но, согласитесь, заголовок «То, что нужно делать во время проектирования и разработки сайта» не столь громкий, как «Чеклист запуска сайта». Не хватает только тега «сенсация!» =)
+1
Интересно было сравнить с webmascon.com/topics/tools/09a.asp (статья от 31.10..2004)
0
Отличная ссылка! Спасибо! Что особенно нужное в статье на Webmascon-е, так это ссылки на онлайн сервисы для проверки чеклиста. Приведу сразу и оригинал той статьи на Webmascon-е: www.maxdesign.com.au/presentation/checklist.htm (англ.)
0
Хорошо подборка, но мало кто этим будет пользоваться. Наверное даже никто.
0
В большинстве случаев связность, корректность и орфография Lorem ipsum… не подлежит сомнению =)
+2
добавил страницу в закладки!
Я раньше так глобально разными проверками сайта не занимался, скоро запуск — скоро и опробую)
По времени это затянется — но в будущем должно быть намного меньше проблем!
Я раньше так глобально разными проверками сайта не занимался, скоро запуск — скоро и опробую)
По времени это затянется — но в будущем должно быть намного меньше проблем!
0
Интересно было бы прикинуть бюджет на все перечисленные операции и сопоставить его с бюджетом на непосредственную реализацию фич. Склоняюсь к паритету :)
0
Несколько вопросов:
1. Что такое «Добавить сайт в социальные медиа: Twitter, ВКонтакте, LinkedIn, Facebook, и т.д.»? Куда их там добавлять?
2. Почему бы не проверить сайт при выключенных картинках?
3. Чем проверять валидность Javascript?
1. Что такое «Добавить сайт в социальные медиа: Twitter, ВКонтакте, LinkedIn, Facebook, и т.д.»? Куда их там добавлять?
2. Почему бы не проверить сайт при выключенных картинках?
3. Чем проверять валидность Javascript?
+1
Что касается лигатур.
Как они влияют на индексацию контента поисковыми системами?
Как она поведёт себя, когда встретит лигатуру fi вместо двух букв fi? Тем более, текст в заголовке — крайне важен для индексации.
Как они влияют на индексацию контента поисковыми системами?
Как она поведёт себя, когда встретит лигатуру fi вместо двух букв fi? Тем более, текст в заголовке — крайне важен для индексации.
+1
Где настройки веб-сервера? Где watchdog? Где автоматическое тестирование? Упущено очень многое…
С очень многими пунктами не согласен:
> ● Вычитать тексты и проверить правописание
> ● Связность текстов
Это нужно делать при приемке контента, но никак не перед запуском.
> ● Проверить нет ли на сайте вшитых ссылок на dev-сервер (т.е. после запуска ссылки должны вести на сайт «в миру»)
А это вообще вопиющая халатность: все ссылки должны генерироваться автоматически, в крайнем случае быть относительными. В любом случае, контент со ссылками — худшее и непереносимое решение. Удачи при создании вап-версии.
> ● Проверить не осталось ли на сайте тестового контента
> ● Отключить вывод ошибок на экран
При грамотном подходе к разработке, с разделением на дев/продакшен, это просто не имеет смысла.
> ● Привести формат ссылок к читабельному виду (напр. site.ru/blog/how-to-make-coffee, site.ru/user/vasya и т.д.)
Задача для ранней стадии, скорее для разработчика движка (или настройщика готового)
> ● Проверить весь заказанный/особый/сложный функционал
> ● Проверить работу поиска (включая релевантность)
> ● Протестировать все формы (контактов, комментариев, фидбека, ...), поставить на них капчу или другую защиту
>…
Все это должно тестироваться не руками, а юнит-тестами в автоматическом режиме. Формы отдельно тестировать не нужно, проверять нужен сам движек сайта на корректность обработки форм. Капча должна расставляться в полуавтоматическом режиме, причем далеко не везде (например, в формах для связи ее делать не следует: лучше пропустить 20 спам-сообщений, чем упустить 1 баг-репорт)
> ● Проверить нет ли у посетителей доступа к служебным/секретным/закрытым страницам
> ● Закрыть поисковикам доступ к служебным/секретным/закрытым разделам сайта, используя robots.txt
Если такое допускается, то автора надо без зазрения совести увольнять с заключением о проф.непригодности.
> ● Проверить и реализовать кэширование где это необходимо
Какое кеширование? Средствами вебсервера? Средствами движка? Нужно ли кеширование байт-кода? Тема кеширования не раскрыта, а это порой очень большая часть при разработке.
> ● Создать свои страницы 404/403
А где 500/503? Где был автор в момент отладки?
Да и 403 — это как плевок в пользователя, «страница есть, но не для тебя, пшел вон отсюда»
С очень многими пунктами не согласен:
> ● Вычитать тексты и проверить правописание
> ● Связность текстов
Это нужно делать при приемке контента, но никак не перед запуском.
> ● Проверить нет ли на сайте вшитых ссылок на dev-сервер (т.е. после запуска ссылки должны вести на сайт «в миру»)
А это вообще вопиющая халатность: все ссылки должны генерироваться автоматически, в крайнем случае быть относительными. В любом случае, контент со ссылками — худшее и непереносимое решение. Удачи при создании вап-версии.
> ● Проверить не осталось ли на сайте тестового контента
> ● Отключить вывод ошибок на экран
При грамотном подходе к разработке, с разделением на дев/продакшен, это просто не имеет смысла.
> ● Привести формат ссылок к читабельному виду (напр. site.ru/blog/how-to-make-coffee, site.ru/user/vasya и т.д.)
Задача для ранней стадии, скорее для разработчика движка (или настройщика готового)
> ● Проверить весь заказанный/особый/сложный функционал
> ● Проверить работу поиска (включая релевантность)
> ● Протестировать все формы (контактов, комментариев, фидбека, ...), поставить на них капчу или другую защиту
>…
Все это должно тестироваться не руками, а юнит-тестами в автоматическом режиме. Формы отдельно тестировать не нужно, проверять нужен сам движек сайта на корректность обработки форм. Капча должна расставляться в полуавтоматическом режиме, причем далеко не везде (например, в формах для связи ее делать не следует: лучше пропустить 20 спам-сообщений, чем упустить 1 баг-репорт)
> ● Проверить нет ли у посетителей доступа к служебным/секретным/закрытым страницам
> ● Закрыть поисковикам доступ к служебным/секретным/закрытым разделам сайта, используя robots.txt
Если такое допускается, то автора надо без зазрения совести увольнять с заключением о проф.непригодности.
> ● Проверить и реализовать кэширование где это необходимо
Какое кеширование? Средствами вебсервера? Средствами движка? Нужно ли кеширование байт-кода? Тема кеширования не раскрыта, а это порой очень большая часть при разработке.
> ● Создать свои страницы 404/403
А где 500/503? Где был автор в момент отладки?
Да и 403 — это как плевок в пользователя, «страница есть, но не для тебя, пшел вон отсюда»
+1
Действительно, 403 не нужна. А группы пользователей и всякие админки — пережиток тоталитаризма и расовой сегрегации.
0
> А группы пользователей и всякие админки — пережиток тоталитаризма и расовой сегрегации.
На хорошем сайте не должно быть ссылок, которые ведут на «закрытые» разделы сайта (разные админки), а если пользователь начал перебирать урлы и пытается зайти куда-то вроде example.com/admin/, то ему лучше показать 404, форму авторизации (когда к админке имеет доступ большое количество пользователей), на худой конец просто кинуть редирект на главную. Но не 403.
В случае групп, у которых разные права доступа, лучше показать форму авторизации, где предложить ввести логин/пароль пользователя, имеющего доступ а этот раздел. Причем указать, почему появилась такая форма, дабы пользователь не вводил свое имя еще раз, тем самым запутываясь. Но не 403.
403 — это оплеуха в чистом виде. Уж лучше 500.
На хорошем сайте не должно быть ссылок, которые ведут на «закрытые» разделы сайта (разные админки), а если пользователь начал перебирать урлы и пытается зайти куда-то вроде example.com/admin/, то ему лучше показать 404, форму авторизации (когда к админке имеет доступ большое количество пользователей), на худой конец просто кинуть редирект на главную. Но не 403.
В случае групп, у которых разные права доступа, лучше показать форму авторизации, где предложить ввести логин/пароль пользователя, имеющего доступ а этот раздел. Причем указать, почему появилась такая форма, дабы пользователь не вводил свое имя еще раз, тем самым запутываясь. Но не 403.
403 — это оплеуха в чистом виде. Уж лучше 500.
0
>все ссылки должны генерироваться автоматически
как все попривыкали к CMS. а бывают ещё и самописные сайты…
> ● Проверить не осталось ли на сайте тестового контента
> ● Отключить вывод ошибок на экран
>При грамотном подходе к разработке, с разделением на дев/продакшен, это просто не имеет смысла.
это далеко не у всех профильных фирм получается, а если админы-дизеры сами всё делают, то очеь даже важный пункт
и главное забыло — обвешать сайт всплывающими порно-банерами и партнерскими ссылками, чтобы webmoney капали :)))) (разумеется уместно не на всех проектах.
как все попривыкали к CMS. а бывают ещё и самописные сайты…
> ● Проверить не осталось ли на сайте тестового контента
> ● Отключить вывод ошибок на экран
>При грамотном подходе к разработке, с разделением на дев/продакшен, это просто не имеет смысла.
это далеко не у всех профильных фирм получается, а если админы-дизеры сами всё делают, то очеь даже важный пункт
и главное забыло — обвешать сайт всплывающими порно-банерами и партнерскими ссылками, чтобы webmoney капали :)))) (разумеется уместно не на всех проектах.
0
> как все попривыкали к CMS. а бывают ещё и самописные сайты…
Это которые в ворде или notepad.exe делают? Без слез на них смотреть нельзя, а если и можно, то строятся такие сайты слишком долго. В остальных случаях используют CMS в той или иной степени, даже если в итоге на хост заливается статический HTML.
> это далеко не у всех профильных фирм получается, а если админы-дизеры сами всё делают, то очеь даже важный пункт
А что в этом сложного? Грамотный подход к разработке — это даже скорее облегчение труда, а если профильная фирма не может обеспечить инструменты для работы, то я бы очень сильно задумался о профильности этой конторы.
про вебмани не понял юмору.
Это которые в ворде или notepad.exe делают? Без слез на них смотреть нельзя, а если и можно, то строятся такие сайты слишком долго. В остальных случаях используют CMS в той или иной степени, даже если в итоге на хост заливается статический HTML.
> это далеко не у всех профильных фирм получается, а если админы-дизеры сами всё делают, то очеь даже важный пункт
А что в этом сложного? Грамотный подход к разработке — это даже скорее облегчение труда, а если профильная фирма не может обеспечить инструменты для работы, то я бы очень сильно задумался о профильности этой конторы.
про вебмани не понял юмору.
-1
сами мы не местные, но интересуемся.
XML Sitemap — это что?
XML Sitemap — это что?
0
Это список всех URLов сайта в специальном xml-формате.
Создаётся для того, чтобы скормить поисковой системе — указать его в robots.txt или в вебмастерах. Так поисковики знают, какие страницы на сайте у вас есть, и сразу качают их все, а не проходят несколькими волнами по ссылкам. Более того, там, в сайтмепе, указывается параметр last-modified: время последнего изменения страницы. Теоретически поисковики учитывают этот параметр. Например, если ластмодифаеды в сайтмепе обновились, то у поисковика есть ещё один повод скачать ваши страницы заново.
Так-то.
Создаётся для того, чтобы скормить поисковой системе — указать его в robots.txt или в вебмастерах. Так поисковики знают, какие страницы на сайте у вас есть, и сразу качают их все, а не проходят несколькими волнами по ссылкам. Более того, там, в сайтмепе, указывается параметр last-modified: время последнего изменения страницы. Теоретически поисковики учитывают этот параметр. Например, если ластмодифаеды в сайтмепе обновились, то у поисковика есть ещё один повод скачать ваши страницы заново.
Так-то.
+2
Ваш топик как раз к месту. Запускаем новый дизайн сайта.
-2
Полезная напоминалка. Можно обернуть все это в небольшой стартап в виде «онлаин чеклиста по моим проектам».
-1
Много полезного, спасибо…
-1
Когда читал, обратил внимание на то, что существуют пункты разного рода. Что-то важное, что делается на этапе дизайна или на этапе проектирования, соседствует с тем, что вообще далеко не обязательно.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чеклист запуска сайта