Welke dingen moet een programmeur die de technische details van een webapplicatie implementeert overwegen voordat hij de site openbaar maakt? Als Jeff Atwood HttpOnly cookies, sitemaps, en cross-site request forgeries allemaal op dezelfde site kan vergeten, welk belangrijk ding zou ik dan ook kunnen vergeten?
Ik denk hierover vanuit het perspectief van een webontwikkelaar, dus iemand anders maakt het eigenlijke ontwerp en de inhoud van de site. Dus hoewel bruikbaarheid en inhoud misschien belangrijker zijn dan het platform, heb jij als programmeur daar weinig over te zeggen. Waar u zich wel zorgen over moet maken is dat uw implementatie van het platform stabiel is, goed presteert, veilig is, en voldoet aan eventuele andere zakelijke doelstellingen (zoals niet te veel kosten, te lang duren om te bouwen, en net zo goed scoren bij Google als de inhoud ondersteunt).
Zie dit vanuit het perspectief van een ontwikkelaar die wat werk heeft gedaan voor intranet-achtige toepassingen in een redelijk vertrouwde omgeving, en op het punt staat zijn eerste schot te wagen en een potentieel populaire site uit te brengen voor het hele grote boze world wide web.
Ook, ik'm op zoek naar iets meer specifieke dan alleen een vage " webstandaarden " antwoord. Ik bedoel, HTML, JavaScript, en CSS over HTTP zijn vrij veel een gegeven, vooral als ik'heb al gespecificeerd dat u'bent een professionele webontwikkelaar. Dus verdergaand dan dat, Welke standaarden? In welke omstandigheden, en waarom? Geef een link naar de specificatie van de standaard'
Het idee hier is dat de meesten van ons altijd _het meeste van wat op deze lijst staat zouden moeten weten. Maar er zijn misschien een of twee punten die u nog niet echt hebt onderzocht, niet helemaal begrijpt of misschien zelfs nog nooit van hebt gehoord. Interface en gebruikerservaring
rel="nofollow"
toe aan door gebruikers gegenereerde links om spam te voorkomen.rel="noopener noreferrer"
op alle door de gebruiker gegeven links met target="_blank"
om te voorkomen dat JavaScript op de bestemmingspagina je pagina omleidt naar ergens anders, zoals een valse loginpagina. Meer infofavicon.ico
bestand in de root van de site staat, d.w.z. /favicon.ico
. Browsers zullen het automatisch opvragen, zelfs als het icoon helemaal niet in de HTML wordt genoemd. Als u geen /favicon.ico
heeft, zal dit resulteren in een groot aantal 404's, die de bandbreedte van uw server opgebruiken.
SEO (Zoekmachine Optimalisatie)voorbeeld.com/pages/45-article-title
in plaats van voorbeeld.com/index.php?page=45
#
gebruikt voor dynamische inhoud, verander dan de #
in #!
en dan op de server $_REQUEST["_escaped_fragment_"]
is wat googlebot gebruikt in plaats van #!
. Met andere woorden, ./#!page=1
wordt ./?_escaped_fragments_=page=1
. Ook, voor gebruikers die FF.b4 of Chromium gebruiken, history.pushState({"foo":"bar"}, "About", "./?page=1");
Is een geweldig commando. Dus ook al is de adresbalk veranderd, de pagina wordt niet opnieuw geladen. Hierdoor kun je ?
gebruiken in plaats van #!
om dynamische inhoud te behouden en ook de server te vertellen wanneer je de link mailt dat we na deze pagina zijn, en de AJAX niet nog een extra verzoek hoeft te doen./sitemap.xml
.<link rel="canonical" ... />
wanneer je meerdere URL's hebt die naar dezelfde content verwijzen, dit probleem kan ook vanuit Google Webmaster Tools worden aangepakt.301 Moved Permanently
) die vragen om www.example.com
naar voorbeeld.com
(of andersom) om te voorkomen dat de google ranking tussen beide sites wordt opgesplitst.