13 ਜੁਲਾ 2025·8 ਮਿੰਟ
SaaS ਮਾਰਕੀਟਿੰਗ ਪੇਜ਼ਾਂ ਅਤੇ ਡੌਕਸ ਲਈ ਵੈਬਸਾਈਟ ਕਿਵੇਂ ਬਣਾਈਏ
ਇੱਕ SaaS ਵੈਬਸਾਈਟ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣ, ਬਣਾਉਣ, ਅਤੇ ਲਾਂਚ ਕਰਨ ਬਾਰੇ ਸਿੱਖੋ ਜੋ ਮਾਰਕੀਟਿੰਗ ਪੇਜ਼ਾਂ ਅਤੇ ਡੌਕਯੂਮੇੰਟੇਸ਼ਨ ਦਾ ਸਹਾਰਾ ਦੇਵੇ—ਸਾਫ਼ ਬਣਤਰ, SEO, ਤੇਜ਼ ਪ੍ਰਦਰਸ਼ਨ, ਅਤੇ ਆਸਾਨ ਅਪਡੇਟਾਂ ਨਾਲ।
ਇੱਕ SaaS ਵੈਬਸਾਈਟ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣ, ਬਣਾਉਣ, ਅਤੇ ਲਾਂਚ ਕਰਨ ਬਾਰੇ ਸਿੱਖੋ ਜੋ ਮਾਰਕੀਟਿੰਗ ਪੇਜ਼ਾਂ ਅਤੇ ਡੌਕਯੂਮੇੰਟੇਸ਼ਨ ਦਾ ਸਹਾਰਾ ਦੇਵੇ—ਸਾਫ਼ ਬਣਤਰ, SEO, ਤੇਜ਼ ਪ੍ਰਦਰਸ਼ਨ, ਅਤੇ ਆਸਾਨ ਅਪਡੇਟਾਂ ਨਾਲ।
ਇੱਕ SaaS ਵੈਬਸਾਈਟ ਜੋ ਮਾਰਕੀਟਿੰਗ ਪੇਜ਼ਾਂ ਅਤੇ ਡੌਕਯੂਮੇੰਟੇਸ਼ਨ ਨੂੰ ਜੋੜਦੀ ਹੈ, ਦੋ ਕੰਮ ਕਰਦੀ ਹੈ: ਨਵੇਂ ਵਿਜ਼ਟਰਾਂ ਨੂੰ ਰਾਜ਼ੀ ਕਰਨਾ ਕਿ ਉਹ ਸ਼ੁਰੂ ਕਰਨ ਤੇ, ਅਤੇ ਮੌਜੂਦਾ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਫਲ ਹੋਣ ਵਿੱਚ ਮਦਦ ਕਰਨੀ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ "ਇੱਕ ਸਾਈਟ ਇਕ ਹੀ ਮਕਸਦ" ਵਜੋਂ ਦੇਖੋਗੇ, ਤਾਂ ਅਕਸਰ ਤੁਸੀਂ ਸਿਰਫ਼ ਇਕ ਪਾਸੇ ਨੂੰ ਅਪਟਿਮਾਈਜ਼ ਕਰੋਗੇ—ਤੇ ਦੂਜਾ ਪਾਸਾ ਛੁਪਕੇ ਘੱਟ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਰਹਿ ਜਾਵੇਗਾ।
ਮਾਰਕੀਟਿੰਗ ਪੇਜ਼ਾਂ ਨੂੰ ਵਿਜ਼ਟਰ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਅਗਲੇ ਕਦਮ ਵੱਲ ਲੈ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ: ਟ੍ਰਾਇਲ ਸ਼ੁਰੂ ਕਰੋ, ਡੈਮੋ ਬੁੱਕ ਕਰੋ, ਜਾਂ ਪ੍ਰਾਈਸਿੰਗ ਵੇਖੋ। ਡੌਕਯੂਮੇੰਟੇਸ਼ਨ ਸਾਈਨਅੱਪ ਤੋਂ ਬਾਅਦ ਰੁਕਾਵਟ ਘਟਾਉਣੀ ਚਾਹੀਦੀ ਹੈ: ਸਵਾਲਾਂ ਦਾ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ, ਸੈਟਅਪ ਦਾ ਮਾਰਗਦਰਸ਼ਨ, ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਕੰਮ ਨੂੰ ਅਨਲੌਕ ਕਰਨਾ।
ਇੱਕ ਇੱਕ-ਵਾਕ੍ਯ ਲਕੜੀ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਹਰ ਯੋਜਨਾ ਮੀਟਿੰਗ ਵਿੱਚ ਦੋਹਰਾਉਂਦੇ ਹੋ, ਉਦਾਹਰਨ:
“Convert qualified prospects while enabling customers to self-serve support.”
ਜ਼ਿਆਦਾਤਰ SaaS ਸਾਈਟਾਂ ਕਈ ਦਰਸ਼ਕ ਸੇਵਾ ਕਰਦੀਆਂ ਹਨ, ਹਰ ਇੱਕ ਦਾ ਇਰਾਦਾ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ:
ਜੇ ਤੁਸੀਂ ਇੱਕ ਪੇਜ਼ ਲਈ ਦਰਸ਼ਕ ਦਾ ਨਾਮ ਨਹੀਂ ਲੈ ਸਕਦੇ, ਉਹ ਪੇਜ਼ ਗੈਰ-ਸਪਸ਼ਟ ਕਾਪੀ ਵਲ ਭਟਕ ਜਾਵੇਗਾ।
ਆਉਟਕਮਾਂ ਤੁਹਾਡੇ ਟੀਮ ਨੂੰ ਪੇਜ ਗਿਣਤੀਆਂ ਦੀ ਥਾਂ ਬਿਹੈਵਿਯਰ 'ਤੇ ਧਿਆਨ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ:
ਕੁਝ ਮਿਤੀਆਂ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਪ੍ਰਤੀ ਮਹੀਨਾ ਚੈਕ ਕਰੋਗੇ: ਮਾਰਕੀਟਿੰਗ ਕਾਨਵਰਜ਼ਨ ਰੇਟ, ਐਕਟੀਵੇਸ਼ਨ ਰੇਟ, ਡੌਕਸ ਖੋਜ ਵਰਤੋਂ, ਬੜੀਆਂ ਅਸਫਲ ਖੋਜਾਂ, ਅਤੇ ਵਿਸ਼ੇਵਾਰ ਸਪੋਰਟ ਟਿਕਟ ਦੀ ਸੰਖਿਆ।
ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੌਣ ਲਿਖਦਾ ਹੈ, ਕੌਣ ਸਮੀਖਿਆ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੌਣ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਮਾਰਕੀਟਿੰਗ ਅਤੇ ਡੌਕਸ ਸਮਗਰੀ। ਸਪਸ਼ਟ ਮਲਕੀਆਨਿਅਤ ਪੁਰਾਣੇ ਡੌਕਸ ਅਤੇ ਅਸਮੰਜਸ ਪੁੰਜਾਬ ਦੀ ਰੋਕਥਾਮ ਕਰਦੀ ਹੈ—ਅਤੇ ਜਦੋਂ ਕਈ ਟੀਮਾਂ ਨੂੰ ਇਕੱਠੇ ਅਪਡੇਟ ਦੀ ਲੋੜ ਹੋਵੇ ਤਾਂ ਲਾਂਚ ਸੌਖਾ ਬਣਾਉਂਦੀ ਹੈ।
ਸੂਚਨਾ ਵਿਵਸਥਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਦੋਨਾਂ ਯਾਤਰਾਵਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਵੱਸਾਉਂਦੇ ਹੋ ਕਿ ਉਹ ਸਪਸ਼ਟ ਲੱਗਣ—ਬਿਨਾਂ ਹੈਡਰ ਨੈਵ ਨੂੰ ਇਕ ਜੰਕ ਡ੍ਰੌਅਰ ਬਣਾਉਂਦੇ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ "marketing + docs" ਨੂੰ ਕੁਝ ਮੁੱਖ ਟਾਪ-ਲੇਵਲ ਖੇਤਰਾਂ ਨਾਲ ਕਵਰ ਕਰ ਸਕਦੀਆਂ ਹਨ:
ਗਲੋਬਲ ਨੈਵੀਗੇਸ਼ਨ ਨੂੰ ਉਸ ਚੀਜ਼ 'ਤੇ ਕੇਂਦਰਿਤ ਰੱਖੋ ਜੋ ਪਹਿਲੀ ਵਾਰੀ ਦੇਖਣ ਵਾਲਾ ਉਮੀਦ ਕਰੇਗਾ। ਬਾਕੀ (ਸੁਰੱਖਿਆ, status, changelog, partners, legal) ਫੂਟਰ ਵਿੱਚ ਜਾਂ ਸੰਬੰਧਿਤ ਸੈਕਸ਼ਨ ਵਿੱਚ ਰੱਖੋ।
ਜ਼ਿਆਦਾਤਰ SaaS ਉਤਪਾਦਾਂ ਲਈ, ਡੌਕਯੂਮੇੰਟੇਸ਼ਨ ਨੂੰ /docs ਦੇ ਹੇਠਾਂ ਹੋਸਟ ਕਰਨਾ ਸਭ ਤੋਂ ਸਧਾਰਨ ਚੋਣ ਹੈ।
Docs under /docs (same domain)
Docs on a subdomain (for example, docs.[your-domain])
ਜੇ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਪਤਾ ਹੈ ਕਿ ਤੁਹਾਡੀਆਂ ਡੌਕਸ ਵਿਆਪਕ ਹੋਣਗੀਆਂ ਅਤੇ ਵੱਖਰੀ ਟੀਮ/ਟੂਲਿੰਗ ਦੁਆਰਾ ਸੰਭਾਲੀਆਂ ਜਾਣਗੀਆਂ, ਤਾਂ ਸਬਡੋਮੇਨ ਮਕੂਲ ਹੋ ਸਕਦਾ ਹੈ। ਨਹੀਂ ਤਾਂ, /docs ਆਮ ਤੌਰ 'ਤੇ ਰਹਿਤਮਤ ਚੋਣ ਹੈ।
ਆਮ ਰਾਹਾਂ ਦੇ ਵਿਚਾਰ ਨਾਲ ਸੋਚੋ, ਫਿਰ ਯਕੀਨੀ ਬਣਾਓ ਕਿ URLs ਅਤੇ ਨੈਵੀਗੇਸ਼ਨ ਉਹਨਾਂ ਨੂੰ ਸਹਾਰਾ ਦਿੰਦੀਆਂ ਹਨ।
Marketing journey example:
Support journey example:
ਨੈਵੀਗੇਸ਼ਨ ਦੀਆਂ ਭੂਮਿਕਾਵਾਂ ਮਾਇਨੇ ਰੱਖਦੀਆਂ ਹਨ:
URLs ਪ੍ਰੋਮਿਸ ਹੁੰਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਬਦਲਣਾ ਬੁੱਕਮਾਰਕ, ਇਨਬਾਉਂਡ ਲਿੰਕ ਅਤੇ ਭਰੋਸਾ ਤੋੜਦਾ ਹੈ।
ਇੱਕ عملي ਤਰੀਕਾ:
ਜਦੋਂ ਤੁਸੀਂ ਦੁਬਾਰਾ ਸਰਚਨਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਰਿਡਾਇਰੈਕਟ ਦੀ ਯੋਜਨਾ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਕਰੋ। ਇਕ ਸਾਫ਼ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਅਸਥਿਰ URLs ਤੁਹਾਡੀ SaaS ਸਾਈਟ ਨੂੰ ਅਸਾਨ ਬਣਾਉਂਦੇ ਹਨ।
ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ SaaS ਸਾਈਟ ਬਣਾ ਰਹੇ ਹੋ ਜੋ ਵੇਚਣ ਅਤੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਹਾਇਤਾ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਾਹ ਇੱਕ ਛੋਟੀ ਸੈੱਟ ਦੇ ਪੇਜ਼ਾਂ ਨੂੰ ਜਾਰੀ ਕਰਨਾ ਹੈ ਜੋ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਂਦੇ ਹਨ: ਇਹ ਕੀ ਹੈ? ਕੀ ਮੈਂ ਇਸ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦਾ ਹਾਂ? ਅਗਲਾ ਕਿਆ ਕਰਾਂ?
ਜਿਨ੍ਹਾਂ ਅਹਮ ਪੇਜ਼ਾਂ ਦੀ ਭਰਪਾਈ ਨਾਲ ਯਾਤਰੀਆਂ ਦੀ ਉਮੀਦ ਅਤੇ ਟੀਮਾਂ ਦੀ ਰੈਫਰੈਂਸ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ, ਉਹ ਪਹਿਲਾਂ ਸ਼ਿਪ ਕਰੋ:
ਹਰ ਪੇਜ਼ ਨੂੰ ਇੱਕ ਫੈਸਲੇ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਰੱਖੋ। ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਵਧਾ ਸਕਦੇ ਹੋ।
ਉਪਭੋਗਤਾ ਟ੍ਰਾਇਲ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਮਾਣ ਲੱਭਦੇ ਹਨ। ਸ਼ੁਰੂ ਵਿੱਚ ਹਲਕੇ ਭਾਰ ਦੇ ਭਰੋਸੇ ਦੇ ਸਿਗਨਲ ਜੋੜੋ:
ਜਦੋਂ ਮੂਲ ਪੇਜ਼ ਹਨ, ਉਹ ਪੇਜ਼ ਜੋ ਤੁਹਾਡੇ ਸੇਲਜ਼ ਮੋਸ਼ਨ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ ਜੋੜੋ:
ਇਹ ਪੇਜ਼ ਰੁਕਾਵਟ ਘਟਾਉਣੇ ਚਾਹੀਦੇ ਹਨ: ਸਪਸ਼ਟ ਫਾਰਮ ਫੀਲਡ, ਉਮੀਦਾਂ (“ਅਸੀਂ 1 ਕਾਰੋਬਾਰੀ ਦਿਨ ਵਿੱਚ ਜਵਾਬ ਦਿੰਦੇ ਹਾਂ”), ਅਤੇ ਅਗਲੇ ਕਦਮ।
ਤੁਹਾਡੀ ਡੌਕਯੂਮੇੰਟੇਸ਼ਨ ਨਵੇਂ ਯੂਜ਼ਰ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਫਲ ਹੋਣ ਵਿੱਚ ਮਦਦ ਕਰਨ ਵਾਲੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:
ਇਹ ਉਹਨਾਂ ਨੂੰ ਜੋੜੋ ਜਦੋਂ ਬੇਸਿਕ ਸਥਿਰ ਹੋ ਜਾਣ:
ਤੁਹਾਡਾ ਟੈਕ ਸਟੈਕ ਇਸ ਗੱਲ ਨਾਲ ਮੇਲ ਖਾਵੇ ਕਿ ਸਮਗਰੀ ਕਿੰਨੀ ਵਾਰੀ ਬਦਲਦੀ ਹੈ, ਕੌਣ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੀ ਸਾਈਟ ਨੂੰ ਐਪ-ਵਰਗਾ ਵਿਹਾਰ ਚਾਹੀਦਾ ਹੈ। ਜ਼ਿਆਦातर SaaS ਟੀਮਾਂ ਲਈ, ਮਿੱਠਾ ਬਿੰਦੂ ਇੱਕ ਐਸਾ ਮਾਰਕੀਟਿੰਗ ਸਾਈਟ + ਡੌਕਸ ਹੈ ਜੋ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੋਵੇ, ਅਪਡੇਟ ਕਰਨਾ ਆਸਾਨ ਹੋਵੇ, ਅਤੇ ਹਰ ਇੱਕ ਕਾਪੀ-ਚੇਕ ਲਈ ਇੰਜੀਨੀਅਰ ਦੀ ਲੋੜ ਨਾ ਪਏ।
SSG (ਜਿਵੇਂ Next.js static export, Astro, Docusaurus, Hugo) ਪੇਜ਼ਾਂ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਬਣਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਤੁਹਾਡੇ ਮਾਰਕੀਟਿੰਗ ਪੇਜ਼ ਅਤੇ ਡੌਕਸ ਜ਼ਿਆਦਾਤਰ ਐਨਟਿਸਪੇਕਟੇਬਲ ਹੋਣ, ਇਹ ਵਧੀਆ ਫ਼ਿੱਟ ਹੁੰਦਾ ਹੈ।
ਸਟੈਟਿਕ ਤਰੀਕੇ ਨਾਲ ਵਰਤੋਂ ਜਦੋਂ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ:
ਇਹ ਡੌਕਸ ਨੂੰ Markdown ਵਿੱਚ ਰੱਖਣ ਦਾ ਇੱਕ ਸਾਫ਼ ਤਰੀਕਾ ਵੀ ਹੈ, ਜਦੋਂ-ਕਿ ਖੋਜ ਅਤੇ ਵਰਜ਼ਨਡ ਸਮਗਰੀ ਨੂੰ सपोर्ट ਕਰਦਾ ਹੈ।
ਜਦੋਂ ਸਾਈਟ ਨੂੰ ਉਤਪਾਦ ਅਨੁਭਵ ਵਾਂਗ ਵਰਤਣਾ ਜਰੂਰੀ ਹੋਵੇ ਤਾਂ ਸਰਵਰ-ਰੇਂਡਰਡ ਸੈਟਅਪ (ਜਾਂ ਪੂਰਾ ਐਪ) ਲਾਇਕ ਹੈ।
ਇਸਨੂੰ ਚੁਣੋ ਜਦੋਂ ਤੁਹਾਨੂੰ ਲੋੜ ਹੋਵੇ:
ਤੁਸੀਂ ਫਿਰ ਵੀ ਬਹੁਤ ਸਾਰੇ ਮਾਰਕੀਟਿੰਗ ਪੇਜ਼ਾਂ ਨੂੰ ਸਟੈਟਿਕਲੀ ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਸਿਰਫ ਜਿਨ੍ਹਾਂ ਹਿੱਸਿਆਂ ਨੂੰ ਡਾਇਨੈਮਿਕ ਚਾਹੀਦਾ ਹੈ ਉਨਾਂ ਨੂੰ ਰੈਂਡਰ ਕਰੋ।
ਜਦੋਂ ਗੈਰ-ਟੈਕਨਿਕਲ ਟੀਮਾਂ ਵਾਰੰ ਵਾਰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਸਟਰੱਕਚਰਡ ਸਮਗਰੀ (ਪ੍ਰਾਈਸਿੰਗ ਟੀਅਰ, ਗਾਹਕ ਕਹਾਣੀਆਂ, ਤੁਲਨਾਤਮਕ ਟੇਬਲ) ਚਾਹੀਦੀ ਹੈ, CMS-ਚਲਿਤ ਸਾਈਟ ਚੰਗੀ ਰਹਿੰਦੀ ਹੈ।
Markdown/MDX ਡੌਕਸ ਲਈ ਆਦਰਸ਼ ਹੈ: ਲਿਖਣ ਵਿੱਚ ਤੇਜ਼, Git ਵਿੱਚ ਸਮੀਖਿਆ ਲਈ ਆਸਾਨ, ਅਤੇ ਵਰਜ਼ਨਿੰਗ ਲਈ ਦੋਸਤਾਨਾ। CMS ਫੀਲਡ ਸਟਰੱਕਚਰਡ ਮਾਰਕੀਟਿੰਗ ਸਮਗਰੀ ਲਈ ਚਮਕਦੇ ਹਨ ਜਿੱਥੇ ਮੁਸਲਮਾਨੀ ਲਾਗੂ ਹੈ।
ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਤਿੰਨ ਵਾਤਾਵਰਨ ਬਣਾਓ:
ਇਹ ਵਰਕਫਲੋ ਪ੍ਰਕਾਸ਼ਨ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਦਾ ਹੈ ਭਾਵੇਂ ਮਾਰਕੀਟਿੰਗ ਅਤੇ ਡੌਕਸ ਹਫ਼ਤਾਵਾਰੀ ਅਪਡੇਟ ਕਰ ਰਹੀਆਂ ਹੋਣ।
ਜੇ ਤੁਸੀਂ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਹੋਰ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵੱਧਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai ਤੁਹਾਡੇ ਨੂੰ ਪ੍ਰਾਥਮਿਕ ਮਾਰਕੀਟਿੰਗ + ਡੌਕਸ ਅਨੁਭਵ ਨੂੰ ਸਧਾਰਨ ਚੈਟ ਤੋਂ ਪ੍ਰੋਟੋਟਾਇਪ ਕਰਕੇ ਮਦਦ ਦੇ ਸਕਦੇ ਹਨ—ਫਿਰ ਜਦੋਂ ਤੁਹਾਡੀ ਸਰਚਨਾ, ਨੈਵੀਗੇਸ਼ਨ, ਅਤੇ ਮੁੱਖ ਪੇਜ਼ ਵੈਲਿਡੇਟ ਹੋ ਜਾਣ, ਤ ਸੁਝਾਅ ਲਈ ਸਰੋਤ ਕੋਡ ਨਿਰਯਾਤ ਕਰੋ।
ਚੰਗਾ ਡਿਜ਼ਾਈਨ SaaS ਸਾਈਟ ਲਈ ਦੋਹੀਂ ਵਿਅਕਤੀਆਂ ਰੱਖਦਾ ਹੈ: ਮਾਰਕੀਟਿੰਗ ਪੇਜ਼ ਲੋਕਾਂ ਨੂੰ ਰਾਜ਼ੀ ਕਰਨ ਅਤੇ ਅਗਲੇ ਕਦਮ ਵੱਲ ਲੈ ਜਾਣ ਲਈ, ਜਦਕਿ ਡੌਕਸ friction ਘਟਾਉਣ ਅਤੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਤੇਜ਼ ਸਫਲਤਾ ਦਿੰਦੇ ਹਨ। ਨੁਕਤਾ ਇਹ ਹੈ ਕਿ ਦੋਨਾਂ ਨੂੰ ਇਕ ਉਤਪਾਦ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਵੇ।
ਪੇਜ਼ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ ਡਿਜ਼ਾਈਨ ਸਿਸਟਮ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਟਾਇਪੋਗ੍ਰਾਫੀ ਸਕੇਲ, ਰੰਗ ਪੈਲੇਟ, ਸਪੇਸਿੰਗ ਨਿਯਮ, ਅਤੇ ਕੁਝ ਕੋਰ ਕੰਪੋਨੈਂਟ (ਬਟਨ, ਅਲਰਟ, ਕਾਰਡ, ਟੈਬ)। ਇਹ ਤੁਹਾਡੇ ਮਾਰਕੀਟਿੰਗ ਪੇਜ਼ਾਂ ਨੂੰ "ਡਿਜ਼ਾਈਨ ਕੀਤੇ" ਅਤੇ ਡੌਕਸ ਨੂੰ "ਡਿਫ਼ਾਲਟ" ਲੱਗਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਵਿਆਹਕ ਤਰੀਕਾ: ਬਾਡੀ + ਹੈਡਿੰਗ ਲਈ 2–3 ਫੌਂਟ ਸਾਈਜ਼, ਇੱਕ ਮੁੱਖ ਬ੍ਰਾਂਡ ਰੰਗ, ਅਤੇ ਨਿਊਟਰਲ ਸਕੇਲ ਬਾਰਡਰ/ਬੈਕਗਰਾਊਂਡ ਲਈ। ਫਿਰ ਸਪੇਸਿੰਗ (ਉਦਾਹਰਨ ਲਈ 8px ਸਟੈਪ) ਨੂੰ ਸਟੈਂਡਰਡ ਕਰੋ ਤਾਂ ਕਿ ਲੇਆਉਟ ਲੈਂਡਿੰਗ ਪੇਜ਼ਾਂ ਅਤੇ ਡੌਕਸ ਵਿੱਚ ਲਗਾਤਾਰ ਰਹਿਣ।
ਪੇਜ਼ ਸੈਕਸ਼ਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ ਬਣਾਓ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਬਿਲਡਿੰਗ ਬਲਾਕ ਵਾਂਗ ਜੋੜ ਸਕੋਂ:
ਜਦੋਂ ਇਹ ਸੈਕਸ਼ਨ ਸਾਂਝੇ ਸਪੇਸਿੰਗ, ਟਾਇਪੋਗ੍ਰਾਫੀ, ਅਤੇ ਬਟਨ ਸਟਾਇਲ ਸਾਂਝੇ ਹੁੰਦੇ ਹਨ, ਤੁਹਾਡੀ ਸਾਈਟ ਇਕੱਠੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਸਮਗਰੀ ਵਧਦੀ ਹੈ।
ਡੌਕਸ ਦਾ UX ਮੁੱਖ ਤੌਰ 'ਤੇ ਪਾਠਨਯੋਗਤਾ ਹੈ। ਸਪਸ਼ਟ ਹੈਡਿੰਗ ਹਾਇਰਾਰਕੀ, ਪੰਕਤੀ-ਛੋਟਾ ਲਾਈਨ-ਹਾਈਟ, ਅਤੇ ਸਮੱਗਰੀ ਚੌੜਾਈ ਜਿਸ ਨਾਲ ਲੰਬੀਆਂ ਵਾਕਾਂ ਅਤੇ ਵਿਆਪਕ ਕੋਡ ਬਲਾਕ ਦੋਹਾਂ ਠੀਕ ਰਹਿਣ। ਕੋਡ ਬਲਾਕਾਂ ਨੂੰ ਅੜ੍ਹਨ ਦੀ ਬਜਾਏ ਲੰਬੇ ਹੋਣ 'ਤੇ ਹੋਰਾਈਜ਼ਨਟਲ ਸਕ੍ਰੋਲ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿਓ। ਪੰਨਿਆਂ ਨੂੰ ਸਕੈਨੇਬਲ ਰੱਖੋ: ਛੋਟੇ ਇੰਟਰੋ, “before you start” ਨੋਟ, ਅਤੇ ਚੇਤਾਵਨੀਾਂ ਲਈ ਕਾਲਆਉਟ।
Accessibility ਨੂੰ ਬੇਸਲਾਈਨ ਸਮਝੋ:
ਮੋਬਾਈਲ ਤੇ, ਦੋ ਚੀਜ਼ਾਂ ਜਲਦੀ ਟੈਸਟ ਕਰੋ: ਟੌਪ ਨੈਵੀਗੇਸ਼ਨ ਮੇਨੂ ਅਤੇ ਡੌਕਸ ਸਾਈਡਬਾਰ। ਜੇ ਕੋਈ ਵੀ ਖੋਲ੍ਹਣਾ, ਬੰਦ ਕਰਨਾ, ਜਾਂ ਸਮਝਣਾ ਔਖਾ ਹੈ, ਯੂਜ਼ਰ ਚੱਲ ਜਾਂਦੇ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ।
ਚੰਗੀਆਂ SaaS ਸਾਈਟਾਂ ਸਿਰਫ਼ ਉਤਪਾਦ ਦਾ ਵਰਣਨ ਨਹੀਂ ਕਰਦੀਆਂ—ਉਹ ਪਾਠਕ ਨੂੰ ਜਿਗਿਆਸਾ ਤੋਂ ਭਰੋਸੇ ਤੱਕ ਲੈ ਜਾਂਦੀਆਂ ਹਨ। ਇਹ ਰਾਹ ਸਪਸ਼ਟ ਮੈਸੇਜਿੰਗ, ਸਧਾਰਨ ਕਾਪੀ, ਅਤੇ ਵਿਚਾਰਸ਼ੀਲ CTA ਨਾਲ ਬਣਿਆ ਹੁੰਦਾ ਹੈ ਜੋ ਹਰ ਪੇਜ਼ 'ਤੇ ਕਿਸੇ ਦੀ ਨੀਤਿ ਨਾਲ ਮਿਲਦੇ ਹਨ।
ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ, ਪ੍ਰਤੀ ਪੇਜ਼ ਕੀ ਸਫਲਤਾ ਹੈ ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ। ਹਰ ਮੁੱਖ ਪੇਜ਼ ਨੂੰ ਇੱਕ primary CTA (ਮੁੱਖ ਚੀਜ਼ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ) ਅਤੇ ਇੱਕ secondary CTA (ਘੱਟ-ਕਮਿਟਮੈਂਟ ਅਗਲਾ ਕਦਮ) ਦਿਓ।
Examples:
CTA ਦੀ ਭਾਸ਼ਾ ਅਤੇ ਸਥਾਨ ਨੂੰ ਲਗਾਤਾਰ ਰੱਖੋ ਤਾਂ ਕਿ ਵਿਜ਼ਟਰ ਹਰ ਪੇਜ਼ 'ਤੇ ਨਵਾਂ ਸਿਖਣ ਨਾ ਪਏ।
ਆਉਟਕਮਾਂ ਨਾਲ ਅਗਵਾ ਕਰੋ ਜੋ ਗਾਹਕ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਫਿਰ ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਉਹਨੂੰ ਕਿਵੇਂ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹੋ। ਅਸਪਸ਼ਟ ਦਾਅਵਿਆਂ ("streamline your workflow") ਨੂੰ ਵਿਸ਼ੇਸ਼ ਨਤੀਜਿਆਂ ਨਾਲ ਬਦਲੋ ("onboarding ਸਮਾਂ ਦਿਨਾਂ ਤੋਂ ਘਟ ਕੇ ਘੰਟਿਆਂ ਤੱਕ")।
ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ ਜਰਗਨ ਤੋਂ ਬਚੋ। ਜੇ ਇੰਡਸਟਰੀ ਸ਼ਬਦ ਵਰਤਣੇ ਲਾਜ਼ਮੀ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਸਾਧੀ ਭਾਸ਼ਾ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਛੋਟੇ ਵਾਕ ਖਾਸ ਕਰਕੇ ਹੈਡਿੰਗ, ਸਬਹੈਡਿੰਗ, ਅਤੇ ਬਟਨ ਟੈਕਸਟ ਲਈ ਜਿੱਤਦੇ ਹਨ।
ਮੁੱਖ ਫੈਸਲਿਆਂ ਕੋਲ ਪ੍ਰੂਫ਼ ਜੋੜੋ (ਫੀਚਰ, ਪ੍ਰਾਈਸਿੰਗ, ਸਾਈਨਅਪ)। ਨੰਬਰ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਵਰਤੋ ਜਦੋਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਦੀ ਪੱਕੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਸੰਦਰਭ ਦਿਖਾਓ:
ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਮਨੁੱਖੀ ਪ੍ਰਮਾਣ ਨਾਲ ਨਿਭਾਓ: ਕੋਟ, ਮਿਨੀ ਕੇਸ ਸਟੱਡੀਜ਼, ਅਤੇ ਰੀਅਲ ਵਰਕਫਲੋ ਉਦਾਹਰਨ।
ਅਸਪਸ਼ਟ ਪ੍ਰਾਈਸਿੰਗ ਸਾਈਨਅੱਪ ਰੋਕਦਾ ਹੈ। ਯੋਜਨਾ ਨਾਮ, ਕੋਰ ਸੀਮਾਵਾਂ, ਐਡ-ਆਨ, ਅਤੇ ਜਦੋਂ ਯੂਜ਼ਰ ਸੀਮਾ ਪਾਰ ਕਰੇਗਾ ਤਾਂ ਕੀ ਹੋਵੇਗਾ—ਸੱਫ਼ ਸੂਚੀ ਦਿਓ। ਐਫ.ਏ.ਕਿਊ. ਸ਼ਾਮਿਲ ਕਰੋ ਜੋ ਆਪਤੀ-ਪ੍ਰਸ਼ਨਾਂ (ਸੁਰੱਖਿਆ, ਬਿਲਿੰਗ, ਰੱਦਗੀ, ਸਪੋਰਟ) ਨੂੰ ਜਵਾਬ ਦੇਵੇ।
ਜਿੱਥੇ ਤੁਸੀਂ ਕਿਸੇ ਫੀਚਰ ਦੀ ਵਿਆਖਿਆ ਕਰਦੇ ਹੋ, ਸਿੱਧਾ ਸਭ ਤੋਂ ਸੰਬੰਧਿਤ ਗਾਇਡ ਨਾਲ ਲਿੰਕ ਕਰੋ: “See how it works” → /docs/getting-started ਜਾਂ /docs/integrations/slack। ਇਹ ਭਰੋਸਾ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਪ੍ਰੀ-ਸੇਲਜ਼ ਸਵਾਲ ਘਟਾਉਂਦਾ ਹੈ—ਅਤੇ ਪਾਠਕ ਨੂੰ ਅੱਗੇ ਵਧਾਉਂਦਾ ਹੈ।
ਚੰਗੇ ਡੌਕਸ "ਸਪਸ਼ਟ" ਵਰਗੀ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ। ਰਾਜ਼ ਉਹ ਹੈ ਕਿ ਇੱਕ ਪੇਸ਼ਗੀ-ਅਨੁਮਾਨਿਤ ਬਣਤਰ ਅਤੇ ਨੈਵੀਗੇਸ਼ਨ ਜੋ ਹਰ ਪੇਜ਼ 'ਤੇ ਦੋ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ: ਮੈਂ ਕਿੱਥੇ ਹਾਂ? ਅਤੇ ਮੈਨੂੰ ਅਗਲੇ ਕੀ ਪੜ੍ਹਨਾ ਚਾਹੀਦਾ ਹੈ?
ਡੌਕਸ ਸਾਈਡਬਾਰ ਨੂੰ ਕੁਝ ਸ਼੍ਰੇਣੀਆਂ ਨਾਲ ਬਣਾਓ, ਸਾਧੀ ਭਾਸ਼ਾ ਵਿੱਚ ਲੇਬਲ। ਟਾਸਕ ਅਤੇ ਨਤੀਜਿਆਂ ਦੇ ਅਧਾਰ 'ਤੇ ਅੋਅਗੇ ਅਤੇ ਟੀਮ ਦੇ ਅੰਦਰੂਨੀ ਨਾਮਾਂ ਉੱਤੇ ਨਹੀਂ।
ਆਮ ਟਾਪ-ਲੇਵਲ ਸ਼੍ਰੇਣੀਆਂ:
ਲੇਬਲ ਤੁਹਾਡੇ ਉਤਪਾਦ ਦੇ ਨਾਮਾਂ ਨਾਲ ਮਿਲਦੇ-ਜੁਲਦੇ ਹੋਣ ਚਾਹੀਦੇ ਹਨ। ਜੇ UI ਵਿੱਚ "Workspaces" ਲਿਖਿਆ ਹੈ, ਉਹਨਾਂ ਨੂੰ docs ਵਿੱਚ "Projects" ਨਾ ਕਰੋ।
ਲੰਬੇ ਪੇਜ਼ਾਂ 'ਤੇ, ਪੇਜ਼ ਦੇ ਉੱਪਰ ਇੱਕ table of contents ਸ਼ਾਮਿਲ ਕਰੋ ਤਾਂ ਕਿ ਪਾਠਕ ਸਿੱਧਾ ਸਹੀ ਸੈਕਸ਼ਨ 'ਤੇ ਜਾ ਸਕਣ। ਨਿੱਛਲੇ/ਪਿਛਲੇ ਲਿੰਕ ਪੇਜ਼ ਦੇ ਤਹਿਤ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ ਸੈਟਅਪ ਅਤੇ ਆਨਬੋਰਡਿੰਗ ਲੜੀਆਂ ਵਿੱਚ ਪਾਠ ਰਹਿਤ ਸਪਸ਼ਟ ਢੰਗ ਦੇ ਨਾਲ ਜਾਰੀ ਰਹੇ।
ਲਗਾਤਾਰਤਾ ਇੱਕ ਫੀਚਰ ਹੈ। ਇੱਕ ਗਾਈਡ ਟੈਮਪਲੇਟ ਵਰਤੋ:
Problem → Steps → Expected result → Troubleshooting
ਇਹ ਪੈਟਰਨ ਪਾਠਕਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਨਵੀਆਂ ਲੇਖ ਲਿਖਣ ਵਿੱਚ ਆਸਾਨੀ ਦਿੰਦਾ ਹੈ।
ਹਰ ਪੇਜ਼ 'ਤੇ ਹਲਕਾ ਫੀਡਬੈਕ ਵਿਕਲਪ ਰੱਖੋ: “Was this helpful?” ਅਤੇ ਸਪੋਰਟ ਨਾਲ ਸੰਪਰਕ ਕਰਨ ਲਈ ਸਪਸ਼ਟ ਲਿੰਕ (for example, /contact ਜਾਂ /support)। ਫੀਡਬੈਕ ਡੌਕਸ ਨੂੰ ਅਸਲੀ ਸਵਾਲਾਂ ਨਾਲ ਮਿਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਨਿਰਾਸ਼ ਪਾਠਕਾਂ ਨੂੰ ਸਹਾਇਤਾ ਲਈ ਇੱਕ ਤੇਜ਼ ਰਾਹ ਦਿੰਦਾ ਹੈ।
SaaS ਸਾਈਟ ਲਗਾਤਾਰ ਬਦਲਦੀ ਰਹਿੰਦੀ ਹੈ: ਪ੍ਰਾਈਸਿੰਗ ਸੋਧਾਂ, ਨਵੀਆਂ ਫੀਚਰਾਂ, ਡੌਕਸ ਫਿਕਸ, ਅਤੇ ਉਤਪਾਦ ਖੁਲਾਸੇ। ਲਕੜੀ ਇਹ ਹੈ ਕਿ ਅਪਡੇਟ ਮਨੁੱਖਾਂ ਲਈ ਆਸਾਨ ਹੋਣ, ਅਤੇ ਸਾਈਟ ਭਰੋਸੇਯੋਗ ਰਹੇ—ਨੈਵੀਗੇਸ਼ਨ, ਖੋਜ, ਅਤੇ SEO ਟੂਟੇ ਬਿਨਾਂ।
ਹਰ ਪੇਜ਼ ਕਿਸੇ ਸਟ੍ਰੱਕਚਰਡ ਸਮਗਰੀ ਵਜੋਂ ਸੋਚੋ। ਜੇ ਤੁਸੀਂ Markdown/MDX ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਸਥਿਰ front matter ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਤਾਂ ਕਿ ਪੇਜ਼ ਲਿਸਟ, ਖੋਜ, ਅਤੇ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਦਿਖਾਈ ਦੇ ਸਕਣ।
ਆਮ ਫੀਲਡ ਜੋ ਸਟੈਂਡਰਡ ਕਰਨ ਯੋਗ ਹਨ:
title (ਪੇਜ਼ ਹੈਡਰ ਵਿੱਚ ਜੋ ਦਿਖੇ)description (meta + cards)tags ਜਾਂ category (ਗਰੁੱਪਿੰਗ ਅਤੇ ਫਿਲਟਰ)last_updated (ਡੌਕਸ ਲਈ ਭਰੋਸੇ ਦੀ ਨਿਸ਼ਾਨੀ)sidebar_position (ਡੌਕਸ ਵਿੱਚ ਆਰਡਰ)ਇਥੇ ਇਕਸਾਰਤਾ “ਰਹੱਸਮਈ ਪੇਜ਼” ਸਮੱਸਿਆ ਰੋਕਦੀ ਹੈ ਜੋ ਮੀਨੂ ਵਿੱਚ ਨਹੀਂ ਦਿਖਦੇ ਜਾਂ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਲਿਸਟ ਨਹੀਂ ਹੁੰਦੇ।
ਇੱਕ ਹਲਕਾ ਪਾਈਪਲਾਈਨ ਗਲਤੀਆਂ ਘਟਾਉਂਦਾ ਹੈ:
Draft → Review → Publish
ਡ੍ਰਾਫਟਸ ਕਿਸੇ ਬ੍ਰਾਂਚ (Git) ਜਾਂ ਹੈੱਡਲੈੱਸ CMS ਵਿੱਚ ਬਣਾਏ ਜਾ ਸਕਦੇ ਹਨ। ਸਮੀਖਿਆਆਂ ਨੂੰ ਸਾਫ਼ਾਈ, ਸਹੀਤਾ, ਅਤੇ ਇਹ ਵੇਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਲਿੰਕ/CTA ਅਜੇ ਵੀ ਸਹੀ ਹਨ (ਉਦਾਹਰਨ ਲਈ /pricing ਜਾਂ /docs)।
ਕਾਪੀ-ਪੇਸਟ ਕੀਤੇ ਟੈਕਸਟ ਜਾਂ ਸਕ੍ਰੀਨਸ਼ਾਟ ਤੋਂ ਬਦਲ ਕਰਨ ਦੀ ਮਨਜ਼ੂਰੀ ਦੇਣ ਤੋਂ ਬਚੋ। ਪ੍ਰੀਵਿਊ ਲਿੰਕ ਵਰਤੋ ਤਾਂ ਕਿ ਸਮੀਖਿਆਕਾਰ ਪੇਜ਼ ਨੂੰ ਪ੍ਰਸੰਗ ਵਿੱਚ ਵੇਖ ਸਕਣ (ਨੈਵੀਗੇਸ਼ਨ, ਮੋਬਾਈਲ ਲੇਆਉਟ, ਅਤੇ ਕ੍ਰਾਸ-ਲਿੰਕ)।
ਆਮ ਵਿਕਲਪ:
ਫੈਸਲੇ ਇੱਕ ਵਾਰੀ ਲਿਖੋ: ਵਾਇਸ, ਹੈਡਿੰਗ ਸਟ੍ਰੱਕਚਰ, ਕੋਡ/ਉਦਾਹਰਨ ਕਨਵੈਨਸ਼ਨ, ਅਤੇ ਸਕ੍ਰੀਨਸ਼ਾਟ ਕਿਵੇਂ ਕੈਪਚਰ ਅਤੇ ਅਪਡੇਟ ਹੋਣੇ ਚਾਹੀਦੇ—ਇਹ ਸਭ ਨੇ docs ਨੂੰ ਇਕਸਾਰ ਬਣਾਉਂਦਾ ਹੈ।
ਨਿਰਧਾਰਿਤ ਕਰੋ ਕੌਣ ਕੀ ਵਰਕ ਦੇਖਦਾ ਹੈ:
ਇੱਕ ਟਾਈ-ਬ੍ਰੇਕਰ ਵੀ ਚੁਣੋ শૅਰਡ ਪੇਜ਼ਾਂ (homepage, navigation labels) ਲਈ ਤਾਂ ਕਿ ਬਦਲਾਅ ਰੁਕ ਨਾ ਜਾਣ।
ਜਦੋਂ ਮਾਰਕੀਟਿੰਗ ਪੇਜ਼ ਅਤੇ ਡੌਕਸ ਇਕੱਠੇ ਇੱਕ ਸਾਈਟ 'ਤੇ ਰਹਿੰਦੇ ਹਨ ਤਾਂ SEO ਆਸਾਨ ਹੋ ਜਾਂਦੀ ਹੈ: ਤੁਸੀਂ ਅਥਾਰਟੀ ਬਣਾਉਂ ਸਕਦੇ ਹੋ, ਅੰਦਰੂਨੀ ਲਿੰਕ ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਸੰਕੇਤ ਬਟਵਾਰਾ ਨਹੀਂ ਹੁੰਦਾ।
ਹਰ ਇੰਡੈਕਸਬਲ ਪੇਜ਼ 'ਤੇ ਮੂਲ ਤੱਤ ਸੈੱਟ ਕਰੋ:
URLs ਅਤੇ ਲਿੰਕ ਲਈ ਸਧਾਰਣ ਨਿਯਮ ਬਣਾਓ: ਹਮੇਸ਼ਾ relative paths ਵਰਤੋ (ਜਿਵੇਂ /pricing, /docs/api/auth)। ਇਹ ਸਟੇਜਿੰਗ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਤਾਵਰਨ ਨੂੰ ਲਗਾਤਾਰ ਰੱਖਦਾ ਅਤੇ ਟੁੱਟੇ ਹੋਏ ਲਿੰਕਾਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।
ਜੋ ਡੰਗ ਨਾਲ ਇਕੱਠੇ ਸਾਈਟਾਂ ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਖ਼ਤਰਾ ਇਹ ਹੈ ਕਿ ਇੱਕੋ ਹੀ ਵਿਆਖਿਆ ਕਈ ਥਾਂ ਤੋੜੀ-ਮਰੋੜੀ ਹੋ ਸਕਦੀ ਹੈ (ਜਿਵੇਂ “How SSO works” ਫੀਚਰ ਪੇਜ਼ ਤੇ ਅਤੇ ਡੌਕਸ ਵਿੱਚ)।
ਜਦੋਂ ਓਵਰਲੈਪ ਅਟੱਲ ਹੋ:
Schema ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਜੋੜੋ ਜਦੋਂ ਇਹ ਸਹੀ ਹੋ:
ਕਲੱਸਟਰ ਬਣਾਓ ਜਿੱਥੇ ਬਲੌਗ ਪੋਸਟ ਵਿਆਪਕ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ ਅਤੇ ਪਾਠਕ ਨੂੰ ਅਗਲੇ ਕਦਮ ਵੱਲ ਲੈ ਜਾਂਦੇ ਹਨ:
ਇਹ ਬਿਲਡਿੰਗ ਰੈਂਕਿੰਗ ਤੇ ਕਨਵਰਜ਼ਨ ਦੋਹਾਂ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ—ਬਿਨਾਂ ਡੌਕਸ ਨੂੰ ਸੇਲਜ਼ ਕਾਪੀ ਵਰਗਾ ਬਣਾਏ।
ਇੱਕ SaaS ਸਾਈਟ ਜੋ ਮਾਰਕੀਟਿੰਗ ਪੇਜ਼ ਅਤੇ ਡੌਕਸ ਮਿਕਸ ਕਰਦੀ ਹੈ, ਨੂੰ ਤੁਰੰਤ ਅਤੇ ਭਰੋਸੇਯੋਗ ਮਹਿਸੂਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਛੋਟੇ ਘਟਕ (ਭਾਰੀ ਸਕ੍ਰਿਪਟ, ਨਵਾਂ ਫੋਂਟ, ਵੱਡਾ ਸਕ੍ਰੀਨਸ਼ਾਟ) ਤੇਜ਼ੀ ਨਾਲ ਜੋੜ ਜਾਂਦੇ ਹਨ।
ਕੁਝ ਮਾਪਯੋਗ ਲਕੜੀਆਂ ਨਿਰਧਾਰਿਤ ਕਰੋ ਅਤੇ ਹਰ ਰਿਲੀਜ਼ 'ਤੇ ਚੈੱਕ ਕਰੋ:
ਉਹ ਚੀਜ਼ਾਂ Optimize ਕਰੋ ਜੋ ਯੂਜ਼ਰ ਪਹਿਲਾਂ ਡਾਊਨਲੋਡ ਕਰਦੇ ਹਨ:
font-display: swap ਵਰਤੋ, ਅਤੇ ਸੋਚੋ ਕਿ ਸਵੈ-ਹੋਸਟ ਕਰਨ ਨਾਲ ਤੀਜੀ-ਪਾਰਟੀ ਰਿਕਵੇਸਟ ਘਟਦੇ ਹਨਕੈਸ਼ਿੰਗ ਅਤੇ ਡਿਲਿਵਰੀ 'ਤੇ ਵੀ ਵਿਚਾਰ ਕਰੋ: ਸਟੇਟਿਕ ਐਸੈਟਸ ਨੂੰ ਲੰਬੇ cache headers ਨਾਲ ਸਰਵ ਕਰੋ, ਅਤੇ CDN ਵਰਤੋ ਜੇ ਤੁਹਾਡੀ ਹੋਸਟਿੰਗ ਇਹ ਨਹੀਂ ਕਰਦੀ।
ਸਿਰਫ਼ ਉਹੀ ਡਾਟਾ ਇਕੱਠਾ ਕਰੋ ਜੋ ਲੋੜੀਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਘੱਟ ਟੂਲ ਨਾਲ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹੋ, ਤਾਂ ਕਰੋ।
ਹਲਕਾ ਮਾਨੀਟਰਿੰਗ ਜੋੜੋ ਅਤੇ status page ਲਈ ਲਿੰਕ ਦਿਓ ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਹੈ (for example, /status). ਜੇ ਨਹੀਂ, ਘੱਟੋ-ਘੱਟ ਸਪੋਰਟ ਪੇਜ ਲਈ ਫੂਟਰ ਲਿੰਕ ਦਿਓ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਜਾਣ ਸਕਣ ਕਿ ਕੁਝ ਖ਼ਰਾਬ ਹੋਣ 'ਤੇ ਕਿੱਥੇ ਜਾਂਣਾ ਹੈ।
ਇੱਕ SaaS ਸਾਈਟ ਮਾਰਕੀਟਿੰਗ ਪੇਜ਼ ਅਤੇ ਡੌਕਸ ਨਾਲ ਕਦੇ "ਮੁਕੰਮਲ" ਨਹੀਂ ਹੁੰਦੀ। ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਸੁਧਾਰ ਕਰਨ ਦਾ ਤਰੀਕਾ ਹੈ ਦੇਖਣਾ ਕਿ ਲੋਕ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਵਰਤ ਰਹੇ ਹਨ: ਉਹ ਕੀ ਖੋਜ ਰਹੇ ਹਨ, ਕਿੱਥੇ ਫਸ ਰਹੇ ਹਨ, ਅਤੇ ਕਿਹੜੇ ਪੇਜ਼ ਸਾਈਨਅੱਪ ਚਲਾਉਂਦੇ ਹਨ।
ਇੱਕ ਬੇਸਿਕ site-wide search ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਦੋਨਾਂ ਮਾਰਕੀਟਿੰਗ ਪੇਜ਼ਾਂ ਅਤੇ ਡੌਕਯੂਮੇੰਟੇਸ਼ਨ ਨੂੰ ਕਵਰ ਕਰੇ। ਇਕ ਸਰਲ ਹੱਲ ਵੀ ਕੋਈ ਹੋਣ ਨਾਲੋਂ ਵਧੀਆ ਹੈ—ਖਾਸ ਕਰਕੇ ਡੌਕਸ-ਭਾਰੀ ਉਤਪਾਦਾਂ ਲਈ।
ਇਹ ਲਾਈਵ ਹੋਣ ਦੇ ਬਾਅਦ, ਖ਼ੁਲ੍ਹ ਕੇ search व्यवहार ਨੁੰ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਸਮੀਖਿਆ ਕਰੋ ਅਤੇ ਸਬੂਤ ਦੇ ਅਧਾਰ 'ਤੇ ਟਿਊਨ ਕਰੋ। ਸਭ ਤੋਂ ਵੱਡੀ ਜਿੱਤ “no results” ਕਵੇਰੀਜ਼ ਨੂੰ ਸੋਧਣਾ ਹੈ: ਗੁੰਮ ਪੇਜ਼ ਜੋੜਨਾ, synonyms, ਜਾਂ ਬਿਹਤਰ ਹੈਡਿੰਗਜ਼।
ਡੌਕਸ ਖੋਜ ਮਾਰਕੀਟਿੰਗ ਖੋਜ ਤੋਂ ਵੱਖਰੀ ਹੁੰਦੀ ਹੈ। ਲੋਕ ਟਾਸਕ-ਚਲਿਤ ਅਤੇ ਬੇਸਬਰਦਾਰ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਛੋਟੀ UX ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਮਾਇਨੇ ਰੱਖਦੀਆਂ ਹਨ:
Pageviews ਇਕੱਲੇ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਕੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਉਹ ইਵੈਂਟ ਟਰੈਕ ਕਰੋ ਜੋ ਫੈਸਲਿਆਂ ਨਾਲ ਜੁੜਦੇ ਹਨ:
ਮਾਰਕੀਟਿੰਗ ਅਤੇ ਸਪੋਰਟ ਦੋਹਾਂ ਲਈ ਡੇਟਾ ਭਰੋਸੇਯੋਗ ਬਣਾਓ। ਨਾਮੀਕਰਨ ਲਗਾਤਾਰ ਰੱਖੋ ਅਤੇ ਇਸਨੂੰ ਇਕ ਸਧਾਰਨ ਅੰਦਰੂਨੀ ਪੇਜ਼ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਕਰੋ (for example, /docs/analytics-events)।
ਦੋ ਦਰਸ਼ਕਾਂ ਲਈ ਹਲਕੀ-ਫੁਲਕੀ ਡੈਸ਼ਬੋਰਡ ਬਣਾਓ:
ਫਿਰ ਫੀਡਬੈਕ ਲੂਪ ਬੰਦ ਕਰੋ: ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਸਪੋਰਟ ਟਿਕਟ ਅਤੇ ਆਮ ਖੋਜਾਂ ਨੂੰ doc ਅਪਡੇਟਾਂ, ਨਵੇਂ ਉਦਾਹਰਨ, ਜਾਂ ਸੁਧਾਰੇ ਹੋਏ troubleshooting ਸੈਕਸ਼ਨਾਂ ਵਿੱਚ ਬਦਲੋ। ਸਮੇਂ ਦੇ ਨਾਲ, ਤੁਹਾਡੇ ਡੌਕਸ ਇੱਕ ਸਵੈ-ਠੀਕ ਕਰਨ ਵਾਲੀ ਪ੍ਰਣਾਲੀ ਬਣ ਜਾਉਂਦੇ ਜੋ ਸਪੋਰਟ ਲੋਡ ਘਟਾਉਂਦੀ ਅਤੇ ਕਨਵਰਜ਼ਨ ਵਧਾਉਂਦੀ ਹੈ।
ਛੰਗੀ SaaS ਵੈਬਸਾਈਟ ਲਾਂਚ "ਪਬਲਿਸ਼ ਅਤੇ ਉਮੀਦ" ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਇੱਕ ਨਿੰਤਰਤ ਰਿਲੀਜ਼ ਹੁੰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਚੈੱਕ ਹਨ ਜੋ ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ (ਟੁੱਟੇ ਹੋਏ ਪੇਜ਼, ਗੁੰਮ ਮੈਟਾ ਡੇਟਾ, ਮਰੇ ਹੋਏ ਸਾਈਨਅਪ ਲਿੰਕ) ਨੂੰ ਪਕੜਦੇ ਹਨ—ਅਤੇ ਇੱਕ ਰੋਜ਼ਾਨਾ ਰਿਟੀਨ ਜੋ ਮਾਰਕੀਟਿੰਗ ਪੇਜ਼ਾਂ ਅਤੇ ਡੌਕਸ ਨੂੰ ਢਿੱਲਾ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਕੁਝ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਕ ਪੂਰਾ ਪਾਸ ਕਰੋ ਜੋ ਇੰਜੀਕਟੀ ਅਤੇ ਇੰਡੈਕਸਿੰਗ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦਾ ਹੈ:
ਜੇ ਤੁਸੀਂ ਪੁਰਾਣੀ ਸਾਈਟ ਤੋਂ ਮਾਇਗਰੇਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ old URL → new URL ਦਾ ਸਧਾਰਨ ਸਪ੍ਰੈਡਸ਼ੀਟ ਬਣਾਓ ਅਤੇ ਇਸਨੂੰ ਆਪਣੇ ਰੀਪੋ ਨਾਲ ਰੱਖੋ ਤਾਂ ਕਿ ਭਵਿੱਖੀ ਬਦਲਾਵ اصل ਯੋਜਨਾ ਨੂੰ ਓਵਰਰਾਈਟ ਨਾ ਕਰਨ।
ਸਿਰਫ਼ ਝਟਪਟ ਕਲਿੱਕ ਨਾ ਕਰੋ। ਉਹ "ਜੌਬ" ਟੈਸਟ ਕਰੋ ਜੋ ਮਾਰਕੀਟਿੰਗ ਅਤੇ ਡੌਕਸ ਨੂੰ ਜੋੜਦੇ ਹਨ:
ਇਹਨਾਂ ਨੂੰ ਰਿਲੀਜ਼ ਬਲਾਕਰ ਸਮਝੋ। ਜੇ ਕੋਈ ਫਲੋ ਫੇਲ ਹੋਵੇ, ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਕਨਵਰਜ਼ਨ ਅਤੇ ਸਪੋਰਟ ਵੋਲਿਊਮ ਵਿੱਚ ਅਸਰ ਮਹਿਸੂਸ ਹੋਵੇਗਾ।
Redirects ਸਿਰਫ਼ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਲਈ ਨਹੀਂ ਹਨ। SaaS ਸਾਈਟਾਂ ਲਗਾਤਾਰ ਬਦਲਦੀਆਂ ਹਨ: ਤੁਸੀਂ ਫੀਚਰਾਂ ਨੂੰ ਨਾਂਮਦੇ ਹੋ, ਡੌਕਸ ਨੂੰ ਦੁਬਾਰਾ ਸਰਚਨਾ ਕਰਦੇ ਹੋ, ਅਤੇ ਉਤਪਾਦ ਪੇਜ਼ ਦੁਬਾਰਾ ਲਿਖਦੇ ਹੋ।
ਇੱਕ ਨਿਯਮ ਬਣਾਓ: ਕਦੇ ਵੀ URL ਨੂੰ ਬਿਨਾਂ (a) ਰਿਡਾਇਰੈਕਟ ਕੀਤਾ ਜਾਂ (b) ਇਸ਼ਤਿਹਾਰਕ ਤੌਰ 'ਤੇ 410 ਵਾਪਸ ਕਰਨ ਦੇ ਹੱਟਾਓ ਨਾ। ਡੌਕਸ ਲਈ, ਰਿਡਾਇਰੈਕਟ ਅਕਸਰ ਸਹੀ ਚੋਣ ਹੁੰਦੀ ਹੈ।
ਅੱਗੇ-ਦਿਖਨ ਵਾਲੀ URL ਨੀਤੀ 'ਤੇ ਸਹਮਤ ਹੋਵੋ (ਉਦਾਹਰਨ ਲਈ, ਜੇ ਤੁਸੀਂ ਡੌਕਸ ਨੂੰ ਵੈਰਜ਼ਨ ਕਰੋਗੇ ਤਾਂ URL ਵਿੱਚ ਵਰਜ਼ਨ ਨੰਬਰ ਲੈਣਾ ਬਚਾਓ)। ਇਹ ਭਵਿੱਖੀ ਰੀਫੈਕਟਰਾਂ ਨੂੰ ਛੋਟਾ ਰੱਖਦਾ ਹੈ।
ਲਾਂਚ ਦਿਨ ਇੱਕ ਹਲਕਾ ਯੋਜਨਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:
ਜੇ ਸੰਭਵ ਹੋਵੇ, ਪਹਿਲੇ 24–48 ਘੰਟਿਆਂ ਲਈ ਟੀਮ ਨਾਲ ਇੱਕ “hotfix window” ਖੁੱਲ੍ਹਾ ਰੱਖੋ।
ਇੱਕ ਸਧਾਰਨ cadence ਢਿੱਲਾ ਹੋਣ ਤੋਂ ਰੋਕਦਾ:
ਇੱਕ ਵੈਬਸਾਈਟ ਨੂੰ ਇਕ ਉਤਪਾਦ ਸਮਝੋ: ਲਗਾਤਾਰ ਸੁਧਾਰ ਸ਼ਿਪ ਕਰੋ, ਅਤੇ ਪ੍ਰਭਾਵ ਨੂੰ ਮਾਪੋ.
Start by writing a one-sentence goal that includes both outcomes, like: “Convert qualified prospects while enabling customers to self-serve support.” Then assign each page a primary job:
Most combined SaaS sites serve at least four groups:
If you can’t name the audience for a page, rewrite the page scope until you can.
Use a small set of top-level sections, then keep the rest in the footer:
Global nav should stay marketing-focused; docs navigation belongs in the docs sidebar (Getting started, Guides, API, Troubleshooting).
For most SaaS products, hosting docs under /docs is the best default:
Choose a separate subdomain only if your docs need different tooling, permissions, or a separate maintenance workflow that would otherwise slow everyone down.
Treat URLs as promises:
/docs/sso)/docs/integrations/slack)Plan URL conventions early, especially if you might version docs later.
Ship the pages that answer: What is it? Can I trust it? What do I do next?
Minimum marketing set:
Minimum docs set:
Pick based on who updates content and how often:
A common hybrid: Markdown/MDX for docs + CMS fields for structured marketing content.
Give each key page a primary and secondary CTA, and keep wording consistent:
Use a predictable docs structure and templates:
Standardize a template such as Problem → Steps → Expected result → Troubleshooting so every page feels familiar.
Track behavior that maps to outcomes, not just pageviews:
Review monthly, then turn recurring searches and tickets into doc updates, new troubleshooting entries, and better internal links (e.g., from features to /docs/getting-started and back to ).
Place proof (logos, testimonials, case studies) near decision points to reduce hesitation.
/pricing