Sitemap

Hjemmeside redesign fejl, der ødelægger SEO

Redesign af et websted, uanset om det er dit eget eller en kundes, er en væsentlig del af markedsføring i dag.Det er vigtigt, fordi teknologi, trends og brugernes forventninger ændrer sig over tid, og hvis vi vil forblive konkurrencedygtige, skal vi holde trit med disse ændringer.

Men selv om denne opgave er væsentlig, udgør den også visse risici fra et SEO-perspektiv.En række ting kan gå galt under processen.Disse problemer kan potentielt få søgemaskiner til ikke længere at se det pågældende websted som det autoritative svar på relevante forespørgsler.I nogle tilfælde kan visse fejl endda resultere i straffe.

Det er der ingen, der ønsker.

Så i denne artikel vil vi udforske nogle af de almindelige webdesignfejl, der kan ødelægge SEO.At kende de potentielle risici kan hjælpe dig med at undgå at begå den slags fejl, der genererer din organiske søgetrafik.

Lader udviklingsmiljøet gennemgås/indekseres

Folk håndterer udviklingsmiljøer på mange forskellige måder.De fleste opsætter simpelthen en undermappe under deres domæne.Nogle kan oprette et domæne udelukkende til udvikling.Så er der dem, der tager den slags forholdsregler for at skjule deres udviklingsmiljø, som ville give en CIA-agent en varm uklar følelse på det tomme sted, hvor deres hjerte burde være.

Jeg har en tendens til at falde ind under den sidste kategori.

Søgemaskiner vil generelt følge links og indeksere det indhold, de finder undervejs - nogle gange endda når du udtrykkeligt fortæller dem, at de ikke skal.Det skaber problemer, fordi de kunne indeksere to versioner af det samme websted, hvilket potentielt kan forårsage problemer med både indhold og links.

Derfor placerer jeg så mange vejspærringer som muligt i vejen for søgemaskiner, der forsøger at få adgang til mit udviklingsmiljø.

Her er hvad jeg gør.Det første trin er at bruge en ren URL, som aldrig har været brugt til en live hjemmeside før.Dette sikrer, at der ikke er links, der peger på det.Dernæst skal du forbyde alle bots, der bruger robots.txt, og oprette en tom indeksside, så andre mapper ikke er synlige.Tidligere er jeg endda gået så langt som at konfigurere adgangskodebeskyttelse, men i de fleste tilfælde kan det være overdrevent.Du kan foretage det opkald.

Derfra opretter jeg en separat mappe for hver hjemmeside under udvikling.Typisk vil mappenavnet være en kombination af ufuldstændige ord, så det er usandsynligt, at det bliver fundet tilfældigt.WordPress vil derefter blive installeret i disse mapper og konfigureret til også at blokere bots på dette niveau.

Vilkårlig ændring af billednavne på sider, der rangerer godt

Dette er ikke altid et problem, men hvis en webside rangerer godt, kan ændring af navnet på et billede på den side forårsage et tab af rangering.Især hvis webdesigneren ikke ved, hvad de laver.

Jeg har set dette ske mere end et par gange, hvor en kunde hyrer en webdesigner, der ikke forstår SEO, til at redesigne en hjemmeside, der allerede rangerer godt.Som en del af redesignprocessen erstatter de gamle billeder med nye, større billeder, men i mangel af den passende oplevelse bruger de dumme billednavne, der giver nul SEO-værdi, som f.eks. image1.jpg.

Dette fjerner et vigtigt stykke kontekst, som søgemaskiner bruger til at bestemme, hvor en bestemt webside skal placeres.

Sletning af sider eller ændring af side-URL'er uden at omdirigere dem

Under et redesign vil nogle sider næsten helt sikkert ikke længere være nødvendige.Mindre erfarne webdesignere vil ofte blot slette dem.Andre sider kan blive flyttet og/eller omdøbt, hvilket i de fleste tilfælde ændrer deres URL.I disse tilfælde ændrer uerfarne webdesignere ofte disse URL'er og betragter opgaven som afsluttet.

Dette er en stor fejl, fordi nogle af disse sider måske allerede rangerer godt.De har muligvis indgående links, der peger på dem eller er blevet bogmærket af besøgende.

Når du sletter sider, der allerede har indgående links, mister du al SEO-værdien fra disse links.I nogle tilfælde kan dette resultere i et drastisk tab af rangering.

Problemet går dog endnu dybere.Enhver, der klikker på disse links eller bogmærker, vil blive mødt af en 404-side.Det giver ingen værdi for nogen, og endnu vigtigere, det skaber en negativ brugeroplevelse.Dette er vigtigt, fordi Google har bekræftet, at brugeroplevelse er en rangeringsfaktor.

Den korrekte måde at slette sider på er at omdirigere dem til den mest relevante side, der findes i øjeblikket.Med hensyn til at flytte sider, som inkluderer alt, der ændrer URL'en på den pågældende side på nogen måde, er det lige så vigtigt at omdirigere den gamle URL til den nye.

I begge scenarier bør en 301-omdirigering generelt bruges.Dette fortæller søgemaskinerne, at den gamle side er blevet permanent flyttet til den nye placering.For de fleste hostingplatforme opnås dette bedst ved at tilføje den relevante post i din .htaccess-fil.

Hvis du ikke kan se en .htaccess-fil på din server, skal du muligvis justere indstillingerne på dit FTP-program for at se skjulte filer.

Nogle specialiserede hostingplatforme kan bruge en anden metode, så du skal muligvis tjekke med deres supportteam for at bestemme, hvordan du opnår det.

Udfører ikke en fuld crawl efter migrering til og fra udviklingsmiljøet

Uanset hvilken metode du bruger til migrering, er du nødt til at løbe ind i nogle fejl.Typisk vil du først migrere live-webstedet til dit udviklingsmiljø, og senere sende det tilbage til live-serveren, efter du har foretaget og testet ændringer.

En, som jeg ofte støder på, er links i indhold, der peger det forkerte sted hen.På en side eller et indlæg på live-webstedet kan du f.eks. have et link, der peger på:

domain.com/services/

Når det er migreret til udviklingsmiljøet, kan det være:

devdomain.com/client123/services/

Alt er fint og godt indtil videre, ikke?

Men nogle gange, mens du migrerer det færdige websted tilbage til live-serveren, kan indholdet på sider og indlæg stadig indeholde links, der peger til siderne i udviklingsmiljøet.

Dette er blot ét eksempel.Der er utallige links til indhold på et websted - inklusive links til det væsentlige billede, JavaScript og CSS-filer.

Heldigvis er løsningen enkel.Et værktøj som Screaming Frog, der kører fra dit skrivebord, eller et skybaseret værktøj som SEMrush, kan bruges til at crawle hvert enkelt link på dit websted.Dette inkluderer tekstlinks, der er synlige på frontend, såvel som alle links til billed-, JavaScript- og CSS-filer, der er gemt væk i HTML'en på et websted.

Sørg for at gennemgå alle links til eksterne kilder, når det nye websted er blevet migreret til live-serveren, fordi alle links, der peger på dit udviklingsmiljø, vil blive vist som eksterne links - når du finder "eksterne links", der egentlig burde være interne links, kan du foretage de nødvendige rettelser.

Dette trin er vigtigt efter migrering i begge retninger for at forhindre potentielt katastrofale fejl.

Undlader at udføre et komplet funktionstjek på alt

Når en nydesignet hjemmeside er blevet migreret til live-serveren, skal du gøre mere end hurtigt at gennemgå et par sider for at sikre, at tingene ser OK ud.I stedet er det vigtigt at teste alt fysisk for at sikre, at det ikke kun ser rigtigt ud, men også fungerer korrekt.

Dette omfatter:

  • Kontakt formularer.
  • E-handel funktionalitet.
  • Søgemuligheder.
  • Interaktive værktøjer.
  • Multimedieafspillere.
  • Analytics.
  • Bekræftelse af Google Search Console / Bing Webmaster Tools.
  • Sporingspixel.
  • Dynamiske annoncer.

Kan ikke omkonfigurere WordPress og plugins efter migrering til live-serveren

Kan du huske, hvordan vi talte om vigtigheden af ​​at sætte en mur op mellem dit udviklingsmiljø og søgemaskinernes crawlere?Nå, det er endnu vigtigere at rive den væg ned efter at have migreret hjemmesiden til live-serveren.

Det er nemt at undlade at gøre dette.Det er også ødelæggende.Faktisk er det en fejl, jeg lavede for flere år siden.

Efter at have migreret en klients websted til deres live-server, glemte jeg at fjerne markeringen i feltet i Yoast SEO, der fortalte søgemaskinerne ikke at crawle eller indeksere det.Desværre var der ingen, der lagde mærke til det i et par dage, hvorefter hjemmesiden næsten var blevet fjernet fra Googles indeks.Heldigvis stolede de ikke på organisk trafik, og da jeg fjernede markeringen i det felt, blev hjemmesiden hurtigt genindekseret.

På grund af den indvirkning, fejl som disse kan have, er det afgørende, at du efter migrering til live-serveren straks tjekker konfigurationen af ​​WordPress såvel som eventuelle plugins, der kan påvirke, hvordan søgemaskiner behandler dit websted.

Dette inkluderer plugins til:

  • SEO.
  • Omdirigering.
  • Sitemaps.
  • Skema.
  • Caching.

Forsømmer at være opmærksom på detaljer

Ingen af ​​disse fejl er særlig komplicerede eller svære at undgå.Du skal blot være opmærksom på dem, implementere en plan for at undgå dem og være meget opmærksom på detaljerne.

Meninger udtrykt i denne artikel er gæsteforfatterens og ikke nødvendigvis Search Engine Land.Personalets forfattere er opført her.