Veel providers bieden webruimte aan hun inbelklanten aan. Dit is gewoonlijk minder dan 5MB, en er kunnen verdere beperkingen zijn; het is bijvoorbeeld vaak niet toegestaan om commercieel gebruik te maken van deze ruimte.
Er zijn meerdere bedrijven en individuen die gratis webruimte aanbieden. Dit varieert gewoonlijk van 100KB tot en met 1MB, en er zijn ook vaak weer beperkingen aan het gebruik. Het gebeurt ook dat ze een link naar hun homepage vereisen. Zie voor verwijzingen naar aanbieders van gratis webruimte <URL:http://www.freewebspace.net/>.
Er zijn ook veel aanbieders van webruimte (ook bekend als 'presence providers') die ruimte op hun servers verkopen. Prijzen lopen uiteen van niet meer dan $1 per maand, tot $100 per maand of meer, afhankelijk van je behoeften. Niet-virtuele webruimte is meestal het goedkoopste, hierbij krijg je een URL zoals: http://www.een-aanbieder.com/jouwnaam/. Voor iets meer, en de kosten voor het registreren van een domeinnaam, kun je virtuele webruimte krijgen, waardoor je kunt beschikken over een URL zoals http://www.jouwnaam.com/.
Als je de een of andere permanente verbinding met Internet hebt, bijvoorbeeld via een gehuurde lijn van je provider, dan kun je een httpd installeren en een eigen webserver beheren. Er zijn diverse webservers beschikbaar voor praktisch alle computersystemen.
Als je enkel informatie wilt uitwisselen met andere lokale gebruikers, of mensen op een LAN of WAN, dan kun je je HTML-bestanden gewoon op het LAN plaatsen waar iedereen erbij kan, of anders, als jouw LAN TCP/IP ondersteunt, een webserver installeren op je eigen computer.
De Internet Corporation for Assigned Names and Numbers (ICANN) houdt een overzicht bij van aangezen registreerders op <URL:http://www.icann.org/registrars/accredited-list.html>. Elk van de bedrijven op deze lijst kan een domeinnaam voor je registreren.
Lees de Voorwaarden voor gebruik (Terms of Service, TOS) die je bent overeengekomen met jouw hosting-dienstverlener. Hierin wordt het hoogstwaarschijnlijk verboden om in te grijpen in de advertenties die zij toevoegen aan je webpagina's. Als je zelf de een of andere truc gebruikt om hun advertenties tegen te houden, kan de hosting dienst jouw account opzeggen wegens het overtreden van de TOS.
Er kunnen echter wel andere mogelijkehden zijn. Sommige hosting-diensten halen de advertenties weg als je een laag maandelijks bedrag betaalt. Anderen verwijderen hun standaard pop-up advertenties als je zelf vaste banners plaatst.
Er is niet één vaste techniek, maar een aantal factoren kunnen helpen.
<TITLE>, gebruik zinvolle koppen (<H1>, <H2>, enzovoort), en zorg voor zinvolle ALT-teksten voor afbeeldingen.<META NAME="keywords" CONTENT="..."> tags die voorkomen in het <HEAD> deel van je documenten. Maar META keywords zijn ook gebruikt om zoekmachines om de tuin te leiden, dus velen zullen je keyword-lijst negeren als je een bepaald keyword te vaak herhaald. Op het moment dat dit wordt geschreven, betekent "te vaak" "meer dan 7 keer" voor enkele populaire zoekmachines, maar dat kan in de toekomst veranderen als indexeer programmas worden veranderd ter verdeding tegen "valsspelers."<META NAME="description" CONTENT="..."> tag opneemt in het <HEAD> deel van je documenten, zullen sommige zoekmachines de inhoud van deze tag gebruiken als beschijving van je site bij het weergeven van zoekresultaten. Dit heeft geen invloed op je ranking in zoekopdrachten, maar het kan gebruikers van zoekmachines helpen bij het begrijpen wat je site hen biedt, wanneer een zoekopdracht jouw site vindt.Merk op dat het CONTENT attribuut van de META keywords en description tags tot maximaal 1022 tekens mogen bevatten, maar behalve entities geen markup.
Je kunt je site bekijken met een text-only browser zoals Lynx, om er een idee van te krijgen hoe je site er uitziet voor zoekmachines. Search Engine Watch op <URL:http://searchenginewatch.com/> is een website gericht op zoekmachines en strategieën voor webpagina ontwerpers.
Merk ook nog op, dat sommige zoekmachines sites negeren die worden geplaatst bij bekende gratis hosting-diensten. Andere zoekmachines indexeren maar een beperkt aantal documenten per server, zodat vroege klanten van gratis hosting-diensten mogelijk worden geïndexeerd, terwijl latere klanten mogelijk worden genegeerd.
Zie <URL:http://info.webcrawler.com/mak/projects/robots/exclusion.html>.
De meest betrouwbare manier is het configureren van de server om een verwijzingsinstructie (redirect) te versturen als de oude URL wordt aangevraagd. Dan zal de browser automatisch de nieuwe URL krijgen. Dit is de snelste en meest efficiënte manier, en het is de enige van de hier beschreven manieren die indexeer-robots kan overtuigen de oude URL te vergeten. Raadpleeg voor details met betrekking tot de configuratie je serverbeheerder of de documentatie (gebruik met NCSA of Apache servers een Redirect statement in .htaccess).
Als je geen redirect kunt opzetten zijn er andere mogelijkheden. Deze zijn minderwaardig omdat ze de zoekmachines vertellen dat er nog steeds een pagina bestaat op de oude locatie, niet dat de pagina verhuisd is naar een nieuwe locatie. Maar als het niet mogelijk is om een redirect te configureren op de server, zijn er twee alternatieven:
META HTTP-EQUIV="Refresh" CONTENT="x; URL=nieuw.URL">Wachtwoordbeveiliging gebeurt door middel van HTTP-authenticatie. Aangezien de configuratie-details verschillen van server tot server moet je hiervoor het onderdeel authenticatie lezen van de serverdocumentatie. Neem contact op met de serverbeheerder als je hierbij hulp nodig hebt.
Als je server bijvoorbeeld Apache is, kijk dan op <URL:http://www.apache.org/docs/misc/FAQ.html#user-authentication>.
Wachtwoord-scripts in JavaScript geven alleen de suggestie van veiligheid. In beginsel werken ze op een van twee manieren. Sommige scripts zetten het wachtwoord om in een URL, waardoor het document geheim blijft doordat het aantal mensen dat de URL kent beperkt is. Sommige scripts controleren een wachtwoord en gaan dan naar een specifieke URL, wat het docuemnt alleen maar beschermt tegen degenen, die die niet in de broncode van het JavaScript kijken om de URL van het document te verkrijgen. Geen van deze twee methoden is echt veilig.
Browsers 'cachen' webdocumenten; ze slaan een lokale kopie op van documenten om herhaalde verzoeken naar documenten die niet zijn veranderd te versnellen. Ook zijn veel browsers ingesteld om een publieke proxy cache te gebruiken, die vele gebruikers dient (bijv. alle klanten van een ISP, of alle werknemers achter een bedrijfs-firewall). Om effectief te beheersen hoe je documenten worden gecached, moet je je server instellen om de juiste HTTP headers te verzenden.
De Expires-header wordt door praktisch alle caches begrepen. Het gecachete document zal opnieuw worden opgehaald zodra het is verlopen. De Expires-header moet een HTTP-datum bevatten, die werkt met Greenwich Mean Time (GMT), niet met de lokale tijd.
HTTP 1.1 introduceert de Cache-Control-header, die meer flexibiliteit biedt voor het aan caches duidelijk maken, hoe ze met het document moeten omgaan. Zie de HTTP 1.1 draft (zie <http://www.w3.org/Protocols/>) voor meer informatie.
De configuratie-details verschillen van server tot server, dus zoek dit op in je serverdocumentatie. Als je server bijvoorbeeld Apache is, zie dan <URL:http://www.apache.org/docs/mod/mod_expires.html> voor informatie over het instellen van de Expires header, en <URL:http://www.apache.org/docs/mod/mod_headers.html> voor informatie over het instellen van andere headers.
De Pragma-header is over het algemeen ineffectief omdat de betekenis niet gestandaardiseerd is en slechts weinig caches het honoreren. Het gebruik van <META HTTP-EQUIV=...> elementen in HTML-documenten is ook in het algemeen ineffectief; sommige browsers kunnen deze markup honoreren, maar andere caches negeren dit geheel.
Verdere behandeling kan worden gevonden op <http://www.mnot.net/cache_docs/>.
Dat kan je niet. De browser heeft de broncode nodig om jouw document weer te geven. Je moet de complete, niet-versleutelde broncode naar de browser sturen. Zelfs als een bepaalde browser geen "Bron Tonen" mogelijkheid heeft, zijn er vele anderen die dat wel hebben, en je kunt altijd een document met de hand ophalen (met behulp van telnet) om de broncode te krijgen. Of de cache van de browser bekijken.
Er zijn trucs die het voor sommige lezers moeilijker maken om de bron te bekijken of op te slaan (bijv. het wijsmaken van newbies dat er niks is, door het toevoegen van een paar dozijn lege regels aan het begin van het document, of het gebruik van JavaScript om de rechter-muis-knop af te vangen). Maar deze trucs hebben, net als met trucs die proberen te voorkomen dat afbeeldingen worden opgeslagen, maar een heel beperkt effect en ze kunnen diverse problemen veroorzaken voor legitieme gebruikers.
Dat kan je niet. URL's zijn de grondslag van de navigatie op het WWW. De URL is onmisbaar voor de browser om je document binnen te kunnen halen. Het is onmogelijk om de URL van een bron voor de browser te verbergen.
Veel browsers identificeren zichzelf wanneer ze een document aanvragen. Een CGI script zal deze informatie beschikbaar hebben in de HTTP_USER_AGENT omgevings-variabele, en kan deze gebruiken om een versie van het document te versturen, die is geoptimaliseerd voor die browser.
Bedenk dat niet alle browsers zichzelf correct identificeren. Microsoft Internet Explorer, bijvoorbeeld, claimt "Mozilla" te zijn om voor Netscape verbeterde documenten te krijgen.
En als een cache-proxy voor Netscape verbeterde document bewaart, zal iemand met een andere browser dit document natuurlijk ook krijgen als hij gebruikt maakt van deze cache.
Vanwege deze en andere redenen, is het geen goed idee om het raad-de-browser-spel te spelen.
Daar kom je niet achter. Alhoewel iedere aanvraag voor een document normaal gesproken wordt gelogd met het naam of het adres van de 'remote host', wordt de werkelijke usernaam bijna nooit gelogd. Dit is vooral zo vanwege performance redenen, aangezien het vereist dat de server het 'ident protocol' gebruikt om te kijken wie er aan de andere kant is. Dat kost tijd. En als een 'cache proxy' de aanvraag doet, krijg je geen zinvolle resultaten.
Maar denk eens even na... wil je nu echt dat elke site die je bezoekt jouw e-mailadres weet? Stel je voor hoeveel bergen automatische dankjewel's je zou ontvangen. Als je 20 sites bezocht, zou je minstens 20 e-mails krijgen die dag, en ongetwijfeld ook nog uitnodigingen om later terug te komen. Het zou een nachtmerrie zijn en een schending van de privacy!
In Netscape 2.0 was het mogelijk om automatisch een formulier te versturen met een mailto als actie, met behulp van JavaScript. Hiermee werd een e-mail gestuurd naar de eigenaar van het document, met het adres dat de bezoeker had ingesteld in de 'From' regel. Dat kan natuurlijk "mickey.mouse@disney.com" zijn. In Netscape 2.01 is dit opgelost.
De meest betrouwbare manier is het plaatsen van een formulier, waarin je de bezoeker vraagt zijn e-mailadres in te vullen. Om de kans te verhogen dat bezoekers dat ook werkelijk doen, kan je iets nuttigs aanbieden als wederdienst.
Recente versies van Internet Explorer gebruiken standaard "gebruikersvriendelijke" HTTP foutberichten. Als een speciaal HTTP antwoord (bijv. een 404 antwoord) korter is dan 512 bytes, zal de browser het eigen bericht gebruiken in plaats van het door de server geleverde bericht. Als gebruiker van Internet Explorer kunt je dit uitschakelen in het "Geavanceerde" opties paneel. Voor webauteurs is het groter maken van de foutpagina's de enige oplossing.