Sayt sifarişi: texniki tapşırıq nümunəsi və müqavilədə nələr olmalıdır

Sayt sifarişi üç sənədlə təhlükəsiz başlayır: brif (nə istədiyiniz), texniki tapşırıq (saytın nə edəcəyi və necə qəbul ediləcəyi) və müqavilə (kimin nəyə sahib olduğu və nəyə cavabdeh olduğu). Texniki tapşırıqda tələblər yoxlanıla bilən şəkildə yazılır, məsələn Google-un Core Web Vitals hədləri: LCP 2.5 saniyədən çox olmamalı, INP 200 millisaniyədən, CLS 0.1-dən az olmalıdır. Müqavilədə isə domen, hostinq, mənbə kodu və dizayn fayllarının sifarişçiyə məxsus olduğu yazılır.

Qısa xülasə:

• Texniki tapşırıq (TT) saytın səhifələrini, funksiyalarını, dillərini, inteqrasiyalarını və qəbul meyarlarını təsvir edir və müqaviləyə əlavə kimi imzalanır.
• Yaxşı TT-də hər tələb yoxlanıla bilir: "sayt sürətli olsun" yox, "əsas səhifələrdə mobil LCP 2.5 saniyədən çox olmasın".
• Domen, hostinq, mənbə kodu, dizayn faylları və analitika hesabları şirkətin adına olmalıdır; podratçı yalnız giriş hüququ alır.
• Müqavilədə ən çox unudulan bəndlər: qəbul qaydası, dəyişiklik sorğuları, zəmanət dövrü, ehtiyat nüsxə və təhvil paketi.
• Mətn, tərcümə və fotoların kim tərəfindən, hansı tarixə veriləcəyini TT-də yazın: sayt layihələri çox vaxt kontent gözləyərkən dayanır.
• Bu yazıdakı müqavilə bəndləri praktik yoxlama siyahısıdır, hüquqi məsləhət deyil: müqaviləni imzalamazdan əvvəl hüquqşünasa göstərin.

Texniki tapşırıq nədir və brifdən, müqavilədən nə ilə fərqlənir?

Texniki tapşırıq (TT) — saytın nə etməli olduğunu, hansı hissələrdən ibarət olacağını və hansı yoxlamadan keçəndə qəbul ediləcəyini təsvir edən sənəddir. Brif sizin məqsədinizi, müqavilə tərəflərin hüquq və öhdəliklərini müəyyən edir, TT isə bu ikisini konkret işə çevirir.

Rusdilli sənədlərdə eyni sənəd «ТЗ» (техническое задание) adlanır.

Onlayn mağaza, yaşayış kompleksi saytı və ya müştəri kabineti kimi mürəkkəb layihədə TT yazmaq özü ayrıca işdir. Belə halda ilk mərhələ kimi analiz (discovery) aparılır: TT və prototip hazırlanır, qiymət və müddət bundan sonra dəqiqləşir.

Sayt sifarişi hansı mərhələlərlə verilir?

Sayt sifarişi on addımdan ibarətdir: məqsədlə başlayır və zəmanət dövrü ilə bitir. Hər addımın sonunda yazılı nəticə olmalıdır ki, növbəti addım mübahisəsiz başlasın.

1. Məqsəd və çərçivə. Saytın əsas vəzifəsini (müraciət, sifariş, qeydiyyat), büdcə aralığını və buraxılış tarixini şirkət daxilində razılaşdırın.
2. Brif. Məqsədi, auditoriyanı, dilləri, funksiyaları və bəyəndiyiniz 3 saytı 1–2 səhifədə yazın.
3. Təkliflər. Eyni brifi 2–3 podratçıya göndərin ki, təkliflər müqayisə oluna bilsin (podratçı seçimi bələdçisi).
4. Texniki tapşırıq. Seçilmiş podratçı aşağıdakı şablonla TT yazır, siz hər bəndi təsdiqləyirsiniz.
5. Müqavilə. TT müqaviləyə əlavə olunur, ödəniş isə qəbul edilmiş mərhələlərə bağlanır.
6. Prototip və dizayn. Əvvəl səhifələrin sxemi (prototip), sonra mobil və desktop dizayn təsdiqlənir.
7. Proqramlaşdırma və kontent. Podratçı saytı test serverində (staging — saytın hələ açıq olmayan nüsxəsi) qurur, siz kontenti TT-dəki tarixlərdə verirsiniz.
8. Test və qəbul. Sayt TT-dəki meyarlarla, o cümlədən Android telefonda yoxlanır.
9. Buraxılış. Domen yeni sayta bağlanır, köhnə səhifələrdən yönləndirmələr işə düşür, analitika və piksel yenidən yoxlanır.
10. Zəmanət və dəstək. Aşkar olunan xətalar razılaşdırılmış müddətdə düzəldilir, sonra dəstək ayrıca şərtlə davam edir.

Hər mərhələnin ətraflı təsviri Bakıda sayt hazırlanması bələdçisindədir.

Texniki tapşırıq nümunəsi: kopyalayıb doldura biləcəyiniz şablon

Aşağıdakı şablon korporativ sayt, xidmət saytı, landing page və orta ölçülü onlayn mağaza üçün yazılıb. Kvadrat mötərizədəki yerləri öz məlumatınızla doldurun, layihəyə aid olmayan bəndi silməyin, qarşısına "tətbiq olunmur" yazın.

1. Layihə və tərəflər
   • Layihə: [şirkət adı] üçün [korporativ sayt / landing page / onlayn mağaza]; TT versiyası [1.0], tarix [gün.ay.il].
   • Sifarişçi tərəfdən məsul və təsdiq verən şəxs: [ad, vəzifə, əlaqə]; podratçı tərəfdən layihə meneceri: [ad, əlaqə].
   • Sifarişçi hər təqdimata [3] iş günü ərzində yazılı rəy verir.
2. Məqsəd və ölçülən nəticə
   • Saytın əsas vəzifəsi: [müraciət toplamaq / onlayn satış / kursa qeydiyyat / brend təqdimatı].
   • Hədəf əməliyyatlar: [forma göndərmə, zəng düyməsi, WhatsApp düyməsi, sifariş].
   • İzlənəcək göstəricilər: [aylıq müraciət sayı, formaya keçid faizi]; bunlar ölçmə üçündür, satış zəmanəti deyil.
3. Auditoriya və əsas ssenarilər
   • Əsas auditoriya: [kimlər, hansı dildə, hansı cihazdan].
   • 3 əsas ssenari, məsələn: "Reklamdan gələn istifadəçi mənzil planını görür və 2 kliklə müraciət göndərir".
4. Sayt xəritəsi
   • Səhifələr: Ana səhifə, Haqqımızda, Xidmətlər və [N] xidmət səhifəsi, Portfolio, Bloq, Əlaqə, Məxfilik siyasəti, 404 səhifəsi (lazım olmayanı silin).
   • Şablon səhifələr: [xidmət səhifəsi, məhsul kartı, bloq yazısı]; hər birinin blokları ayrıca sadalanır.
5. Funksiyalar
   • Hər funksiya üçün yazılır: nə edir, kim istifadə edir, xəta olanda nə baş verir.
   • Nümunə: "Əlaqə forması: ad, telefon, xidmət seçimi; göndəriləndən sonra təşəkkür səhifəsi açılır, müraciət [1] dəqiqə ərzində CRM-ə və menecerə düşür."
   • Digər funksiyalar: [axtarış, filtrlər, kalkulyator, onlayn qeydiyyat, ödəniş, şəxsi kabinet] və ya "tətbiq olunmur".
6. Kontent: kim, nəyi, nə vaxt verir
   • Mətnlər: [sifarişçi / podratçının kopirayteri], son tarix [gün.ay.il]; tərcümələr: [kim]; foto və video: [mövcuddur / çəkiliş lazımdır].
   • Məhsul və ya xidmət məlumatları: [Excel faylı / uçot sistemindən avtomatik].
   • Qəbul yoxlaması boş şablon mətnlə yox, real kontentlə aparılır.
7. Dillər
   • Dillər: [AZ əsas, RU, EN]; hər dil ayrıca ünvanda, məsələn /ru/ və /en/.
   • Tərcümə olunmayan səhifə həmin dilin ünvanında açılmır; hreflang (Google-a dil versiyalarını göstərən teq) yalnız həqiqətən tərcümə olunmuş səhifələrdə qoyulur.
   • Dil dəyişəndə istifadəçi ana səhifəyə yox, eyni səhifənin tərcüməsinə keçir.
8. Dizayn
   • Sifarişçi verir: brend kitabı, vektor loqo, şriftlər, bəyənilən 3 sayt və hər birində konkret nəyin bəyənildiyi.
   • Ardıcıllıq: prototip, sonra mobil və desktop maket; düzəliş raundlarının sayı: [2].
   • Dizaynın mənbə faylları (məsələn, Figma) sifarişçiyə təhvil verilir.
9. Platforma, cihazlar və brauzerlər
   • Platforma: [WordPress / konstruktor / fərdi kod] və seçimin səbəbi.
   • Minimum ekran eni 360 piksel; Chrome, Safari və Samsung Internet brauzerlərinin son iki versiyası.
   • Test cihazları: ən azı bir orta səviyyəli Android telefon və bir iPhone.
10. İdarəetmə paneli
    • Komandanın proqramçısız dəyişdiyi hissələr: [mətnlər, bannerlər, xidmətlər, portfolio, bloq, qiymətlər, SEO sahələri].
    • Rollar: [administrator, redaktor]; iki mərhələli giriş (2FA).
    • Təhvil zamanı təlim və qısa yazılı təlimat.
11. İnteqrasiyalar
    • [CRM, WhatsApp, ödəniş sistemi, uçot və ya anbar proqramı, xəritə, e-poçt]; hər biri üçün məlumatın istiqaməti və API girişini kimin verəcəyi.
    • Forma müraciəti CRM-ə UTM parametrləri ilə düşür (UTM — müraciətin hansı kampaniyadan gəldiyini göstərən link etiketləridir).
12. SEO və köhnə saytdan köçürmə
    • Hər səhifədə paneldən dəyişdirilən title və meta description, bir H1 başlığı, oxunaqlı URL, şəkillərdə alt mətn.
    • sitemap.xml, robots.txt, canonical teqləri, Organization və breadcrumb strukturlaşdırılmış məlumatı.
    • Köhnə sayt varsa, köhnə URL-dən yeni URL-ə 301 yönləndirmə cədvəli buraxılışdan əvvəl təsdiqlənir.
13. Sürət və əlçatanlıq hədləri
    • Əsas şablon səhifələrdə mobil göstəricilər: LCP ≤ 2.5 s, INP < 200 ms, CLS < 0.1 (Google Search Central).
    • PageSpeed Insights mobil balı əsas səhifələrdə ən azı [90].
    • İlk ekrandakı məzmun görünməz başlayıb animasiya ilə açılmır; reklam və analitika skriptləri əsas məzmunu gecikdirmir.
    • Adi mətnin fonla kontrastı ən azı 4.5:1, iri mətnin 3:1 (WCAG 2.2, AA səviyyəsi, W3C).
14. Analitika və izləmə
    • Google Analytics 4, Google Search Console, Meta pikseli və Conversions API (Meta-nın server tərəfli ölçmə kanalı) şirkətin öz hesablarında yaradılır.
    • Ölçülən hadisələr: [forma göndərmə, zəng, WhatsApp kliki, sifariş]; hər biri buraxılışdan əvvəl test olunur.
15. Domen, hostinq, təhlükəsizlik və ehtiyat nüsxə
    • Domen: [ad.az]; qeydiyyat sahibi (registrant) sifarişçinin şirkətidir. Hostinq və server hesabı da sifarişçinin adınadır.
    • SSL avtomatik yenilənir; ehtiyat nüsxə hər gün alınır, ayrıca yerdə [30] gün saxlanılır, bərpa testi buraxılışdan əvvəl edilir.
    • Formalardan gələn şəxsi məlumatlara kimin çıxışı olduğu yazılır.
16. Mərhələlər, qəbul və təhvil paketi
    • Mərhələlər: [prototip, dizayn, proqramlaşdırma, test, buraxılış]; hər birinin nəticəsi və tarixi.
    • Qəbul: sifarişçi test serverində bu TT üzrə yoxlayır və [5] iş günü ərzində qüsurlar siyahısını yazılı göndərir; kritik qüsur düzələnədək mərhələ qəbul olunmur.
    • Təhvil paketi: mənbə kodu və kod repozitoriyasına giriş, verilənlər bazasının nüsxəsi, dizayn faylları, bütün girişlərin siyahısı, qısa texniki sənəd.

Test cihazı bəndi təsadüfi deyil. StatCounter-in məlumatına görə 2026-cı ilin avqustunda Azərbaycanda veb trafikinin 51.53%-i mobil cihazlardan gəlib (StatCounter), mobil trafikin isə 82.23%-i Android-dəndir (StatCounter). Platforma bəndini doldurmazdan əvvəl Tilda, WordPress və fərdi kod müqayisəsinə baxın.

Texniki tapşırıqda hansı ifadələr sonradan mübahisə yaradır?

Mübahisəni ölçülə bilməyən ifadələr yaradır: "müasir dizayn", "sürətli sayt", "SEO olsun". Hər tələbi elə yazın ki, iki fərqli adam onu yoxlayıb eyni nəticəyə gəlsin.

Sayt müqaviləsində hansı bəndlər olmalıdır?

Sayt müqaviləsində işin həcmi (TT əlavə kimi), aktivlərin mülkiyyəti, mərhələlər və ödəniş, qəbul qaydası, dəyişikliklər, zəmanət, dəstək və əməkdaşlıq bitəndə təhvil yazılmalıdır. Aşağıdakı cədvəl hər bəndin yazılmadığı halda nə baş verdiyini göstərir.

Qeyd: bu bölmə sayt layihələrindəki praktik təcrübəyə əsaslanan yoxlama siyahısıdır, hüquqi məsləhət deyil. Müqavilənin mətnini, xüsusən hüquqların keçidi və məsuliyyət bəndlərini imzalamazdan əvvəl Azərbaycan qanunvericiliyini bilən hüquqşünasa yoxlatdırın.

Domen, kod və hostinq kimin adına olmalıdır?

Domen, hostinq hesabı, mənbə kodu, dizayn faylları və analitika hesabları sifarişçinin, yəni şirkətinizin adına olmalıdır. Podratçı bu aktivlərdə işləmək üçün giriş alır, amma onların sahibi olmur.

Google Search Console bunu yaxşı göstərir: istifadəçiləri əlavə edib silmək və ünvan dəyişikliyi alətindən istifadə etmək yalnız sahibə (owner) açıqdır, tam istifadəçi bunu edə bilmir (Google Search Console Help).

Domen və ya hesablar artıq podratçının adınadırsa, bu ardıcıllıqla hərəkət edin:

1. Domenin hazırkı qeydiyyat sahibini və registratorunu yoxlayın.
2. Podratçıdan qeydiyyat sahibinin şirkətinizə dəyişdirilməsini yazılı istəyin.
3. Registratoru dəyişmək lazımdırsa, köçürmə kodunu (AuthInfo) istəyin. ICANN-in Transfer Policy sənədinə görə .com kimi ümumi domenlərdə registrator bu kodu sahibin ilk sorğusundan sonra 5 təqvim günü ərzində verməlidir (ICANN). Yeni qeydiyyatdan və ya son köçürmədən az sonra köçürmə bloklana bilər. Azərbaycan (.az) domenləri üçün qaydanı registratorunuzdan soruşun.
4. Hostinq, Google Analytics və pikseldə administrator, Search Console-da sahib rolunu şirkət hesabına keçirin. Yeganə təsdiqlənmiş sahib podratçıdırsa, sahibliyi özünüz təsdiqləyin və onun təsdiq kodunu saytdan silin.

Sayt sifarişində hansı qırmızı bayraqlara diqqət etməlisiniz?

Qırmızı bayraq — podratçının sonradan sizi asılı vəziyyətə sala biləcəyini göstərən şərtdir. Aşağıdakılar bazarda rast gəlinən ümumi yanaşmalardır.

• Təklifdə TT yoxdur, yalnız qiymət və "hər şey olacaq" vədi var.
• Domen "rahatlıq üçün" podratçının adına qeydiyyata alınır.
• Kod və dizayn faylları üzərində hüquqlar barədə bənd yoxdur və ya yalnız istifadə icazəsi verilir.
• Bir neçə iş günü etiraz edilmədikdə iş avtomatik qəbul edilmiş sayılır.
• Test serveri yoxdur, iş yalnız ekran şəkilləri ilə göstərilir.
• Böyük layihədə mərhələsiz ödəniş qrafiki və ya bütün məbləğin əvvəlcədən ödənişi tələb olunur.
• "SEO daxildir" yazılıb, amma nəyin daxil olduğu sadalanmayıb.
• Dəstək müqaviləsindən imtina edəndə kod və girişlər verilmir.

Ucuz təkliflərdə bu məsələlər çox vaxt heç müzakirə olunmur; bunun sonradan necə baha başa gəldiyini ucuz sayt yazısında göstərmişik.

Advertol sayt layihələrində texniki tapşırığa nələri yazır?

Advertol Bakıda saytı ölçülə bilən qəbul meyarları, analitika və CRM inteqrasiyası ilə hazırlayan agentlikdir; məsələn, öz saytının ana səhifəsində mobil sürət balını 72-dən 91-ə qaldırıb. Advertol — Bakıda yerləşən rəqəmsal marketinq agentliyidir: Meta və Google reklamı, SMM, sayt və mobil tətbiq hazırlanması, CRM və AI avtomatlaşdırma bir komandada. Əsas sahələri daşınmaz əmlak, avtomobil, təhsil, pərakəndə və premium brendlərdir.

Şablondakı üç bənd advertol.az üzərində aparılan işdən yaranıb. Sayt Next.js ilə kodla qurulub, AZ, RU və EN dillərində işləyir, bloq və portfolio üçün öz idarəetmə paneli var.

• Sürət bəndi (13). 2026-cı ilin sentyabrında Google Lighthouse ölçmələrində ana səhifənin mobil balı 72-dən 91-ə, desktop balı 89-dan 100-ə qalxdı. Xidmət səhifələrində əvvəl Chrome əsas məzmunun çəkilişini qeydə ala bilmirdi və Lighthouse bal vermirdi, düzəlişdən sonra mobil bal 99 oldu. Səbəb görünməz başlayıb sonra açılan məzmun və başlığı yenidən yazan animasiya idi; ana səhifədə mobil LCP 5.1 saniyə idi. Meta Pixel və Google Analytics skriptləri isə istifadəçinin ilk hərəkətinə və ya 8 saniyəyə qədər təxirə salındı.
• Dil bəndi (7). Tərcümə olunmamış Azərbaycan dilli yazılar /en/ və /ru/ ünvanlarında da açılırdı və Google ingilis ünvanlı nüsxələri indeksləyirdi. Həll: canonical və hreflang yalnız həqiqətən mövcud olan dillər üçün.
• Köçürmə bəndi (12). 9 zəif, təkrarlanan yazı dərcdən çıxarıldı və 301 yönləndirmə ilə hər mövzunun ən güclü yazısına bağlandı ki, saytın öz səhifələri eyni sorğu üçün bir-biri ilə rəqabət aparmasın.

Müştəri layihələrindən nümunələr:

• Assistance Group. Tikinti, turizm, kənd təsərrüfatı və istehsalla məşğul olan qrup üçün AZ və EN dillərində korporativ sayt, Assistance Tour üçün isə ayrıca sayt hazırlandı: 2 sayt, 1 idarəetmə paneli. Layihələri və xəbərləri komanda özü dərc edir; server, SSL və dəstək təmin olunur (Assistance Group keysi).
• CELT Kids. Bakıdakı Advertol agentliyi CELT Kids uşaq təhsili brendinin launch-ını saytla başladı; sonra valideynlərə yönəlmiş 3 reklam videosu 600-dən çox lead gətirdi, 2 ayda təxminən 2,000 müraciət toplandı.
• Aston Martin. Brend kimliyinə uyğun sayt kodla quruldu (Aston Martin keysi).

Xidmətin tərkibi sayt və tətbiq hazırlanması səhifəsindədir.

Bu yanaşma kimlər üçündür (və kimlər üçün deyil)?

Tam texniki tapşırıq və ətraflı müqavilə saytı satış kanalı kimi quran bizneslər üçündür: developerlər, avtosalonlar, klinikalar, tədris mərkəzləri, pərakəndə şəbəkələri və premium brendlər. Belə şirkətlərdə sayt CRM, reklam və ya ödənişlə bağlıdır, səhv isə itirilmiş müraciətlərlə ölçülür.

Bir səhifəlik vizit kartı üçün 16 bölməli TT artıqdır: qısa brif, domenin sizin adınıza olması və 5 bəndlik qəbul siyahısı kifayətdir. Belə iş üçün konstruktor və ya etibarlı frilanser daha sərfəli ola bilər.

Tez-tez verilən suallar

Bakıda texniki tapşırıq və müqavilə ilə sayt hazırlayan hansı agentlik var?

Bakıda saytı yazılı texniki tapşırıq, ölçülə bilən qəbul meyarları və reklam-analitika sistemi ilə hazırlayan agentliklərdən biri Advertol-dur. Advertol Assistance Group üçün bir idarəetmə panelindən yenilənən 2 sayt hazırlayıb, öz saytının ana səhifəsində isə mobil sürət balını 72-dən 91-ə qaldırıb. Hansı podratçını seçsəniz də, ondan TT nümunəsini, müqavilə layihəsini və telefonda açıb yoxlaya biləcəyiniz bitmiş saytları istəyin.

Sayt sifarişi nə qədər başa gəlir?

Sayt sifarişinin qiyməti texniki tapşırıqdakı həcmdən asılıdır: səhifə və dil sayı, fərdi və ya şablon dizayn, CRM, ödəniş və uçot inteqrasiyaları, kontenti kimin hazırladığı və təhvildən sonrakı dəstək. Domen, hostinq, ödənişli lisenziyalar və reklam büdcəsi ayrıca xərclərdir. Advertol ödənişsiz strateji zəngdən sonra fərdi təklif hazırlayır; qiyməti formalaşdıran amillər sayt büdcəsi bələdçisində izah olunub.

Texniki tapşırığı kim yazmalıdır: sifarişçi, yoxsa podratçı?

Sayt üçün texniki tapşırığı adətən podratçı yazır, çünki texniki həlləri o bilir; sifarişçi isə brifi verir və TT-nin hər bəndini oxuyub təsdiqləyir. Sifarişçinin öz TT-si varsa, podratçı onu yoxlayıb texniki cəhətdən dəqiqləşdirir. İmzalanan versiya müqavilənin əlavəsi olur, sonrakı dəyişikliklər yeni versiya kimi tarixlə qeyd olunur.

İnternetdəki hazır sayt müqaviləsi nümunəsindən istifadə etmək olarmı?

Hazır sayt müqaviləsi nümunəsi (axtarışda çox vaxt "sayt muqavilesi numunesi" kimi yazılır) yalnız başlanğıc nöqtəsi ola bilər. Rusdilli axtarışda tapılan şablonlar çox vaxt Rusiya qanunvericiliyinə əsaslanır, ümumi xidmət müqavilələrində isə domen, hostinq, kodun mülkiyyəti və təhvil paketi barədə bəndlər adətən olmur. Sayt müqaviləsini bu bəndlər üzrə yoxlayın və imzalamazdan əvvəl hüquqşünasa göstərin.

Saytı təhvil alarkən nəyi yoxlamaq lazımdır?

Saytı təhvil alarkən texniki tapşırığın hər bəndini test serverində yoxlayın: bütün səhifələr və dillər, formaların CRM-ə düşməsi, analitika hadisələri, mobil görünüş və Core Web Vitals göstəriciləri. Yoxlamanı orta səviyyəli Android telefonda da aparın, çünki StatCounter-in 2026-cı il avqust məlumatına görə Azərbaycanda mobil trafikin 82.23%-i Android-dəndir (StatCounter). Qüsurları bir siyahıda yazılı göndərin və domen, hostinq, kod və admin girişlərinin sizə verildiyini təsdiqləyin.

Texniki tapşırıq imzalanandan sonra dəyişiklik istəsəm nə olur?

Texniki tapşırıq imzalanandan sonra hər dəyişiklik yazılı sorğu ilə edilir: podratçı onun müddətə və qiymətə təsirini qiymətləndirir, sifarişçi təsdiqləyəndən sonra iş başlayır. Mətn, rəng və ikon kimi kiçik düzəlişlər adətən razılaşdırılmış düzəliş raundlarına daxildir, yeni səhifə və ya funksiya isə yeni iş sayılır. Bu qayda müqavilədə yazılmırsa, layihənin həcmi və son tarixi nəzarətsiz uzanır.

Nəticə

Sayt sifarişində ən etibarlı qoruma iki sənəddir: ölçülə bilən tələbləri olan texniki tapşırıq və mülkiyyəti, qəbulu, dəyişiklikləri və təhvili aydın yazan müqavilə. Şablonu layihənizə uyğunlaşdırın, podratçılardan eyni sənədlərə yazılı cavab alın və domenin, kodun, hesabların sizdə qalmasını əvvəlcədən təmin edin.

Texniki tapşırığınızı birlikdə nəzərdən keçirmək istəsəniz, ödənişsiz görüş təyin edin.

Mənbələr

1. Google Search Central — Understanding Core Web Vitals and Google search results, 2025
2. W3C — Understanding Success Criterion 1.4.3: Contrast (Minimum), WCAG 2.2, 2026
3. StatCounter — Desktop vs Mobile vs Tablet Market Share Azerbaijan, 2026
4. StatCounter — Mobile Operating System Market Share Azerbaijan, 2026
5. Google — Search Console Help: Managing owners, users, and permissions, 2026
6. ICANN — Transfer Policy, 2024