વેબ ઍપ્લિકેશન માટે ટેકનિકલ SEO: રૅન્કિંગ ખરેખર શું બદલે છે

જ્યારે કોઈ વેબ ઍપ્લિકેશન રૅન્ક થતી નથી, ત્યારે કારણ ભાગ્યે જ કન્ટેન્ટ હોય છે. કારણ એ હોય છે કે ક્રોલરને ખાલી પાનું મળ્યું, કે એક જ વસ્તુ ધરાવતાં ચાર URL મળ્યાં, કે તેણે પોતાનું ક્રોલ ભથ્થું ફેસેટેડ ફિલ્ટર સંયોજનો પર વાપરી નાખ્યું, કે કોઈ ભટકેલી સૂચનાએ તેને પાનું ઇન્ડેક્સ જ ન કરવા કહ્યું. આમાંનું કશું કીવર્ડ રિપોર્ટમાં દેખાતું નથી, અને આ બધાં માટે એવી વ્યક્તિ જોઈએ જે કોડ બદલી શકે.

ક્રોલરને ખરેખર શું મળે છે ત્યાંથી શરૂ કરો

ટેકનિકલ SEO ની સૌથી ઉપયોગી ટેવ છે બ્રાઉઝરમાં પાનું જોવાનું બંધ કરવું. સર્વર જે કાચું HTML પાછું આપે છે તે લાવો અને એ જ વાંચો. તે નિયમિતપણે તમે જે જુઓ છો તેનાથી અલગ દસ્તાવેજ હોય છે.

ક્લાયન્ટ-રેન્ડર્ડ ઍપ્લિકેશન માટે એ સ્ક્રિપ્ટ ટૅગ સાથેનું ખાલી માળખું હોઈ શકે. Google JavaScript રેન્ડર કરે તો છે, પણ રેન્ડરિંગ ક્રોલિંગથી અલગ કતારમાં થાય છે અને તેના તાત્કાલિક કે પૂર્ણ હોવાની ખાતરી નથી — અને બીજા ક્રોલર, જેમાં સોશિયલ પ્રીવ્યૂ અને કેટલીક AI સિસ્ટમ પાછળનાં પણ છે, ઘણા ઓછા ભરોસે કે બિલકુલ રેન્ડર કરતા નથી.

ઉકેલ એ છે કે જે પણ પાનાને રૅન્ક કરાવવું છે તેનું કન્ટેન્ટ શરૂઆતના HTML માં પીરસાય. સર્વર-સાઇડ રેન્ડરિંગ, સ્ટૅટિક જનરેશન કે પ્રીરેન્ડરિંગ બધાં આ સાધે છે; કયું પસંદ કરવું તે આર્કિટેક્ચરનો નિર્ણય છે, પણ જો સર્ચ મહત્ત્વની હોય તો આ જરૂરિયાત વાટાઘાટ યોગ્ય નથી.

ડુપ્લિકેટ URL ચૂપચાપ બધું બગાડે છે

ઍપ્લિકેશન વગર મહેનતે URL ના રૂપાંતરો બનાવતી રહે છે: ટ્રૅકિંગ પૅરામીટર, સેશન ઓળખકર્તા, સૉર્ટ અને ફિલ્ટર સંયોજનો, ટ્રેલિંગ-સ્લૅશ રૂપાંતરો, મોટા અક્ષરોવાળા પાથ, અને એ જ પાનું બે રસ્તે પહોંચમાં. ક્રોલર માટે દરેક રૂપાંતર અલગ URL છે, અને રૅન્કિંગ સંકેતો તેમાં વહેંચાઈ જાય છે.

ત્રણ બાબતો આનો ઉકેલ લાવે છે. દરેક પાનાને પોતાની તરફ ઇશારો કરતું કૅનોનિકલ જોઈએ જે એ જ સંસ્કરણ તરફ હોય જેને તમે ઇન્ડેક્સ કરાવવા માગો છો. સર્વરે રૂપાંતરો — બિન-કૅનોનિકલ હોસ્ટ, ખોટો પ્રોટોકોલ, અસંગત ટ્રેલિંગ સ્લૅશ — કાયમી રીડાયરેક્ટથી મોકલવાં જોઈએ, બધાં પીરસવાં નહીં. અને જે પૅરામીટર કન્ટેન્ટ બદલતા નથી તેમણે અલગ ઇન્ડેક્સ યોગ્ય URL ન બનાવવું જોઈએ.

અહીં સૌથી સામાન્ય ભૂલ છે એવું કૅનોનિકલ જે સાઇટમૅપ સાથે અસંમત હોય, કે એવું કૅનોનિકલ જે રીડાયરેક્ટ થતા URL તરફ ઇશારો કરે. બંનેને ગૂંચવાયેલા સંકેત ગણવામાં આવે છે, અને ગૂંચવણનો નિવેડો તમારી વિરુદ્ધ આવે છે.

ફિલ્ટર આવતાં જ ક્રોલ બજેટ ખરી સમસ્યા બને છે

પચાસ પાનાંની સાઇટ માટે ક્રોલ બજેટ તમારી સમસ્યા નથી. ફેસેટેડ નેવિગેશન ધરાવતી ઍપ્લિકેશન માટે એ પહેલી સમસ્યાઓમાં છે, કારણ કે મુઠ્ઠીભર ફિલ્ટર URL નો સંયોજનાત્મક વિસ્ફોટ પેદા કરે છે અને ક્રોલર મહત્ત્વનાં પાનાંને બદલે અઠવાડિયાં તેમના પર ખુશીથી વાપરી નાખશે.

સ્પષ્ટપણે નક્કી કરો કે કયાં ફિલ્ટર સંયોજનો ઇન્ડેક્સ થવા લાયક છે — સામાન્ય રીતે એ જેમાં ખરી સર્ચ માગ છે, જેમ કે એક શ્રેણી અને એક લક્ષણ — અને બાકીનાને ઇન્ડેક્સ-અયોગ્ય બનાવો. જે પૅરામીટર પૅટર્નનું કોઈ મૂલ્ય નથી તેમનું ક્રોલિંગ robots.txt થી રોકો, અને એ પાનાં માટે noindex સૂચના રાખો જેમણે તેમની લિંક માટે ક્રોલ થવા યોગ્ય રહેવું છે પણ પરિણામોમાં ન આવવું જોઈએ.

આ બંને એકબીજાની જગ્યાએ વાપરી શકાય નહીં, અને તેમને ભેળવી દેવું સામાન્ય છે: robots.txt માં રોકાયેલું પાનું ક્રોલ થઈ શકતું નથી, તેથી તેનું noindex ક્યારેય જોવાતું નથી, અને URL માત્ર બાહ્ય સંકેતો પર પરિણામોમાં તોય દેખાઈ શકે છે. જો કોઈ પાનું ઇન્ડેક્સની બહાર રાખવું હોય, તો તે ક્રોલ થવા યોગ્ય હોવું જોઈએ અને તેના પર noindex હોવું જોઈએ.

Core Web Vitals, વાસ્તવિક વપરાશમાં માપેલા

પરફોર્મન્સ એક રૅન્કિંગ પરિબળ છે, અને તેથીય વધુ તે કન્વર્ઝન પરિબળ છે. ભૂલ એ છે કે ઝડપી મશીન પર લૅબ સ્કોર સામે ઑપ્ટિમાઇઝ કરવું, નહીં કે વાસ્તવિક વપરાશકર્તાઓ જેનો અનુભવ કરે છે તેની સામે.

Largest Contentful Paint માટે સામાન્ય દોષિતો છે એ છબી જે પ્રીલોડ નથી, એ ફોન્ટ જે ટેક્સ્ટને દેખાતાં રોકે છે, અને રેન્ડર-બ્લૉક કરતી સ્ટાઇલશીટ. જે તત્ત્વ સૌથી મોટું હશે તેને પ્રીલોડ કરો, font-display વાપરો જેથી ટેક્સ્ટ ફૉલબૅકમાં તરત દેખાય, અને પહેલી સ્ક્રીન માટે જરૂરી સ્ટાઇલ ઇનલાઇન રાખો.

Cumulative Layout Shift લગભગ હંમેશાં પરિમાણ વગરની છબીઓ અને એમ્બેડથી, હાલના કન્ટેન્ટ ઉપર નાખેલા કન્ટેન્ટથી, અને સ્વૅપ પર ફરી વહેતા વેબ ફોન્ટથી આવે છે. સ્પષ્ટ પહોળાઈ-ઊંચાઈ નક્કી કરો, મોડેથી આવતી દરેક વસ્તુ માટે જગ્યા રાખો, અને ફૉલબૅક ફોન્ટનાં માપ મેળવો.

Interaction to Next Paint એ છે જેમાં ઍપ્લિકેશન સૌથી વધુ નિષ્ફળ જાય છે, કારણ કે તે ભારે JavaScript મેઇન થ્રેડ નીચે પ્રતિસાદશીલતા માપે છે. લાંબાં કાર્યો તોડો, મેઇન થ્રેડ પર ઓછું કામ કરો, અને પ્રામાણિકપણે જુઓ કે જે પાનાનું કામ માહિતી બતાવવાનું છે તેના પર ખરેખર કેટલું ફ્રેમવર્ક જોઈએ.

સ્ટ્રક્ચર્ડ ડેટા જે પરસ્પર મેળ ખાય

સ્ટ્રક્ચર્ડ ડેટા સીધું રૅન્કિંગ વધારતું નથી, પણ તે નક્કી કરે છે કે પરિણામ કેવી રીતે બતાવાય અને સર્ચ એન્જિન કેટલા ભરોસે સમજે કે તમારી સાઇટ શેના વિશે છે. સામાન્ય નિષ્ફળતા અમાન્ય માર્કઅપ નથી — એ એવું માર્કઅપ છે જે પાનાંઓમાં પોતાની સાથે વિરોધાભાસ કરે, એક જ સંસ્થાને ત્રણ જુદી રીતે વર્ણવે.

એક ઓળખાયેલા સંસ્થા નોડનો ઉપયોગ કરો અને બાકીના દરેક બ્લૉકને તેનો સંદર્ભ અપાવો, દરેક પાના પર કંપની ફરી જણાવવાને બદલે. ક્યારેક કોઈ ટેસ્ટિંગ ટૂલમાં પેસ્ટ કરવાને બદલે બિલ્ડમાં જ ચકાસો, જેથી ખામી ચૂપચાપ જવાને બદલે બિલ્ડ નિષ્ફળ કરે.

એવી સમીક્ષાઓ માર્કઅપ ન કરો જે તમે લીધી નથી, એવાં રેટિંગ જે તમે શૂન્યમાંથી ભેગાં કર્યાં છે, કે એવા FAQ જે પાના પર દેખાતા જ નથી. આ મેન્યુઅલ ઍક્શનને આમંત્રે છે, અને રિચ રિઝલ્ટ એ જોખમને લાયક નથી.

ઇન્ટરનેશનલાઇઝેશન, જ્યાં સામાન્ય રીતે ભૂલ થાય છે

જો તમે અનેક ભાષાઓ પીરસો છો, તો hreflang સર્ચ એન્જિનને જણાવે છે કે કયું સંસ્કરણ બતાવવું. એમાં સૂક્ષ્મ ભૂલ થવી પણ સૌથી સહેલી છે.

• એનોટેશન પરસ્પર હોવાં જોઈએ. જો અંગ્રેજી પાનું જર્મન તરફ ઇશારો કરે, તો જર્મન પાનાએ પાછું ઇશારો કરવો જ પડે, નહીંતર આખો સેટ અવગણાય છે.
• સેટનો દરેક URL 200 પાછું આપવું જોઈએ. ક્લસ્ટરમાં એક પણ 404 આખી વ્યવસ્થા નબળી પાડે છે.
• દરેક પાનાનું કૅનોનિકલ પોતાની જ તરફ ઇશારો કરવું જોઈએ, અંગ્રેજી સંસ્કરણ તરફ નહીં. બીજી ભાષા તરફનું કૅનોનિકલ એ પાનાને ઇન્ડેક્સમાંથી કાઢવાની વિનંતી છે.
• કોઈ ભાષા મેળ ન ખાય ત્યારે ફૉલબૅક માટે x-default વાપરો.
• કોઈ પાનાનું મશીન અનુવાદ કરીને તેને ભાષા વિકલ્પ તરીકે ચિહ્નિત ન કરો, સિવાય કે તે ખરેખર સારું હોય. પાતળો કે બગડેલો અનુવાદ એ ભાષા બિલકુલ ન આપવા કરતાં પણ ખરાબ છે.

એવું માપન જે પ્રાઇવસી-પ્રધાન વેબમાં ટકે

મુલાકાતીઓનો મોટો હિસ્સો ક્લાયન્ટ-સાઇડ ઍનાલિટિક્સ રોકે છે, અને આ હિસ્સો તકનીકી પ્રેક્ષકોમાં સૌથી વધુ છે — જે કોઈ સૉફ્ટવેર ઉત્પાદન માટે એ જ પ્રેક્ષક છે જેમને તમે સૌથી વધુ સમજવા માગો છો. રોકાયેલા ટૅગમાંથી મળેલા આંકડા માત્ર અધૂરા નથી, તે એ દિશામાં પક્ષપાતી છે જે મહત્ત્વની છે.

સર્વર લૉગ અને સર્વર-સાઇડ માપનમાં આ સમસ્યા નથી, અને તે તમને ક્રોલરનું વર્તન પણ બતાવે છે, જે ક્લાયન્ટ-સાઇડ ઍનાલિટિક્સ ક્યારેય નહીં બતાવે. નવી સાઇટ માટે, લૉગમાં Googlebot ને આવતું જોવું કોઈપણ ડૅશબોર્ડ કરતાં વધુ ઉપયોગી સંકેત છે — તે જણાવે છે કે તમારી સમસ્યા ક્રોલિંગની છે કે રૅન્કિંગની, અને બંને ખૂબ જુદી રીતે સુધરે છે.

Search Console સૌથી મૂલ્યવાન સ્રોત રહે છે, કારણ કે તે એ ક્વેરી જણાવે છે જેના માટે તમે પહેલેથી દેખાઓ છો. એ ક્વેરી કોઈપણ કીવર્ડ ટૂલ કરતાં સારો કન્ટેન્ટ બ્રીફ છે, કારણ કે તે બતાવે છે કે તમે ક્યાં એટલા નજીક છો કે નાનો સુધારો પરિણામ બદલી નાખશે.

કામનો એક વ્યવહારુ ક્રમ

1. પહેલાં ઇન્ડેક્સેબિલિટી ચકાસોSearch Console, કવરેજ રિપોર્ટ, અને તમારી જ સાઇટનો એક ક્રોલ. એવા પાનાને ઑપ્ટિમાઇઝ કરવાનો કોઈ અર્થ નથી જે બહાર જ રખાયું છે.
2. રેન્ડરિંગ સુધારોખાતરી કરો કે જે કન્ટેન્ટ રૅન્ક કરાવવું છે તે શરૂઆતના HTML પ્રતિસાદમાં હોય.
3. ડુપ્લિકેટ ઉકેલોકૅનોનિકલ, રીડાયરેક્ટ અને પૅરામીટર હૅન્ડલિંગ, જેથી સંકેતો વહેંચાવાને બદલે એક જગ્યાએ કેન્દ્રિત થાય.
4. ક્રોલ નિયંત્રિત કરોનક્કી કરો કે કયા જનરેટ થયેલા URL ઇન્ડેક્સિંગને લાયક છે અને બાકીનાને ક્રોલ ભથ્થું વાપરતા અટકાવો.
5. પછી પરફોર્મન્સફીલ્ડ ડેટા, લૅબ સ્કોર નહીં, અને બિલ્ડ પાઇપલાઇનમાં નક્કી કરેલું જેથી તે ફરી બગડી ન શકે.
6. પછી કન્ટેન્ટએ ક્વેરી માટે લખાયેલું જેના પર Search Console બતાવે છે કે તમે પહેલેથી નજીક છો.

આ ક્રમ મહત્ત્વનો છે. જે પાનું ક્રોલર જોઈ જ ન શકે તેના માટે લખાયેલું કન્ટેન્ટ વેડફાયેલી મહેનત છે, અને ઇન્ડેક્સમાંથી બહાર રખાયેલા પાના પર પરફોર્મન્સ ટ્યુનિંગથી કશું જ બદલાતું નથી.