SharePoint SEO pēc migrācijas: kļūdas, ko labot

Ievads

Pēc Microsoft 365 migrācijas saturs bieži ir pārvietots, bet meklēšanas un publicēšanas loģika paliek vecā. Tieši tur sākas SharePoint SEO problēmas: lapas saglabājas, bet pazūd skaidri URL, meklētājam traucē nekonsekventi failu nosaukumi, un publicēšanas saturs vairs neatbilst jaunajai struktūrai. M365 administratoram tas nozīmē ne tikai dekoratīvu tīmekļa slāni, bet arī tehnisku sakārtošanu: jāpārbauda dokumentu bibliotēku nosaukumu standarti, lapu metadati, navigācija, meklēšanas apgabali un veco saišu pāradresācija. Ja migrācija pārraksta saturu, bet neatjauno saistītos elementus, lietotājs atrod novecojušu versiju vai saņem kļūdu tieši tajā brīdī, kad meklēšanas indeksam būtu jāstrādā precīzi. [1] Praktiski tas nozīmē sākt ar to, ko lietotājs redz meklēšanā un URL, pēc tam pārbaudīt, kā saturs tiek publicēts, un tikai beigās kosmētiski labot lapu dizainu. SharePoint telpu līdzeklis ir atzīts par novecojušu, sākot ar 2025. gada martu, tāpēc 3D vai telpiskā satura scenārijos Microsoft iesaka pārskatīt Mesh pieeju, nevis turpināt būvēt uz novecojuša pamata. [1]

Kāpēc SharePoint SEO pēc migrācijas sabrūk pat tad, ja saturs ir pārvietots

Pēc Microsoft 365 migrācijas galvenā problēma nav pats failu vai lapu pārcelšanas fakts, bet tas, ka meklēšana, saites un publicēšanas struktūra turpina balstīties uz veco organizāciju. Rezultātā saturs fiziski atrodas jaunajā vietā, taču lietotājs to neatrod caur ierasto ceļu: lapas atveras ar citu URL, dokumenti maina atrašanās vietu, un meklēšanas rezultāti sāk rādīt fragmentētus vai mazāk precīzus ierakstus. SharePoint SEO šajā brīdī nozīmē nevis atslēgvārdu atkārtošanu, bet tehnisku sakārtošanu, lai saturs atkal būtu atrodams pēc satura, ceļa un publicēšanas loģikas.

Cēlonis parasti ir informācijas arhitektūras maiņa bez saskaņotas pārejas. Vecais navigācijas modelis paliek cilvēku atmiņā, bet jaunajā vidē lapas dzīvo citos bibliotēku un vietņu ceļos. Ja migrācijas laikā nav pārbaudīti URL, failu nosaukumi, lapu metadati un publicēšanas hierarhija, meklēšana un iekšējās saites sāk strādāt pretēji paredzētajam. Tas īpaši jūtams, ja viena tēma pirms migrācijas bija vienā sadaļā, bet pēc tam sadalīta vairākās vietnēs vai dokumentu bibliotēkās.

Risinājumu sāk ar inventarizāciju. SharePoint administrēšanas vai vietnes līmenī pārbaudi, kuras lapas un bibliotēkas satur biznesa kritisko saturu, un salīdzini vecos un jaunos ceļus. Tad veic šādas darbības:

• atver Site contents un noskaidro, kur atrodas galvenās dokumentu bibliotēkas;
• pārbaudi lapu URL un vietņu struktūru, lai saprastu, kuri ceļi mainījušies;
• salīdzini navigāciju sadaļā Settings un vietnes izvēlnes konfigurāciju;
• pārskati, vai dokumentu un lapu nosaukumi saskan ar jauno informācijas arhitektūru;
• testē meklēšanu no lietotāja skatpunkta: ievadi konkrētus satura terminus un vēro, kura lapa atveras pirmā.

Pārbaude notiek vienkārši: ja lietotājs no sākumlappuses vai meklēšanas rezultātiem nonāk uz pareizās lapas bez manuālas maldīšanās pa bibliotēkām, pamatstruktūra strādā. Tad SharePoint SEO uzreiz iegūst stabilu pamatu, jo saturs vairs neeksistē tikai kā pārvietots fails, bet kā loģiski saslēgta publicēšanas sistēma. Nākamā tipiskā kļūda jau ir daudz konkrētāka — bojāti failu un mapju nosaukumi, kas salauž ielādi pārlūkā.

1. kļūda: bojāti failu un mapju nosaukumi, kas izjauc ielādi pārlūkā

Tipiska kļūda praksē parādās brīdī, kad migrācijas laikā uz jaunajām bibliotēkām tiek pārnesti faili ar nosaukumiem, kas agrāk sistēmā vēl “pārdzīvoja”, bet tīmekļa pārlūkā sāk uzvesties nekorekti. Bieži redzu mapes un failus ar speciālajām rakstzīmēm, kuras sākumā šķiet nekaitīgas, taču tīmekļa ielāde var no tām salūzt vai atvērt dokumentu nepareizi. Microsoft dokumentācija par SharePoint telpām norāda, ka noteiktu speciālo rakstzīmju izmantošana mapju vai failu nosaukumos var izraisīt nepareizu failu ielādi tīmekļa pārlūkprogrammās [1].

Kāpēc tā rodas? Tāpēc, ka migrācijas brīdī uzmanība bieži ir uz saturu, nevis uz adresējamību. Komandu īpašnieki grib saglabāt “cilvēcīgos” nosaukumus, bet neizvērtē, kā tie uzvedas URL, bibliotēkas skatā un pārlūka ielādē. Īpaši riskanti ir nosaukumi ar rakstzīmēm, kas ceļā tiek kodētas, saīsinātas vai interpretētas atšķirīgi. Ja saturs tiek ievietots mapēs ar nekonsekventiem nosaukumiem, meklēšana vēl var atrast failu, bet lietotājs līdz tam nonāk ar kļūdainu atvēršanu, pāradresēšanas cilpu vai tukšu lapu.

Pareizā konfigurācija sākas ar nosaukumu standartu visai bibliotēkai. Microsoft ieteikums SharePoint telpām ir izmantot tikai lielos burtus, mazos burtus vai ciparus failu nosaukumos un mapju ceļos [1]. Praktiskā secība ir šāda:

1. atver dokumentu bibliotēku un pārskati mapju nosaukumus;
2. atrodi vienumus ar speciālajām rakstzīmēm un pārsauc tos pēc vienota standarta;
3. pārbaudi, vai nosaukums joprojām skaidri apraksta saturu bez liekiem simboliem;
4. salīdzini faila ceļu ar to, kā to redz lietotājs pārlūkā vai kopīgotā saitē;
5. testē atvēršanu vairākos scenārijos: no bibliotēkas, no meklēšanas un no kopīgotas saites.

Ja šo soli izlaiž, sekas ir tiešas: nepareizi ielādēts dokuments kļūst par sliktu lietotāja pieredzi, un meklēšana zaudē uzticamību. Cilvēks redz, ka nosaukums ir pazīstams, bet atvēršana nenotiek vai notiek citādi, nekā gaidīts. Tas ir viens no ātrākajiem veidiem, kā pēc migrācijas sabojāt SharePoint SEO no tehniskās puses. Tālāk problēma pāriet no failu līmeņa uz lapu līmeni — vecie URL paliek bez pāradresācijas.

2. kļūda: vecie URL paliek bez pāradresācijas uz jaunajām lapām

Šī ir vieta, kur īpaši labi redzama atšķirība starp “saturs eksistē” un “saturs ir sasniedzams”. Pēc migrācijas viena pieeja ir vienkārši publicēt jauno lapu jaunā URL un cerēt, ka lietotāji paši pāries uz jauno struktūru. Otra pieeja ir saglabāt veco adresējamību un novirzīt lietotāju uz atbilstošo jauno lapu. Ja vecie URL paliek bez pāradresācijas, saites no e-pastiem, intraneta un ārējām atsaucēm turpina vest uz tukšu vai nepareizu mērķi, un meklēšana joprojām uzrāda novecojušas saites.

Salīdzinājums praksē izskatās šādi. Pirmā pieeja der tikai īslaicīgam eksperimentam vai iekšējai melnraksta videi, kur neviens nebalstās uz vecām adresēm. Otrā pieeja ir pareiza, kad pēc migrācijas jau pastāv biznesam svarīgi ienākošie ceļi: iepriekš kopīgotas saites, dokumentu bibliotēku adreses, iecienītākie pārlūka grāmatzīmju ceļi un saites no citām vietnēm. Ja jaunā informācijas arhitektūra maina lapu adreses, pāradresācija notur lietotāju plūsmu un samazina situācijas, kur meklēšanas rezultāts aizved uz nepareizu vietu.

Praktiskais ieteikums ir vienkāršs: pāradresāciju uzskati par obligātu migrācijas soli, nevis par “vēl vienu labojumu pēc tam”. Vispirms izveido veco un jauno URL karti. Pēc tam pārbaudi, kuras lapas ir biznesa kritiskas un kuras saņem visvairāk iekšējo saišu. Darbību secība:

• izveido sarakstu ar vecajiem lapu URL un jaunajiem mērķiem;
• pārbaudi, vai katram svarīgajam vecajam URL ir viens skaidrs jaunais mērķis;
• atjauno saites vietnes navigācijā un lapu saturā;
• testē veco URL pārlūkā un pārliecinies, ka tas atver pareizo jauno lapu;
• pārskati meklēšanas rezultātus, lai nepieļautu vairākas konkurējošas adreses vienam tematam.

Ja pāradresācijas netiek sakārtotas, praksē rodas divi zaudējumi: lietotājs zaudē uzticību saitēm, un redakcionālā komanda sāk tērēt laiku manuālai skaidrošanai, kur atrodas jaunais saturs. Šeit SharePoint SEO vairs nav par atslēgvārdiem, bet par to, lai katrs vecais ceļš beigtos pareizajā jaunajā vietā. Nākamais solis ir vēl specifiskāks — publicēšanas lapu pārskatīšana pēc informācijas arhitektūras maiņas.

3. kļūda: publicēšanas lapas netiek pārskatītas pēc informācijas arhitektūras maiņas

Publicēšanas lapas ir pirmais slānis, ko redz lietotājs, tāpēc pēc informācijas arhitektūras maiņas tās jāpārbauda ne tikai vizuāli, bet arī strukturāli. Ja mainīta vietnes sadaļu loģika, lapu hierarhija vai navigācijas mezgli, vecais saturs nereti paliek ar iepriekšējo virsrakstu, novecojušu fragmentu, nepareizu attēlu vai saiti uz neaktuālu apakšsadaļu. Tas neizskatās pēc tehniskas kļūmes, taču tieši tā tiek sabojāta uzticība saturam un sajaukta meklēšanas loģika.

Rīkojies secīgi. Atver konkrēto publicēšanas lapu un ej caur tās pārvaldību no sākuma līdz publicēšanai. Praktiska instrukcija:

1. atver lapu un izvēlies Edit;
2. pārskati galvenes virsrakstu un pārliecinies, ka tas atbilst jaunajai sadaļas nosaukumu loģikai;
3. pārbaudi tīmekļa daļas un saites uz dokumentiem, jo pēc arhitektūras maiņas tās bieži ved uz veciem apakšceļiem;
4. atver Page details un salīdzini metadatus ar jaunās struktūras nosaukumiem;
5. izmanto Save as draft, lai pārbaudītu, kā lapa izskatās pirms publicēšanas;
6. beigās izvēlies Publish tikai tad, kad saturs, navigācija un lapas saites sakrīt ar jauno struktūru.

Biežākā kļūme katrā solī ir tāda, ka redaktors labojumus izdara tikai vizuāli. Virsraksts tiek nomainīts, bet tīmekļa daļa joprojām rāda vecu apakšsadaļu; saite tiek atjaunota, bet lapas detaļās paliek veca kategorija; publicēšana notiek, bet melnraksta pārbaude nav veikta. Šādā situācijā SharePoint SEO cieš tāpēc, ka saturs izskatās “daļēji pareizs” un meklēšana, kā arī lietotāju uzvedība sāk dalīties starp veco un jauno struktūru. Kad šī pārskatīšana ir izdarīta rūpīgi, publicēšanas slānis sāk atbalstīt jauno informācijas arhitektūru, nevis to sabotēt. Nākamajā sadaļā jau būtu jāsalāgo meklēšanas optimizācija ar vietnes navigāciju un satura metadatiem.

4. kļūda: metadati ir pārkopēti, bet nav pielāgoti jaunajai meklēšanas loģikai

Pēc migrācijas metadati bieži tiek pārcelti kopā ar saturu, bet paliek piesaistīti vecajai struktūrai: kolonnas saglabā nosaukumus, taču vairs neatspoguļo to, kā lietotāji faktiski meklē jaunajā vidē. SharePoint SEO šeit cieš tāpēc, ka meklēšana balstās ne tikai uz faila nosaukumu, bet arī uz to, kā dokumenti ir aprakstīti, filtrēti un grupēti. Ja pēc migrācijas turpina lietot vecos terminu kopumus, rezultātos parādās saturs, kas ir tehniski pareizs, bet biznesam grūti atrodams.

Ikdienā tas izpaužas ļoti konkrēti: komanda meklē “līgums”, bet bibliotēkā dokumenti ir marķēti ar iekšēju projekta kodu; lietotājs atver filtru paneli, bet redz novecojušas vērtības no vecās informācijas arhitektūras; īpašnieks uzskata, ka saturs ir sakārtots, jo kolonnas eksistē, bet reāli tās vairs nepalīdz atrast aktuālos dokumentus. Šo kļūdu neizlabo ar masveida pārdēvēšanu vien, jo problēma ir semantikā, nevis tikai tehniskā migrācijā.

Praktiskais risinājums sākas ar bibliotēkas satura pārskatīšanu un kolonu pielāgošanu jaunajam meklēšanas modelim. SharePoint Online vidē atver konkrēto bibliotēku un pārbaudi, vai izmantotās kolonnas tiešām atbilst biznesa valodai, nevis vecai sistēmai.

1. Atver Document Library → Settings → Library settings.
2. Pārskati Columns sadaļu un noņem lauku nosaukumus, kas vairs neatbilst lietotāju terminoloģijai.
3. Pielāgo skatus sadaļā Views, lai svarīgākās kolonnas būtu priekšplānā.
4. Ja saturs tiek filtrēts pēc terminu kopām, pārbaudi, vai tās sakrīt ar aktuālajiem procesa nosaukumiem un nevis ar migrācijas laikā mantotu klasifikāciju.
5. Atver meklēšanu vietnes līmenī un testē ar konkrētiem biznesa terminiem, nevis tikai ar failu nosaukumiem.

Rezultātā meklēšana sāk dot saturu pēc jēgas, nevis pēc nejauši mantota marķējuma. Lietotājs ātrāk atrod pareizo dokumentu, jo metadati palīdz filtrēt saturu pēc faktiskā darba procesa. Tieši šeit SharePoint SEO iegūst praktisku vērtību: saturs kļūst saprotams gan cilvēkam, gan meklēšanas mehānismam. Kad metadati ir sakārtoti, nākamā problēma parasti parādās navigācijā, kur vecās saites turpina vest uz nepareizām sadaļām.

5. kļūda: navigācija ved uz vecām sadaļām un rada dubultu indeksāciju

Praksē šī kļūda visbiežāk parādās pēc satura reorganizācijas, kad vietnes navigācijā vēl paliek gan jaunā, gan vecā struktūra. Lietotājs no sākumlapas atver vienu un to pašu saturu pa diviem ceļiem, un meklēšanas skatā rodas divi ceļi uz identisku lapu vai dokumentu. SharePoint SEO šādos gadījumos cieš nevis tāpēc, ka saturs pazūd, bet tāpēc, ka platforma sāk signālus sadalīt starp dublētām navigācijas takām.

Tipisks scenārijs: migrācijas laikā tiek izveidota jauna nodaļas vietne, bet klasiskā navigācija vēl norāda uz veco apakšvietni. Rezultātā darbinieks redz vienu saturu vietnes izvēlnē, citu saturu meklēšanā un vēl citus rezultātus no vecās lapas, kas joprojām eksistē kā novecojis atspulgs. Problēma nav tikai estētiska; tā rada situāciju, kur saturs tiek uztverts kā nesakārtots, pat ja dokumenti ir pareizi saglabāti.

Ko izdara pārvaldībā: vispirms notīra vietnes navigāciju un tikai pēc tam pārbauda, kuras lapas drīkst palikt pieejamas. SharePoint Online vidē to dara Site contents un vietnes iestatījumu līmenī, nevis tikai vizuāli pārvietojot izvēlnes saites.

• Atver vietni un dodies uz Settings → Change the look → Navigation, ja vietnei lieto rediģējamu navigāciju.
• Pārbaudi visas saites uz vecām sadaļām un aizstāj tās ar jaunajām lapām vai bibliotēkām.
• Ja vecā vietne vairs nav vajadzīga, pieņem lēmumu par tās slēgšanu vai novirzīšanu, lai lietotājs neredz paralēlas navigācijas takas.
• Pārskati arī kreisās puses navigāciju vietnēs, kur tā tiek izmantota kā primārais informācijas ceļš.
• Testē no dažādiem ieejas punktiem: sākumlapa, meklēšana un dziļāka projekta sadaļa.

Rezultātā lietotājs nonāk vienā pareizā vietā, nevis starp vairākām versijām ar vienu un to pašu informāciju. Meklēšanas indekss saņem skaidrāku signālu, jo vietnes struktūra vairs nekonkurē pati ar sevi. Kad navigācija ir sakārtota, uzmanība jāpārvieto uz saturu, kas joprojām izmanto novecojušo SharePoint telpu pieeju.

6. kļūda: 3D saturs joprojām balstās uz novecojušu SharePoint telpu pieeju [1]

Šī kļūda parādās tad, kad organizācija turpina uzturēt 3D saturu uz SharePoint telpu pamata, lai gan šis līdzeklis ir atzīts par novecojušu, sākot ar 2025. gada martu [1]. Problēma nav tikai tehnoloģiskā izvēle; tā ir arī satura pieejamības un uzturēšanas problēma. Ja 3D materiāls ir piesiets pie novecojuša formāta vai pieejas, migrācija to nepārvērš par mūsdienīgu pieredzi. SharePoint SEO kontekstā tas nozīmē, ka saturs var eksistēt, bet lietotājs to nesasniedz vienkāršā un stabilā veidā.

Cēlonis parasti ir tas, ka 3D lapas vai telpas tiek uztvertas kā “vienkārši vizuāls papildinājums”, nevis kā atsevišķa publicēšanas sistēma ar savām prasībām. Microsoft iesaka izpētīt Microsoft Mesh, lai iegūtu jaunu tīrskata 3D saturu pakalpojumā M365 [1]. Ja organizācija migrācijas laikā tikai pārvieto saites, bet neizvērtē, kāds formāts un kāda platforma to saturu turpmāk uzturēs, rezultāts ir novecojis resurss, kas turpina dzīvot blakus jaunajai informācijas arhitektūrai.

Risinājuma soļi sākas ar satura inventarizāciju un beidzas ar tehnisku pārorientēšanu. Ja 3D objekti tiešām ir nepieciešami, Microsoft dokumentācija norāda uz GLB un GLTF formāta 3D modeļiem, kad vien iespējams [1].

1. Pārskati visas vietnes, kurās izmanto 3D saturu vai telpu tipa pieredzi.
2. Identificē, kurš saturs ir tikai informatīvs un kurš joprojām ir darba process.
3. Ja saturs ir jāsaglabā 3D formā, sagatavo to GLB vai GLTF formātā, kad tas ir piemērots [1].
4. Izvērtē pāreju uz Microsoft Mesh, ja saturs ir daļa no jaunākas M365 pieredzes [1].
5. Pārbaudi, vai saites uz 3D resursiem nav iestrādātas vecās lapās, kuras lietotājs vairs neredz.

Pārbaude praksē notiek vienkārši: atver attiecīgo lapu vai pieredzi no tipiska lietotāja profila, pārliecinies, ka resurss ielādējas, un pārbaudi, vai tas nav atkarīgs no novecojuša telpas komponenta. Ja saturs atveras tikai šaurā, sen uzturētā ceļā, tas jāplāno pārbūvei, nevis jāatstāj “vēl vienam mēnesim”. Kad 3D saturs ir pārnests uz atbilstošu pieeju, nākamais risks parādās pavisam ikdienišķi — dokumentu bibliotēku nosaukumos un ceļos.

7. kļūda: netiek sakārtotas dokumentu bibliotēku nosaukumu un ceļu prasības

Tipiska kļūda pēc migrācijas ir tā, ka bibliotēku nosaukumi un mapju ceļi tiek atstāti “tā, kā tie atnāca no vecās sistēmas”. Sākumā tas izskatās nekaitīgi, jo dokumenti ir redzami un šķietami sakārtoti. Taču tieši šajā brīdī sākas problēmas ar atvēršanu pārlūkā, saites ģenerēšanu un meklēšanas uztveri. Noteiktu speciālo rakstzīmju izmantošana mapju vai failu nosaukumos var izraisīt nepareizu failu ielādi tīmekļa pārlūkprogrammās [1], tāpēc migrācijas pēdējā posmā šis nav dekoratīvs jautājums, bet tehnisks risks.

Kāpēc tas notiek? Tāpēc, ka vecajās failu sistēmās nosaukumu disciplīna bieži bija mīkstāka, savukārt SharePoint vidē faila ceļš, bibliotēkas nosaukums un mapes struktūra ietekmē to, kā saturs tiek atvērts un uztverts pārlūkā. Microsoft dokumentācija norāda, ka vislabāk failu nosaukumos un mapju ceļos izmantot tikai lielos burtus, mazos burtus vai ciparus [1]. Tas nav stila ieteikums; tā ir drošāka forma stabilai piekļuvei pēc migrācijas.

Pareizā konfigurācija sākas ar tīrīšanu bibliotēkas līmenī un beidzas ar vienotu nosaukumu politiku visā vietnē.

• Atver attiecīgo bibliotēku un pārskati mapju koku no augšas līdz apakšai.
• Pārsauc mapes un failus, kuros ir speciālās rakstzīmes, lieki atstarpju veidi vai nestandarta simboli.
• Vienojies par vienotu nosaukumu principu: lielie burti, mazie burti vai cipari [1].
• Pārbaudi, vai bibliotēku nosaukumi neietver terminu variantus, kas rada sajukumu starp lietotāju un meklēšanu.
• Testē failu atvēršanu pārlūkā un pārliecinies, ka saites ģenerējas bez kļūdām.

Ja šo neizlabo, sekas parādās ikdienā: lietotājs atver dokumentu un saņem nekorektu ielādi, nodaļa sāk glabāt vienu un to pašu failu vairākās versijās, bet atbalsta komanda tērē laiku, meklējot, kurš ceļš tieši salūzis. Kad bibliotēku nosaukumi un ceļi ir sakārtoti, SharePoint SEO ieguvums kļūst redzams ātri: dokumenti atveras paredzami, meklēšana nezaudē signālu, un saturs beidzot darbojas kā viena sistēma, nevis kā migrētu mapju kolekcija.

Kā pārbaudīt SharePoint SEO pēc migrācijas: administratorsa īsā pārbaudes secība

Pēc migrācijas SharePoint SEO pārbaudi veic divos līmeņos: pirmkārt, pārbaudi, vai saturs vispār ir sasniedzams ar jaunajām adresēm; otrkārt, pārbaudi, vai meklēšana, navigācija un publicēšanas lapas rāda vienu un to pašu struktūru. Ja šos divus līmeņus sajauc, administrators redz tikai “pārceltus failus”, bet lietotājs turpina atdurties pret vecām saitēm, tukšām lapām vai nesaskaņotu navigāciju.

Praktiska īsā secība sākas vietnes līmenī. Atver Site contents un pārskati, kuras dokumentu bibliotēkas un lapu bibliotēkas pēc migrācijas joprojām izmanto vecos nosaukumus vai veco informācijas arhitektūru. Tad pārej uz Site pages un atver galvenās publicēšanas lapas, lai pārbaudītu virsrakstus, navigācijas komponentes un saites uz saistītajām lapām. Tālāk atver Document Library → Settings → Versioning settings tajās bibliotēkās, kur dokumentu aktualizēšana notiek bieži, jo versiju uzvedība pēc migrācijas ietekmē to, ko lietotājs redz kā “jaunāko” saturu. Ja vietnē ir meklēšanas fokusētas lapas, pārbaudi, vai tajās izmantotie saistītie dokumenti un metadati ved uz pareizajām vienībām, nevis uz vecām mapēm.

Administratorsa īsā pārbaude darbojas labāk nekā vienkārša vizuāla caurskate, jo tā piespiež pārbaudīt saistību starp URL, bibliotēku, navigāciju un lapas saturu. Kad šī saite ir sakārtota, meklēšana sāk atrast pareizo objektu pēc satura un struktūras, nevis pēc mantojuma no vecās vietnes. Tas ir pamats turpmākajai SharePoint SEO diagnostikai, un nākamais solis ir salīdzināt, kur tieši migrācija ir atstājusi vecos nosaukumus, metadatus un navigācijas ceļus.

Lai šo pārbaudi veiktu precīzi, administrators izmanto divas pieejas: ātro vietnes inventarizāciju un mērķētu lapu un bibliotēku analīzi. Ātrā inventarizācija der situācijās, kad jāpārskata viss apjoms un jāsaprot, kuras vietnes daļas skar migrācija. Mērķētā analīze der tad, ja jau ir zināms, ka problēma ir konkrētā sadaļā, piemēram, publicēšanas lapās vai dokumentu bibliotēkā. Es ieteiktu sākt ar inventarizāciju, pēc tam pāriet uz mērķēto analīzi, jo tieši šādā secībā ātrāk atklājas vietas, kur SharePoint SEO pēc migrācijas sabrūk nevis satura trūkuma, bet strukturālas nesakritības dēļ.

Rezultātā lietotājs nonāk līdz saturam pa jaunām saitēm, vietnes navigācija neved uz pagātnes struktūru, un administrators redz, kurā posmā jālabo pāradresācijas, lapas vai bibliotēkas iestatījumi. Tālāk loģiski pāriet uz konkrētajiem migrācijas defektiem, sākot ar iemesliem, kāpēc meklēšana vai ielāde izgāžas tieši nosaukumu un ceļu dēļ.

Avoti

Kā KSJ var palīdzēt