Колко посещения са нужни за успеха на сайт?
Нужно ли е да имаме много посещения, за да е успешен сайтът ни? В тази тема ще изкажа моите виждания по този въпрос. Защото за повечето уебмастъри посещенията са главното мерило за успеха на сайта им. Според мен многото посещения може да са също толкова вредни и пагубни, колкото и липсата на такива.
Безспорно един сайт трябва да има трафик, за да се развива. Но според мен е важен не обемът на трафика, а качеството му. Важно е и от къде идва този трафик, защото примерно социалните мрежи генерират много трафик, но той трудно се монетизира и хората от там трудно се задържат за читатели.
За мен за едни сайт е най-важно той да получава най-много трафик от търсачките и този трафик да е по основните му ключови думи/фрази. Разбира се, от това следва, че е важно думите от тематиката на сайта да са търсени и това търсене да се държи на ниво. Тоест, да не е временно и да не намалява с времето.
Размерът на трафика е от значение, само ако е таргетиран и носи печалби. В противен случай просто излишно си товарим хостинга, цената за поддръжка на сайта се вдига, а приходи няма. Затова е важно не просто да се борим за трафик, а да се борим за таргетиран трафик. Същото се отнася и за връзките.
Пиша всичко това, защото имам сайт със сериозен брой уникални посещения дневно, който от около година не генерира приходи. Но потребителите му се увеличават експоненциално ежедневно, тъй като те сами си генерират и управляват съдържанието. Това е Web 2.0, какво да се прави :)
В моя случай сайтът стартира с определена аудитория потребители, които бяха ограничени, но си генерираха определени печалби. В последствие, след преминаването на Web 2.0, аудиторията се измени постепенно и в момента е десетократно по-голяма, но вече не е от целевата възрастова група.
Изводът: Броят на потребителите не е еднакво мерило за успеха на всички сайтове. Един сайт с 20 уникални на ден може да е много по-успешен от такъв с 2000, разбира се, ако потребителите му са таргетирани. Всичко зависи от тематиката и до колко печеливша е тя. При мен най-много печелят малките сайтове.
Оптимизация на динамични сайтове и скриптове
Не, този път няма да пиша за SEO оптимизация, както обикновено, а за един друг вид оптимизация, която пренебрегваме още по-често – оптимизацията на кода на даден сайт или скрипт. Тя е също толкова важен елемент от успеха на един сайт, колкото е и SEO оптимизацията.
Повечето хора си качват сайтовете на така популярния и удобен „споделен хостинг“. Но този хостинг е споделен и трябва да се спазва определена култура, когато се използва. Различните сайтове използват споделени ресурси и когато един сайт товари повече и заема повече памет, то това се отразява на всички други.
Рядко се налага един сайт да има толкова много потребители и изчислителни нужди, че да се наложи да работи на VPS или на собствен сървър. Последните ми разработки около referring sites скрипта ми доказаха, че един сайт с много изчисления и потребители може да се оптимизира и да хаби ресурси колкото обикновен блог.
Хората рядко мислят за оптимизация на програмите си. В днешния свят на постоянно развиващи се технологии, сякаш може с малко по-скъп хардуер да се подкара всяка една програма. В същност не е така – когато даден сайт започне да прави значителен брой посещения – тогава проблемът с ресурсите може да се реши само чрез оптимизация на скриптовете му.
Ето и някои основни принципи, без да се задълбавам:
1. Използване на функции, изискващи по-малко ресурси.
Примерно в PHP е много по-ефективно да се използват функциите strpos() и strstr() за търсене на низ в текст, отколкото функцията preg_match(). Последната е проектирана за регулярни изрази и заема много повече памет и ресурси. Проверявайте за всяка функция какво прави и дали няма по-добра алтернатива.
2. Минимизиране на връзките към базата данни.
Това може би е най-често срещания проблем при разработка на уеб скриптове – големият брой връзки към базата данни. Често начинаещите програмисти извикват връзка всеки път, когато им е нужна дадена информация. В повечето случаи има начин необходимата информация да се вземе предварително и наведнъж, и да не се занимава допълнително SQL сървърът.
3. Използване на индекси (кеширане) на SQL ниво.
Повечето системи за обработка на бази данни, като MySQL, поддържат така нареченото кеширане на колони. То е полезно, когато ще търсим в дадена колона или ще сортираме по нея. Примерно, ако имате колона client и често Ви се налага заявка от вида: „SELECT * FROM clients WHERE client LIKE ‘%Ivanov’“, то добавете индекс към client.
4. Кеширане на информация с цел избягване на повторни заявки
Става въпрос за класическото кеширане, при което примерно създаваме отделен HTML за всяка страница и го качваме на сървъра. При следващо извикване на съответната страница, не товарим базата данни със заявки, а просто зареждаме кешираното копие. При промени в скрипта, всичко се кешира на ново, което е много по-оптимизиран процес.
5. Използване на бази данни в трета нормална форма
Това е малко по-сложно за кратко обяснение, но идеята е да има повече малки таблици с външни ключове между тях. Целта е да се избягват служебно празни полета и/или повтаряне на данни в дадена колона. Така се пести място и многократно се ускорява работата на системата. В MySQL външни ключове се правят при основа InnoDB.
6. Използване на PHP или сървърния скрипт само където е необходимо
Може цяла една HTML или друга страница да се генерира чрез PHP, примерно, но това изисква много повече функции и ресурси. Изглежда и по-сложно. Затова сървърният скрипт трябва да се използва само там, където наистина има нужда от него. Примерно, за изписване на текст не е нужно да викате echo „Ала бала“;, а е достатъчно да си напишете текста.
7. Избягване на типове като BLOB в SQL системата
Много често с цел улесняване на дадена задача, ни е по-лесно да качим дадена снимка или видео директно в базата данни в бинарна форма. Това обаче е страшно натоварващо за системата. Много по-ефективно е да качим снимките/видеотата в директория и в базата данни да пазим само връзки към тях. А BLOB се използва само когато няма друг начин.
Това са основните моменти, за които се сетих. Разбира се, няма как да съм изчерпателен. Оптимизацията си е цяло едно изкуство, но винаги може да се оптимизира повече. Въпросът е къде е разумната и приемлива граница. Чрез избягването на най-често срещаните грешки се вдига ефективността многократно. Тук описах повечето от тях.
Преструктуриране на сайт (блог)
Вчера реших да преструктурирам два мои блога, защото връзките на статиите им не ме удовлетворяваха. Единият сайт беше много известен и посещаван, другият е този. Подобна промяна ми се струваше рискована, защото първият сайт имаше няколко статии, които се класираха много добре с ключовите си думи.
По принцип в такава ситуация се пренасочват старите връзки с грешка тип 301 към новите, но в първия случай това нямаше как да стане, защото връзките бяха на кирилица. Поне аз не успях да подкарам Apache-то да ги захапе и да ги пренасочи. От друга страна, публикациите в блога бяха прекалено много и ме чакаше голямо писане.
Какво направих: и в двата блога влязох в съответния контролен панел на Wordpress за управление на връзките и просто ги промених както аз ги искам. Качих и нови карти sitemap.xml на сайтовете и започнах да чакам. 24 часа след това установих, че при първия блог над 80% от старите връзки ги нямаше и бяха заменени с новите им еквиваленти.
При текущия блог положението е по-лошо, просто защото още не е разработен и бота на Google не стои постоянно тук. Но като цяло е впечатляващо за колко малко време се индексираха новите структури и изчезнаха старите такива. Даже статиите, които се класираха добре в първия блог си бяха на мястото в SERP-а с новите си адреси.
От всичко това си правя извода, че от Google са усъвършенствали системите за откриване на дублирано съдържание и оценяване кой е първоизточника и кое е копието. Това като цяло е добре, когато се отнася за преструктуриране на сайтове. Но дали няма да даде предимство на тези, които копират съдържание?
Примерно имаме блог, който бива копиран от някой друг сайт (блог). Ако от нашият блог поради някаква причина изчезнат статии или си сменят адресите, то дали няма за първоизточник да бъде обявен сайтът, който ни копира? Да се надяваме, че от Google са предвидили ситуацията и това не се случва.
