Какви неща трябва да вземе предвид програмистът, който изпълнява техническите детайли на уеб приложение, преди да направи сайта публичен? Ако Джеф Атууд може да забрави за HttpOnly cookies, sitemaps, и cross-site request forgeries всичко това в един и същи сайт, какво важно нещо мога да забравя и аз?
Мисля за това от гледна точка на уеб разработчика, така че някой друг създава действителния дизайн и съдържание на сайта. Така че, макар че ползваемостта и съдържанието може да са по-важни от платформата, вие, програмистът, нямате голяма дума за това. Това, за което трябва да се притеснявате, е дали вашата реализация на платформата е стабилна, дали работи добре, дали е сигурна и дали отговаря на всички други бизнес цели (като например да не струва твърде скъпо, да не отнема твърде много време за изграждане и да се класира толкова добре в Google, колкото поддържа съдържанието).
Помислете за това от гледната точка на разработчик, който'е свършил някаква работа за приложения от интранет тип в доста надеждна среда и е на път да направи първия си опит и да пусне потенциално популярен сайт за цялата голяма лоша световна мрежа.
Също така, търся нещо по-конкретно, а не просто неясен "уеб стандарти" отговор. Искам да кажа, че HTML, JavaScript и CSS по HTTP са почти даденост, особено когато вече съм уточнил, че сте професионален уеб разработчик. И така, ако продължим отвъд това, Кои стандарти? При какви обстоятелства и защо? Посочете линк към спецификацията на стандарта.
Идеята тук е, че повечето от нас вече знаят повечето от това, което е включено в този списък. Но може да има само един или два елемента, които не сте разглеждали преди, не разбирате напълно или може би дори не сте чували за тях. Интерфейс и потребителски опит
rel="nofollow"
към генерираните от потребителите връзки за да избегнете спам.rel="noopener noreferrer"
на всички връзки, предоставени от потребителя, с target="_blank"
, за да предотвратите пренасочването на JavaScript на целевата страница към друго място, например към фалшива страница за вход. Повече информацияfavicon.ico
, т.е. /favicon.ico
. Браузърите ще го поискат автоматично, дори ако иконата изобщо не е спомената в HTML. Ако нямате файл /favicon.ico
, това ще доведе до много 404 съобщения, които ще източат честотната лента на сървъра ви.
SEO (оптимизация за търсачки)example.com/pages/45-article-title
вместо example.com/index.php?page=45
.#
за динамично съдържание, променете #
на #!
и след това на сървъра $_REQUEST["_escaped_fragment_"]
е това, което googlebot използва вместо #!
. С други думи, ./#!page=1
става ./?_escaped_fragments_=page=1
. Също така, за потребителите, които може да използват FF.b4 или Chromium, history.pushState({"foo": "bar"}, "About", "./?page=1");
е чудесна команда. Така, въпреки че адресната лента се е променила, страницата не се презарежда. Това ви позволява да използвате ?
вместо #!
, за да запазите динамичното съдържание, а също така да кажете на сървъра, когато изпращате връзката по имейл, че сме след тази страница, и AJAX не трябва да прави още една допълнителна заявка./sitemap.xml
.<link rel="canonical" ... />
, когато имате множество URL адреси, които сочат към едно и също съдържание, като този въпрос може да бъде разгледан и от Google Webmaster Tools.301 Moved Permanently
) с искане за www.example.com
към example.com
(или обратното), за да предотвратите разделянето на класирането в Google между двата сайта.