Amino Ekspertblog

Ekspertblogger på Amino om SEO & reputation management

HUSK at passwordbeskytte dit test website!

7. december 2010 | 3.031 Visninger| 42 kommentarer
Hvor mange stjerner giver du?:

Amino Ekspertblog

Mikkel deMib Svendsen

Ekspertblogger på Amino om SEO & reputation management

Ufærdige websites skal ikke ligge frit tilgængelige så alle og enhver – inklusiv søgemaskinerne, kan tilgå dem. Punktum! Alligevel oplever jeg igen og igen, at webbureauer ikke respekterer dette eller tager problematikken seriøst. Det er katastrofalt. For konsekvenserne af det kan være yderst alvorlige.

Det står på side 1 hver gang jeg skriver en SEO-kravspecifikation: Passwordbeskyt test-websitet! Det burde ikke være så svært. Alligevel oplever jeg alt for ofte at webbureauer, designere og udviklere ikke overholder dette simple krav. De lader simpelt hen test-websitet stå pivåbent. Jeg har oplevet det 2 gange bare indenfor det sidste måned, så nu synes jeg det var passende med et offentligt opråb.
  

Hvad kan der ske, hvis dit test-website ikke er passwordbeskyttet?

Der er flere problemer forbundet med, at lade dit test-website stå åbent og ubeskyttet.

1) Du kan blive til grin
Hvis dine kunder, konkurrenter, pressen eller forretningspartnere ser dit ufærdige website – måske uden at vide, at det faktisk er ufærdigt, kan du blive gjort til grin over de fejl, der sikkert er. At blive til grin kan du måske overleve, men hvis det forplanter sig hos dem der ser det kan det få alvorlige konsekvenser for dit gode ry og rygte – din online reputation, og det kan koste dyrt på sigt.

2) Du står juridisk til ansvar for det der står
Formelt set står du til ansvar for det du publicerer – også selvom det er på det du kalder et ”test-website”. Så hvis der står forkerte priser, produktinformationer eller andre urigtige informationer, så kan du risikere at hænge på dem. Det kan også være du har ”lånt” nogle billeder eller tekster på Nettet og brugt det som dummy-fyld i testversionen, men hvis ikke den er passwordbeskyttet, så kan du knaldes for ulovlig kopiering.

3) Det kan TOTALT fucke SEO på dit nye website op!
I forhold til SEO er det en katastrofe, hvis du lader dit test-website stå åbent, så søgemaskinerne kan komme ind og indeksere det.

Det der i værste fald kan ske er, at dit test-website bliver indekseret og når du så lancerer det færdige website på den rigtige adresse, så tror søgemaskinerne at det er en kopi af dit test-website – og at test-websitet er originalen. Resultatet bliver, at du ikke kan få dit rigtige website indekseret. Det kan tage op til over 1 år at løse den type problemer. I al den tid vil du være helt usynlig i søgemaskinerne. Og det var nok ikke lige den start på dit nye website du havde håbet på, vel?


Men hvordan kan folk overhovedet finde min test-website?

Det er et godt spørgsmål. Måske tænker du, at hvis jeg nu ikke linker til det, så er der da ingen der kan finde det. Wrong!

Den type strategier kan betegnes som ”security by obscurity” – altså, at din sikkerhed bygger på, at andre folk nok ikke gør noget, som de ikke bør, og nok ikke gætter sig til, eller på andre måder finder ud af noget som du ikke ønsker de skal finde ud af (i dette tilfælde adressen på dit test-website).

Security by obscurity er generelt set en virkelig dårlige form for sikkerhed. Jeg kan bestemt ikke anbefale, at du gambler med din SEO – og de andre problemer nævnt ovenfor, på den måde. Det er for åndssvagt. Særligt set i lyset af, hvor let det faktisk er, at passwordbeskytte dit website.

Jeg har flere gange konstateret, at folk har gættet sig til selv meget lange og virkelig obskure URLs til nye test-sites. Jeg ved ikke altid helt hvordan de gør det, men faktum er, at det hele tiden sker. Og hvis bare en kender adressen, så går der ikke længe før mange andre også kender den.


Brug robots.txt, hvis du ikke passwordbeskytter dit test-website!

Hvis du ikke har mulighed for, eller lyst til, at passwordbeskytte dit test-website, så bør du i det mindste beskytte det mod crawling via robots.txt. Du skal blot indsætte følgende kode i en fil med navnet robots.txt og ligge den i roden af dit test-website:

User-agent: *
Disallow: /


Gør passwordbeskyttelse til et ufravigeligt krav

Til slut vil jeg blot huske dig på, at understrege overfor dem der skal udvikle dit nye website, at de skal password beskytte test-websitet og, at hvis de glemmer det vil du betragte det som et alvorligt og erstatningspådragende brud på aftalen. Hvor meget koster 1 år ude af Google dig? Det er det beløb + de omkostninger der eventuelt kommer til eksperthjælp, som din leverandør skal vide, at de kan komme til at skulle betale dig i erstatning, hvis de ikke overholder dette simple krav.

 

Læs også


Kommentarer

Iryna  den 07-12-2010 kl. 16:37

Virkelig god artikel! Jeg er selv ved at begå denne fejl i allerhøjeste grad. Men hvis man ikke kender noget til det, så er det bare ikke noget man tænker over.

Jeg takker for at du gør opmærksom på det! Skal ikke ske igen!

Er kommentaren brugbar? 0 0
Thomas Rosenstand  den 07-12-2010 kl. 17:08

Hej Mikkel

Helt enig - undtagen i den med robots.txt, som faktisk er direkte forkert. En robots.txt beskytter ikke mod at blive "optaget" indeks med URls - den beskytter kun mod indeksering. Det snyder mange - og forklaringen er her: www.youtube.com/watch

Skal der lukkes af, skal det ske med "noindex" i head.

Er kommentaren brugbar? 0 0
Henrik Nielsen  den 07-12-2010 kl. 17:08

Godt og relevant indlæg. Jeg ser også ofte WordPress eller lignende sites lige klar til at blive installeret. Fatter ikke folk tør at risikere at der bliver uploadet noget skrammel :-) men det er jo nok glemsomhed

Er kommentaren brugbar? 0 0
Henrik Nielsen  den 07-12-2010 kl. 17:09

Godt og relevant indlæg. Jeg ser også ofte WordPress eller lignende sites lige klar til at blive installeret. Fatter ikke folk tør at risikere at der bliver uploadet noget skrammel :-) men det er jo nok glemsomhed

Er kommentaren brugbar? 0 0
Thomas Rosenstand  den 07-12-2010 kl. 17:12

Lille rettelse til min kommentar: Det er sandt, at robots.txt beskytter mod at blive crawlet - men ikke mod at blive fundet, og dermed er dine pkt. 1 og 2 stadig en risiko. Er du ikke enig i, at et "noindex" er bedre i udviklingsperioden - hvis der altså ikke passwordbeskyttes?

Er kommentaren brugbar? 0 0
jebla  den 07-12-2010 kl. 17:36

Godt indlæg, så logisk men alligevel noget man let glemmer og ikke får tænkt ordentligt over konsekvenserne ved. Det sker ikke igen nu.

Mht. robot.txt er man vel beskyttet mod ikke at blive udelukket af google pga. samme indhold når website lanceres. Test site er vel kun indexeret og ikke crawlet. Så de burde vel ikke kunne se at det er samme indhold på test site og det endelige site?

Er kommentaren brugbar? 0 0
jebla  den 07-12-2010 kl. 17:36

Godt indlæg, så logisk men alligevel noget man let glemmer og ikke får tænkt ordentligt over konsekvenserne ved. Det sker ikke igen nu.

Mht. robot.txt er man vel beskyttet mod ikke at blive udelukket af google pga. samme indhold når website lanceres. Test site er vel kun indexeret og ikke crawlet. Så de burde vel ikke kunne se at det er samme indhold på test site og det endelige site?

Er kommentaren brugbar? 0 0
Birgitte  den 07-12-2010 kl. 17:45

Ai - den blog kunne du godt være kommet med for 4 uger siden - mit testsite endte med at få en ordre fra en kunde - det var pinligt at skulle forklare hvorfor hun lige skulle bestille igen.

Du har selvfølgelig helt ret og .htaccess er hermed rettet på alle mapper.

Er kommentaren brugbar? 0 0
Mikkel deMib Svendsen  den 07-12-2010 kl. 18:12

Der fik du vist lige rodet lidt rundt i tingene, Thomas :)

Som jeg netop skriver i artiklen "... beskytte det mod crawling via robots.txt.".

Hvis det er et helt nyt test-domæne du sætter op, hvilket normalt er tilfældet, så er robots.txt både den letteste og bedste metode. Uden crawling intet dublicate content - og det er jo alene det vi er ude efter at beskytte os imod, når den metode anvendes.

Men det er som sagt ikke den bedste metode. Det er meget bedre at passwordbeskyttet sitet (hvilket dog HELLER ikke beskytter mod indeksering, men det beskytter fuldt ud mod duplicate content, da materialet ikke kan crawles).

Ved at have hele ekskluderingen samlet i en fil er det også min erfaring at folk oftere husker at rette det. Hvis hver enkelt template/side har fået sat NOINDEX på synes jeg langt oftere, at folk glemmer at rette alle sider, når de går live. Og så sker der jo ligesom ikke så meget med de sider.

Det er stadig nummer 1 grund til at alle de kunder jeg gennem tiden har rådgivet ikke er blevet indekseret - at de selv har blokeret for crawling eller indeksering :)

Er kommentaren brugbar? 0 0
egeek  den 07-12-2010 kl. 18:18

Helt enig med Rosenstand.

robots.txt forhinder Googlebot i at crawle siden, men ikke Google i at vise den. Siden kan bla. findes og indekseres af Google, hvis andre linker til den.

Man bør benytte sig af:

<meta name="robots" content="noindex, nofollow" />

Som forhindrer Google i at vise siden, samt følge og indeksere links på siden.

Mere info kan læses på:

sites.google.com/.../faq--crawling--indexing---ranking

Er kommentaren brugbar? 0 0
Mikkel deMib Svendsen  den 07-12-2010 kl. 18:30

I glemmer context og formål :)

Ekskludering er som sagt en nødløsning hvis man ikke kan eller vil passwordbeskytte test-sitet. Formålet er, at sikre, at der ikke opstår duplicate content, når de rigtige site lanceres.

Det er yderst sjældent, at der opstår så mange links til et test-site, at Google finder på at inkludere links til sider, de ikke må eller kan crawle. Der skal nemlig en del til. Ja, faktisk har jeg aldrig selv set det eller hørt om det. Har I - Thomas eller Egeek nogle eksempler på test-sites, der typisk kun er live kort tid, som er blevet omfattende indekseret selvom der har været brugt robots.txt?

Passwordbeskyttelse giver som sagt heller ikke beskyttelse mod ikke at blive indekseret. I princippet kunne Google også finde på at inkludere URL's fra et passwordbeskyttet site. Det er bare ikke særlig sandsynligt.

Er kommentaren brugbar? 0 0
Thomas Rosenstand  den 07-12-2010 kl. 18:54

Jamen Mikkel - jeg skrev jo også en rettelse. Men dit eget pkt. 1 og 2 gælder vel stadig? Så context og formål er skam ikke glemt - og duplicate content er ikke det eneste, vi ønsker at beskytte os mod. Og som du selv skriver: Folk finder de mest obskure ting via ditto URLs. Så en fuldstændig udelukkelse fra index i stedet for blot en udelukkelse fra crawl er at foretrække. Better safe than sorry - det er i hvert fald den approach, jeg bedst kan lide.

Men det er jo blot en detalje - bortset fra det har du 100% ret. Og ufatteligt at det stadig ultimo 2010 er mere reglen end undtagelsen, at udviklingssites indekseres.

Er kommentaren brugbar? 0 0
egeek  den 07-12-2010 kl. 18:58

Du har højst sandsynlig ret mht. det er sjældent sites med "User-agent: * Disallow: /" bliver indekseret i Google, men det vil i realiteten være muligt.

Hvis vi ser bort fra duplicate content og fokuserer på punk 1 & 2, vil det derfor være en god idé med "noindex" efter min overbevisning. Better safe than sorry. :)

Passwordbeskyttelse samt "User-agent: * Disallow: /" burde vel forhindre Google i at indeksere siderne, så frem der ikke bliver linket til dem?

Er kommentaren brugbar? 0 0
Thomas Rosenstand  den 07-12-2010 kl. 19:01

Hov - overså dit spørgsmål - sorry. Nej - jeg har ingen eksempler på testsites, der er blevet omfattende indekseret trods robots.txt. Men jeg har set flere, der er blevet delvist indekseret med uncrawled URLs på den konto. Derfor reagerede jeg ;-)

Er kommentaren brugbar? 0 0
egeek  den 07-12-2010 kl. 19:03

Du var en smule hurtigere Thomas, men samme tanke. :)

Mht. crawling af passwordbeskyttede sider, benytter jeg på eks. Wordpress blogs "User-agent: * Disallow: /wp-admin/", hvorfor backend ikke kan findes i Google.

Er kommentaren brugbar? 0 0
Mikkel deMib Svendsen  den 07-12-2010 kl. 19:36

Uanset om du passwordbeskytter eller bruger robots.txt kan dine sider i teorien blive indekseret. Jeg har som sagt bare aldrig oplevet at det er sket for test-sites, der jo ofte kun er oppe nogle få måneder, indtil det rigtige site går i luften. Og jeg hører heller ingen andre her sige, at de har set det i den slags situationer.

Selv ved brug af NOINDEX kan en side i princippet blive indekseret ud fra links alene - som med passwordbeskyttede og robots.txt beskyttede sider. Det kræver nemlig at søgemaskinerne faktisk crawler siden for at se at der er NOINDEX på den. Hvis de alene smider den i indekset på basis af links til den, så ser de det jo ikke.

Men begge disse scenarier er som sagt bare langt fra virkelighedens verden.

Og i virkelighedens verden oplever jeg MEGET oftere problemer, når folk først skal indsætte NOINDEX på en masse forskellige sider på et test-site - og derefter fjerne dem alle igen, når de går live. Alt for ofte glemmer de nogle sider, der så bliver indekseret på test-sitet, eller som ikke bliver indekseret på det nye rigtige site.

De kan naturligvis også glemme at rette i robots.txt når de går live, men så opdages det hurtigere, end hvis det blot er nogle få sider de har glemt det på, og det er let at rette, da det kun skal gøres et sted.

Er kommentaren brugbar? 0 0
egeek  den 07-12-2010 kl. 20:02

Mener du at en Wordpress backend kan blive indekseret, på trods af man benytter sig af: "User-agent: * Disallow: /wp-admin/"? Ikke nødvendigvis et test site, men fast website.

Det er rigtigt Google crawler alle sider, men når den støder på "NOINDEX", vælger den ikke at indeksere dem.

Er ikke uenig i dine udtalelser, er bare mere interesseret i teorien bag, end hvorvidt folk begår fejl i praksis. :)

Er kommentaren brugbar? 0 0
Mikkel deMib Svendsen  den 07-12-2010 kl. 20:06

Teoretisk set, ja. Hvis der er mange der linker til en given URL kan Google godt finde på, at smide den i deres index. Nogle har vurderet at det er helt op imod 2/3-dele af Googles samlede indeks som de ikke har crawlet - og de sider de ikke har crawlet, der ved de naturligvis ikke om der er NOINDEX på eller bruges robots.txt blokering. Det finder de først ud af når de besøger siden.

Men i forhold til din back-end, eller et passwordbeskyttet site er problemet jo i praksis ikke eksisterende. For der bliver aldrig tale om DC problemer, og skulle nogle så alligevel finde URL'en - enten via en obskur søgning i Google, eller på andre måder, kan de jo ikke komme ind uden password.

Er kommentaren brugbar? 0 0
egeek  den 07-12-2010 kl. 20:21

Det er så bare her jeg mener at sider med NOINDEX ikke indekseres, hvorimod sider der blokeres ved hjælp af robots.txt godt kan indekseres hvis der linkes til dem, som du også skriver. Det kræver selvfølgelig Googlebot kommer forbi og opdager NOINDEX.

www.google.com/.../answer.py

Mht. backend tænker jeg ikke på DC, men mere om urlen til backend på nogen måde vil kunne opstå i Google, selvom der er benyttet robots.txt til at skjule denne, samt der selvfølgelig ikke linkes dertil?

Er kommentaren brugbar? 0 0
Mikkel deMib Svendsen  den 07-12-2010 kl. 20:26

Du får blandet tingene lidt sammen. Læs mit svar ovenfor igen, der står det :)

Er kommentaren brugbar? 0 0
Ralf Willers  den 07-12-2010 kl. 20:52

Problemet kan undgås hvis der er tilgang til en .htaccess fil på websitet

robots.txt / noindex mv. forudsætter at Google følger dine anvisninger, men Google skal først indexerer din side før den kan opdage robots.txt / noindex

For helt at undgå Google på testsites kan nedenstående benyttes.

<limit GET>

satisfy any

order deny,allow

deny from all

allow from xx.xx.xx.xx

require valid-user

</limit>

Forudsætter at der er tilgang til en .htaccess

Ovenstående kan også laves i en Global.asax fil

Er kommentaren brugbar? 0 0
Mikkel deMib Svendsen  den 07-12-2010 kl. 21:18

> Google skal først indexerer din side før den kan opdage robots.txt / noindex

Det er nu ikke helt rigtigt. Google skal downloade robots.txt filen, for at se de ikke må crawle sitet. Den kigger de efter med jævne mellemrum. Men de behøver skam ikke indeksere nogle sider fra sitet for at se den.

For at se NOINDEX skal de besøge de enkelte sider - som minimum med et HEAD request

Er kommentaren brugbar? 0 0
Ralf Willers  den 07-12-2010 kl. 21:31

Du har ret i at Google mv. af og til kun henter robots.txt.

Men sagens kerne er, hvorfor lade det være op til Google om anvisninger skal følges.

Det er set før at Google 'glemmer' at følge anvisningerne, og det må da være op af bakke hvis man skal kæmpe med duplicate content allerede inden man er i luften med det nye site..

I min verden er det noget der styres på server siden, så kan der ingen tvivl være om Google får adgang eller ej.

Er kommentaren brugbar? 0 0
Mikkel deMib Svendsen  den 07-12-2010 kl. 21:33

Jeg tror lige du skal læse artiklen igen, og kommentarerne ovenfor, der er ingen grund til at starte forfra i den samme diskusion :)

Er kommentaren brugbar? 0 0
Online Marketing  den 07-12-2010 kl. 22:34

Hej Mikkel

Der er rigtigt mange CMS og shop udbydere, der praktiserer dette til fuldkommenhed, det ses bla. hos et af landets største CMS huse, de har konsekvent deres kunders website liggende på subdomæner på deres eget navn, værst af alt de tilbyder sågar SEO, og oven i købet professionelt, som de kalder det, og udbyder seo certificeringskurser etc.

Jeg har haft fat i dem flere gange når vi har optimeret på nogle af deres løsninger, de forstår ikke problematikken, men fjerner så skoddomænet efter diverse diskussioner.

Hvis man ønsker at lukke helt af for det nye site kan man køre det uden om dns serveren og anvende den lokale maskines hostfil.

Et eksempel.

# Copyright (c) 1993-2006 Microsoft Corp.

#

# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.

#

# This file contains the mappings of IP addresses to host names. Each

# entry should be kept on an individual line. The IP address should

# be placed in the first column followed by the corresponding host name.

# The IP address and the host name should be separated by at least one

# space.

#

# Additionally, comments (such as these) may be inserted on individual

# lines or following the machine name denoted by a '#' symbol.

#

# For example:

#

#      102.54.94.97     rhino.acme.com          # source server

#       38.25.63.10     x.acme.com              # x client host

127.0.0.1       localhost

::1             localhost

88.88.888.111 www.mitfedewebsite.dk

81.25.255.110 www.mitgodewebsite.dk

Det er fiktive IP addresser, der er vist i eksemplet.

Hostfilen ligger i følgende bibliotek.

Windows Vista = c:\windows\system32\drivers\etc

Windows XP = C:\windows\system32\drivers\etc

Man skal huske at tilgå den som administrator, eller kan man ikke rette i filen, derefter vil den lokale maskine kunne tilgå dette domæne.

Mvh.

René Madsen

Er kommentaren brugbar? 0 0
egeek  den 08-12-2010 kl. 00:41

"Hvis man ønsker at lukke helt af for det nye site kan man køre det uden om dns serveren og anvende den lokale maskines hostfil."

Det ændrer jo kun URI lokalt på den enkelte maskine, hvilket ikke giver meget mening.

Du kan selvfølgelig oprette sitet på serveren uden at tildele det et domæne, og i stedet gøre det lokalt som i dit eksempel, men dette forhindrer på ingen måde Google i at indeksere dit site.

Mest optimale løsning på hele problematikken, vil være at lukke af for alle IP'er, pånær dem hvis personer skal have adgang til sitet. Dette gøres ved hjælp af .htacces som Ralf Willers er inde på.

Er kommentaren brugbar? 0 0
Online Marketing  den 08-12-2010 kl. 09:29

@ "Det ændrer jo kun URI lokalt på den enkelte maskine, hvilket ikke giver meget mening."

Proceduren er at der oprettes et domæne på serveren hos den nye udbyder som normalt, uden det gøres offentligt. (Der peges ikke DNS på dette domæne indtil sitet er gjort færdigt). Derefter få oplyst hvilket IP nummer sitet ligger på hos udbyderen, man kan nu tilgå det via opsætning i en lokal hostfil fra en hvilken som helst maskine ved indtastning af IPadressen og den aktuelle mappe som websitet ligger i. (domænenavnet)

Webserver mappen bliver ikke synlig da man normalt ikke tilgår et domæne via IP adressen, hvis serveren er sat korrekt op.

I mange tilfælde skal brugeren skifte udbyder alligevel, domænet oprettes derfor som normalt, men gøres ikke synligt før domænenavnet peges over på den nye webserver.

Mvh.

René Madsen

Er kommentaren brugbar? 0 0
Mikkel deMib Svendsen  den 08-12-2010 kl. 09:34

Det svarer vel lidt til at flyve mod øst når man skal til New York ... ja, man kommer til sidst frem, men det er sgu lidt af en omvej :)

Er kommentaren brugbar? 0 0
Online Marketing  den 08-12-2010 kl. 10:01

Hej Mikkel

Man kommer frem, fordelen er at der reelt kan arbejdes på det færdige website hos den nye udbyder, hvor alle funktioner er i den færdige version, stier passer mv. (De peger ikke ned på test urlér etc.).

Det er kun at rette en linje i hostfilen for at få adgang til det nye website, udbyderen slipper også for at flytte det bagefter, men kan pege DNS ind på domænet og det er i drift.

Findelingstjenester, ssshhh, omgår også offentlighedens lys på samme måde når der bliver lukket ned for dem, så kører de det typisk via IPadresser og hostfil opsætning.

Men budskabet i artiklen er helt klar, der skal udelukkes på den ene eller anden måde, så det ikke indekseres og skader det nye website.

Mvh.

René Madsen

Er kommentaren brugbar? 0 0
Jimmy B. Carlsen  den 08-12-2010 kl. 10:09

Vedrørende password-beskyttelse, så forudser jeg et kæmpe problem, hvis man har brug for at blive godkendt til en indløsningsaftale hos PBS/Nets/Teller.

Min erfaring siger mig, at de er rimelig strikse - og at de snildt kunne finde på at gå i baglås over et password.

Men hvis nogen har prøvet at få godkendt et testsite med password på hos PBS, så er det jo bare dejligt, og så trækker jeg min bekrymring tilbage.

Er kommentaren brugbar? 0 0
Steffen Daleng  den 08-12-2010 kl. 14:35

Indtil videre har jeg aldrig gjort andet end at lave en disallow i robots.txt, uden nogle problemer.

At skulle til at lave en NOFOLLOW på næsten 100 sider, forekommer mig fuldstændigt uoverskueligt, og som det også bliver nævnt så er der jo en overhængede risiko for at der sker en smutter, når man launcher. For ikke at nævne hvem der skal betale regningen for at side og lave DOFOLLOW/NOFOLLOW på næsten 100 sider.

Men en ting jeg faktisk bliver lidt i tvivl om, er når man fx bruger Wordpress, og evt. har et Maintainance plugin installeret, der lukker af for at "ikke indloggede" bruger kan se sitet.  Crawler den så stadig siderne, eller ér den password protected til sitets urls, så google ikke crawler ?

Indtil videre har jeg ikke taget chancen, og har bare kørt disallow, på alt i robets, af ren og skær vane, men det kunne da være sjovt at høre.

Er kommentaren brugbar? 0 0
Mikkel deMib Svendsen  den 08-12-2010 kl. 15:31

Ja, og 100 sider er i min verden et lille bitte site. De fleste af de kunder jeg arbejder med har tusindvis af sider, en del af dem millioner og enkelte oppe i milliarder. Her bliver NOINDEX strategien endnu mere umulig :)

Er kommentaren brugbar? 0 0
Steffen Daleng  den 08-12-2010 kl. 16:41

"Mikkel: Blæremås   ;)  Men du har fuldstændigt ret. I dit niveau vil det jo være fjollet bare at tænke tanken. Med mindre man selvfølgelig kan bruge en form for injection software til det, hvis det overhovedet eksisterer.

En anden tanke er i forhold til Punkt 1 og 2. Generelt set er der vel ikke nogen måde for konkurrenter at gå ind og screene server indhold, så med mindre de har fået et insider tip om hvilke klienter man arbejder med, og kan gætte sig frem til en mappe placering på serveren, så har de vel reelt set ikke nogen mulighed for at afsløre testsitet for offentligheden og evt linke til det for at få Google til at indexere de gældende URLs?

Er kommentaren brugbar? 0 0
Mikkel deMib Svendsen  den 08-12-2010 kl. 16:57

Crea8ive - som sagt er Security by Obscurity ikke en metode jeg kan anbefale. Jeg har flere gange oplevet test sites med MEGET, MEGET lange og underlige test-adresser blive fundet af folk, der så efterfølgende har lavet grin med dem andre steder på Nettet.

Passwordbeskyttelse, IP-låsning eller andre sikre metoder til at holde uvedkommende ude er langt at foretrække. Og i reglen er det faktisk ikke så svært at få sat et globalt password på et site - det kan gøres på server-niveau. I reglen er der ikke brug for flerbrugerstyrring til denne form for afslåsning - et login kan bruges på tværs af de, som oftest relativt få, der har brug for at kigge med på test-sitet.

Er kommentaren brugbar? 0 0
Thomas Rosenstand  den 08-12-2010 kl. 17:00

Nu er jeg jo langt fra programmør, men som regel lykkes det mig at få de programmører, der arbejder for mine kunder (og det er også sjældent sites med omkring 100 sider ;-) ) til at lave en funktion, så de med et flueben kan knalde "noindex" ind i head - og ud igen ved at fjerne fluebenet.

Og når sitet går i luften, fjerner de funktionen helt - bare for en sikkerheds skyld ;-)

Er kommentaren brugbar? 0 0
egeek  den 08-12-2010 kl. 19:40

Mht. jeres hundrede, tusinder og milliarder sider, er header selvfølgelig gemt i en separat fil, så denne kun skal rettes ét sted. ;-)

Er kommentaren brugbar? 0 0
Mikkel deMib Svendsen  den 08-12-2010 kl. 19:59

Det er nu ike helt korrekt. Meget ofte består så store sites af mange helt forskellige dele, som er konstrueret forskelligt. Nogle store virksomheder bruger endda flere CMS oveni hinanden. En enkelt større US virksomhed jeg husker brugte 4-5 til at danne et site.

Så nej, arkitekturerne omkring større sites er ikke altid så enkel. Og nej, det er langt fra altid at ting der ellers burde synes enkle bliver det, når det skal igennem en tung IT afdeling eller skal løses af et webbureau, som er 7000 arbejdstimer bagud allerede (som det faktisk var tilfældet for en af mine kunder for nyligt).

Faktum er, at i langt de fleste tilfælde, hvor man ikke kan udelukke et test-site ordentligt - med adgangsspærring for alle dem der ikke må komme ind, så er en central robots.txt den absolut letteste og sikreste metode. Den løser den opgave der skal løses sikkert og der er stor sikkerhed for at den ikke fejler, hverken ved implementering eller nedtagning. Samlet set er det derfor langt oftest bedst.

Men der kan naturligvis altid være undtagelser - det er der altid.

Men som sagt - det vigtigste at holde fast i er, at adgangsspærring er bedre end blot udelukkelse fra crawling eller indeksering.

Er kommentaren brugbar? 0 0
Online Marketing  den 09-12-2010 kl. 21:27

Jeg har sat mange store websites op til bla. rejsebureauer, et af de store teleselskaber i Norden og en af de store banker, her er der ikke tale om en webserver, men mange webservere til et domænenavn og de subdomæner og sprogversioner de anvender.

De store websites jeg har arbejdet med deler ikke space med andre websites, da de ikke ligger på et webhotel(one.com, surftown.dk). De kræver i forvejen maksimal ydelse af den enkelte server, mange danske webshops er ligeledes nødsaget til at køre deres shopløsninger på egne webservere, som kun indeholder deres egne websteder, hvis tilgangstider etc. skal være rimelige og serveren ikke skal gå kold, når der kommer mange besøg.

Et websted, der skal servicere mange brugere og indeholder mange sider består typisk af en eller flere loadbalancer servere og underliggende servere til håndtering af disse opgaver med applikationerne. Der kan alternativt også anvendes en DNS løsning, som kaldes Round Robin til fordelingen til den enkelte server (fattigmandsmodellen).  

Så proceduren har været at opsætte en ny server på en given IP adresse og tilgå den med den tidligere nævnte hostfil løsning, efterfølgende når sitet er færdigt peges domænenavnet over på den nye server og sitet kører efterfølgende som det gjorde i testmoden, når det går online.

Fordelen ved denne løsning er, at sitet ikke er public, det kan kun ses af dem der tilpasser deres hostfil med den rette IP adresse og det nuværende rigtige domænenavn.

Samme løsning kan også anvendes på små løsninger på et webhotel, ligesom de andre teknikker nævnt her i tråden kan anvendes til spærring på et testdomæne med passwords beskyttelse, IP blokering etc.

Ulempen med disse teknikker er, hvis man ikke sikrer sig urlér peger rigtigt (direkte urlér) risikerer man at der i den version, der går online stadig peges ind på det tidligere testdomæne, og i billedmapper der ikke eksisterer..

NU vil mange sige det ikke er et problem, jeg kan dokumentere mange tilfælde fra nogle af de største CMS og shopudbydere her i landet, hvor billedstier / urladresser cykler rundt med testdomæne urlér i færdige versioner af shops etc.

Jeg har skrevet en lille guide til hvordan man kan bruge denne model.

blog.onlinemarketing.dk/beskyt-dit-website-mod-indeksering-pa-testdomaene.html

Mvh.

René Madsen

Er kommentaren brugbar? 0 0
Kasper Bergholt  den 10-12-2010 kl. 08:05

Ja, det er skræmmende, hvor mange 360-graders bureauer, der laver den her slags fodfejl, når det kommer til basal seo.

Sidste uge gjorde Brian Brandt mig opmærksom på, at DanDomain lod alle midlertidige domæner (kasperbergholt.org.dandomainserv32.dk fx) forblive aktive, efter registreringen af primærdomænet faldt på plads. Det er også en dejlig omgang duplicate content, man kan rode sig ud i dér.

Jeg har været tilknyttet projekter, hvor 3 forskellige versioner af et site lå på forskellige url'er med samme indhold på grund af præ-launche site, test server og udbyders testserver.

Helt knold.

Så godt brølt!

Er kommentaren brugbar? 0 0
Bjørn Nielsen  den 10-12-2010 kl. 12:37

Jeg vil lige komme med en kommentar ind budskabet drukner i tekniske detaljer :)

Først: Jeg ser også hver uge, ufærdige hjemmesider. Det er faktisk ret så irriterende, og er skyld i, at jeg ikke tør købe noget hos små web butikker.

Da det virker utroværdigt.

Men jeg er samtidigt også en af dem som har haft en ufærdig hjemmeside.

Jeg har bare ikke benyttet funktionen test.webadresse.dk

Jeg har bygget mit site op dag for dag, og det er jo også ret useriøst.

Essensen i det her må være, at man tager en snak med sin web hoster eller lign. Inden man går i gang med en hjemmeside.

Så tak for det gode råd Mikkel de MIK.

Er kommentaren brugbar? 0 0
slettet_bruger  den 16-12-2010 kl. 00:13

Hej Mikkel jeg ville bare lige rose din usødede stil.

1) Du kan blive til grin

Jeg kan godt lige love dig for at jeg var flad af grin da jeg så den der.

Altså ikke fordi det er noget vås, men fordi det er smadder sjovt når folk skriver ting så lige ud af posen.

Er kommentaren brugbar? 0 0
x-tra  den 04-01-2011 kl. 22:49

Man kan da heller ikke skjule noget på Internettet, men mange tror de kan. Nogen kæmper for at få besøgende til deres site og så er der dem der slet ikke vil have besøg :-)

Godt skrevet.

Er kommentaren brugbar? 0 0
 

Tilføj en kommentar

 
Husk Mig

Få besked når der kommenteres (Log ind for at få tilsendt mail)
 

Om denne blog


Få besked når Mikkel skriver


Lær mere om SEO!

 

Køb SEO 2.0 og SEO FAQ her
Besøg også min SEO Blog, mit SEO bureau eller mit Webshop firma her.


Mikkel på Twitter

Hvis du vil have besked når Mikkel og ligesindede bloggere har lavet et nyt indlæg, så klik her:


Seneste kommentarer