Онлайн ревюта е един от начините за подпомагане на потребителите при процеса на избор на услуга или доставчик. Все пак никой не иска да работи със такива имащи една или две звезди придружени със съсипващо текстово ревю. А между другото е и инструмент за сладко отмъщение, всички знаем много примери как фирмите изведнъж стават отзивчиви при негативни ревюта из интернета.
Как обаче да се подпомогне писането на ревюта към Google Business Page? Реално след масивните обновления на интерфейса вече това е невъзможно със директен линк и потребителите са затруднени. Сега ще ви покажа как това може да се случи лесно и просто със помоща на Google Maps. За пример ще използваме магазина на нашите приятели от Aloha.bg.
За да изкараме пряк линк ние се нуждаем от 3 неща:
1. Име на страницата/бизнеса
2. ludoCID – цифри
3. LRD – цифри
Проблема обаче е вземането на ludoCID и LRD. Сега ще ви покажа как можете бързо, лесно и просто да ги вземете:
1. Отваряте Google Maps на настолен компютър
2. Намирате името на страницата/бизнеса. Във нашия случай е Aloha Bulgaria. И търсите за него.
3. Отивате където са ревютата и копирате линка.
4. Махате ,1 отзад (може да е и нещо друго) и дописвате ,3,5
5. Успех! Нашия финален линк е следния
https://www.google.bg/search?q=%D0%90%D0%BB%D0%BE%D1%85%D0%B0+(Aloha+Bulgaria),+ul.+%22Pirin%22+77%D0%91,+1680+Sofia&ludocid=1486783925008404561#lrd=0x40aa84ea6165b697:0x14a21e1a3be31051,3,5
6. Резултат от посещението на горния линк
Трик N:1 – горния линк можете да го залепите нейде из футъра на сайта със някаква интересна картинка „Напишете ни ревю във Google“
Трик N:2 – линка също така може да бъде скъсен със използване на goo.gl и да се закачи един Analytics Event за отчитане на кликовете към него.
ВАЖНО: Моля не използвайте този метод за лоши цели. Видовден винаги идва!
WordPress е много хубава CMS система и работи out-of-box. Но за да работи още по-добре се слагат разни плъгини, уиджети, модули и други благинки. Сега ще ви покажа как 2 перфектни и много известни плъгини се сбиват и правят живота ви със една идея по-труден дори при генерирането на един прост sitemap. От дълго време ползвам W3TC както и Yoast SEO. И двата плъгина са лидери във своята област и всекидневно се използват от милиони блогове. За съжаление има малка уловка при тях която се отразява на XML sitemap-a.
От известно време забелязах че сайтмапа ми веднъж се появява така:
друг път така:
Поради липса на време (и интерес) не обърнах внимание защо и как се получава това. Отделно роботите продължават да ми посещават сайта без проблем, все едно няма такъв. Обаче има проблем: веднъж когато работи сайта ми връща text/xml, друг път text/html. В момента работя разни неща за проверка на sitemap и не ми трябва просто някакъв сайтмап, ами ми трябва перфектният сайтмап.
След 30 минутно разследване се оказа че когато съм логнат винаги виждам нещата перфектно независимо колко пъти ги презаредя. Когато изляза и почистя W3TC кеша ги виждам перфектно веднъж като xml, след което при презареждане ми се сервират html файлове. Което е сигурен признак, че проблема е нейде във W3TC.
Малко предистория
W3TC има няколко режима на работа от които на мен най-ми харесва Disk: Enhanced. Във този режим готовите страници се записват на диска и със няколко ловки пренасочвания със .htaccess или nginx правила се достъпват. Това е един от най-добрите режими защото веднъж след като WordPress и PHP генерират страницата повече не се изпълнява нито ред код от тях. На практика дори WP/PHP не знаят че страницата е достъпвана след като я генерират. Единственния вариант да се достъпи е когато човек се логне или когато кеша се инвалидира. Другия вариант е Disk: Basic, но там веднъж след като се генерира страницата и се записва после достъпа пак минава през WP/PHP. Там плюса е че не се извикват всички плъгини и модули за целта и направо се връща готовата страница. На практика плъгина Hyper Cache Extended на Marto Lazarov прави същата функционалност. Другия подобен плъгин е WP Super Cache на Donncha O Caoimh, но той е малко по-комплексен и съчетава едновременно Basic и Еnhanced.
Сега Disk: Enhanced след като генерира файла го обслужва със серия правила за web server-a. Но проблема е че по дефиниция той приема че всички кеширани файлове са text/html докато във моя случай трябва да връща text/xml. За да бъде хаоса пълен тези файлове не съществуват физически на диска а WordPress ги виртуализира през едно негово API. Yoast SEO ги генерира от базата данни и ги връща на клиента. Затова и W3TC ги прихваща.
Разбира се W3TC има правила при които може да се изключи файл от кеширането. При мен просто във Performance -> Page Cache -> Never cache the following pages:
При вас разбира се може файловете малко да се различават. Затова отворете sitemap_index.xml и добавете във горния списък необходимите файлове.
Разбира се всичко зависи от настройките на плъгините и на практика ставате жертва на обстоятелствата. И двата плъгина работят чудесно по отделно, но при определени настройки нещата се чупят когато са заедно. Разбира се това работи във моя случай. Обаче ако сте активирали минифицирането и конкатинирането на файловете е напълно възможно също да счупите генерирането на сайтмап.
Извода е, че колкото по-голям и комплексен е даден плъгин толкова по-голяма е вероятността да повреди нещо друго. И винаги проверявайте какво се случва след плъгините. Понякога малки и незначителни на вид неща имат катастрофални последици.
Днес докато разглеждах сайта на доставчика ми (Networx) от мобилно устройство за да открия тарифата за безжичен интернет забелязах че докато зарежда за части от секундата видях текст „стоматолог в русе“. Но когато страницата се зареди вече нямаше такъв текст. Разбира се любопитството ми проработи и когато седнах на компютър направих нова проверка.
Резултата беше категоричен. Линк има във кода:
Но във DOM линка изчезва:
Тук вече любопитството ми заработи на пълни обороти. Има няколко начина да се скрие линк като се направи невидим – като се сложи за цвят цвета на фона, като се направи със много малък шрифт, като се скрие зад друг елемент и още няколко подобни похвати описани по-подробно на линка тук. Разбира се описано е много добре:
Hiding text or links in your content to manipulate Google’s search rankings can be seen as deceptive and is a violation of Google’s Webmaster Guidelines.
Понеже Google не са всемогъщи те имат една форма за подаване на сигнал към екипа за уеб спам която се намира тук. Разбира се никой не е открил топлата вода. Подобни условия имат Bing и Yandex
Но това са разни CSS похвати които са сравнително лесно може да се открият. Във моя случай текста просто изчезваше което говореше за използване на JavaScript код. За щастие целия текст е обграден от един span елемент с много специфичен идентификатор което предполага използването му за почистването. Тук вече късметът ми изневери малко. Сайта имаше 20 JS скрипта и 11 CSS файла и не ми се търсеше всичко файл-по-файл. За мое щастие във инструментите за разработчици има възможност да се търси текст във всички файлове. Така лошия код много лесно беше разгадан:
Хмм… Разгледах няколко страници от сайта им и на всички намерих горния код. На пръв поглед изглежда някой е хакнал моя интернет доставчик като му е сложил 4 реда нейде из WordPress темата. Една проверка във OpenSiteExplorer за линка показа, че и още един сайт има същия линк: Проблема е че RuseNews също е на Networx и изглежда и той беше пострадал. Втория проблем е, че OSE работи доста бавно за откриване на нови линкове поради специфика на самия инструмент. Затова една бърза проверка във OpenLinkProfiler разкрива малко повече подробности:
Явно не само Networx са пострадалите от тази линкбилдинг техника. Уви тази техника е непозволена и може да доведе до наказания на всички сайтове участващи във схемата. Аз няма да рапортувам сайтовете във тази порочна схема, но не мога да гарантирам че някой читател няма да направи това. Освен това нарочно използвам снимки за да не им правя неволен линкбилдинг.
Затова винаги си проверявайте сайтовете през някакъв период от време за изходящи и входящи линкове. Понякога няколко минути работа може да доведат до резултати многократно надхвърлащи очакванията.
Сега ще ви покажа как можем да проверим дали даден домейн не е изключен от системата за реклами Google AdSense без да кандидатстваме. Разбирате, че това е доста полезно ако планирате да закупите домейн и искате да проверите историята му, без да го закупувате. Досега видях как IsBanned.com и няколко други сайта могат да покажат тази информация и ми е било чудно как я достъпват. Разбира се те няма как да се знаят всички домейни на света както и всички блокирани домейни, това могат само Google да го знаят. Значи все пак има някакъв начин.
Въоръжен с малко доза самоувереност намерих едно извикване към кода за рекламите което на стандартен сайт изглежда така:
Ако го извикваме през curl горния линк връща някакви реклами, както и 200 OK което е сигурен признак че домейна не е блокиран дори и да няма пуснати реклами в момента на него. Нека сега да проверим един „лош“ домейн който е бил наказан. В горния линк редактираме всички обръщения към http://peter.nikolow.me и ги заместваме със http://www.budo-zone.com/. Линка придобива следния вид:
При извикването му вече получаваме код за грешка: 403 Forbidden. Това е сигурен признак, че домейна е бил блокиран от системата на Google AdSense.
Кода връщан от сървърите може да се провери по няколко начина. Един от най-лесните е да се използва FireBug при Firefox. Ако използвате Safari/Chrome може да се провери при използването на Develop при единия и Developer Tools при другия. Феновете на Opera могат да използват DragonFly за целта. Ако все още ползвате Internet Explorer можете да използвате ieHTTPHeaders или Fiddler. Разбира се това е лесния начин.
Далеч по-елегантния подход е да се използва curl или wget за целта. Няма нужда от научни степени за използването им. При curl трябва да се напише curl -I „URL“ (кавичките не са задължителни, но при адреси използващи поне един амперсанд & се стартират фонови процеси във *nix което чупи линка и прави задачата неизползваема). За wget може да се използва следния начин за извикване wget -v „URL“ (и тук важи предходния коментар относно амерсандите &).
Разбира се това е само начин за една проста проверка дали домейна е със забрана за показване. Съществуват 2 основни причини за забрана на рекламите – invalid activity и policy reasons. На този адрес Top reasons for account closure можете да проверите какви са разликите между тях. За съжаление и двата типа причини за забрана са заради груби нарушения и не може да се определи кое е по-малкото зло. Ако домейна ви е със забрана за обслужване на реклами поради „policy reasons“ можете да поискате преразглеждане на забраната ако попълните заявка на следния адрес: Policy Violation Appeal. Изключително важно е преди попълването на молбата да проверите дали сайта ви отговаря на всички критерии за програмата намиращи се AdSense program policies както и на официалния им блог Inside AdSense. Важно е защото молбата ви ще бъде преразгледана само един единствен път! Всички останали молби ще бъдат директно отказвани със мълчалив отказ. Ако причината за забрана ви е „invalid activity“ то можете да се опитате да си вдигнете забраната като попълните тази молба: Invalid Activity appeal.
Защо това е важно? Ако преди трябваше да се покаже отделен и специфичен пост във сайт се използваше добре познатата техника – изрязан screenshot което водеше до неудобство при изтрити, променени или обновени постове. В момента ще можете директно да вмъкнете поста във сайта като всеки клик върху поста ще доведе до съответното действие – харесване, коментар или споделяне.
За момента услугата е активна на определени акаунти, но горния код е универсален и позволява използването му и за такива където услугата все още не е налична. Единственния проблем е, че линка във <fb:post&gr; трябва да се дописва на ръка което е известно неудобство.
