Пока три. Но суть проблемы попадания под АГС понятна - экономия на контенте.
Отучаю себя от жадности.. вернее, не.. неправильно сказал. Отучаю себя от принципов скорого заработка и причаю к схеме, общую мысль которой можно выразить следующей фразой - хочешь стабильно зарабатывать на сайте - вкладывай минимум пол года и вкладывай добросовестно.
Любые скороспелки наказываются АГС-ом.
Лично вывел два сайта из АГС. Ключ к решению вопроса - добросовестное наполнение уникальным контентом, терпение и срок. Никаких переписок с Платонами.
Под АГС домены были более полугода.
Хорошая новость! Пожалуйста, огласите перечень изменений, которые были сделаны (на сайте тоже к сожалению, не нашел).
mark3000, спасибо Вам за ответ! Будем ждать комментарии по другим вопросам и, конечно, новых, доработанных версий программы!
Горю желанием купить, но необходимо, в первую очередь, исправить явные ошибки.
Cтоп. Тогда вообще мне непонятно. Если мы знаем URL, зачем тогда нам ее искать в общем перечне?
Если мы знаем целевую страницу - вводим ее в анализ данных и начинаем вести побор нужных страниц для перелинковки. Задача-то в чем?
Я согласен. Мне кажется, то о чем мы сказали выше, вполне хватит на долгие месяцы разработки и внедрения в программу.
anthony_ добавил 30.06.2011 в 15:22
В общих настройках, если стоят все галочки, то внизу опция, чтобы программа не учитывала вес сквозных ссылок. Попробуйте ее снял и проверить, изменится ли картина.
Кстати, по обозначенному выше сайту я через маску закрыл индексацию для нескольких страниц.
Предлагаю, в программе либо вообще не выводить их в результатах анализа, либо подсвечивать, например, серым, как страницы принудительно исключенные из процесса индексации.
Все верно. Но для меня лично были проблемы с индексацией этого сайта и с релевантностью до сих пор возникают проблемы, когда место целевой ранжируется второстепенная, так или иначе я вижу, что проблемы были..
anthony_ добавил 30.06.2011 в 15:31
Такс.. еще важный момент - уже к разработчику.
Сравниваю результат обратотки сайта вашей программой и программой Xenu.
В последнем случае программа видит ошибки (ссылки на страницы 404), ваша программа - не видит. И самое главное, те адреса, которые дублируют главную страницу - эти адрес сформированы вашей программой (т.е. результат неправильной обработки адреса) - программа выводит страницу
http://site.ru/?id_tovar=24, а на самом деле в структуре навигации эта страница называется http://site.ru/xxx_rus.php?id_tovar=24 - т.е. программа каким-то образом усекла адрес и породила новые адреса. Расчитала для эти адресов новый вес и он получился больше, чем у целевых страниц, это довольно серьезно путает. В результате, в программе значится 15 страниц, проиндексированных Яндексом, а в самом Яндексе поисковик находит больше 30-ти. Это, господа, разработчики, косяк, надо исправлять.
Cпустя несколько минут..
Проверил еще один сайт - точно такая ситуация. Программа неправильно обрабатывает адрес и порождает новые страницы. Соот-но, комплексно ей анализировать вообще нельзя :(
Ждем скорейшего исправления!
anthony_ добавил 30.06.2011 в 17:36
Нашел еще одну серьезную неувязку. Объясню на примере конкретного случая. Пришло задание продвинуть сайт по ритуальных услугах по новому перечню ключ. запросов, среди них запрос "бальзамирование". Пробую подобрать релевантную страницу и вижу, что ровно ничего программа мне предложить не может.. все по нулям. Начинаю проверять какие страницы релеванты для этого запроса по Яндексу и вижу, что ПС ранжирует три документа.
1) Страница с фото (текстового вхождения нет, ранжируется по внутреннему НПС)
2) Главная страница (есть слово "бальзамирование" и ссылка на вышеуказанное фото)
3) Второстепенная страница с публикацией, где тоже есть единичное употребление словоформы - "бальзамирования".
Кстати! Первым ранжируется документ именно с внутренним НПС, получается, что он перебивает главную, с прямым текстовым вхождение слова. Проверяю серп, отсекаю все лишние сайты и оставляю региональные - круто, на 4-ом месте ранжируется именно документ с фото по НПС. Вот это я понимаю! Респект Яндексу! Без каких либо натужных перелинковок логически выводит верную страницу! Круто! Ничего не скажешь.. начинаешь по-настоящему ощущать ценность ссылочного проектирования сайта. А большая часть оптимизаторов тупо давит внешним ссылочным из сапы, какое же это продвижение? Это просто ссылочный бомбинг :( Была бы моя воля, я бы вообще вес этот серый ссылочный sape хлам обесценил в минуса, рынок был бы куда здоровЕе. А то понавылезают деятели, за 500 рублей накачивают сайты сапой и пропагандируют "доступное" продвижение, перебивая истиную стоимость работ. Потом клиентские сайты хватают фильтры и прибегают, ай, помогите, мы купили ссылки, а сайт упал. Начинаешь проверять структуру и релевантность - там такой бред от незнания специфики ранжирования, такие перекосы, аж работать не хочется, - сносить все на домене и проектировать структуру сайта заново.
Вернемся к программе. Начинаю разбираться, как так, почему программа ничего подобного мне не показала? Почему ссылку с целевым анкором не нашла, почему, нет еще двух страниц, где употребляется это слово? И понимаю, что касаемо главной страницы, поиск идет по корпусу из 10 часто встречаемых слов по убывающей, и слово "бальзамирование" туда просто не попало (так спроектирована программа). В результате, программа просто не видит этих слов и никакую аналитическую работу, опираясь на программу здесь сделать нелья, - грусто, опять приходится работать с поиском по сайту и все делать вручную, программа в данном случае для меня нефункциональна :(
Вывод - наличие всех слов web документа необходимо программой индексировать, иначе это не инструмент анализа - а морской бой на тетрадном листке. Таких прогрешностей быть не должно.
Ну, соб-но, что могу сказать. Если в общем контенте на многих страницах идет ссылка на вход/регистрацию аккаунта пользователя, то, соб-но, почему бы и нет?
Формально, это технические страницы и их надо закрывать для индексации. Засунул в Disallow: и вопрос решен.
Я вот сейчас проверил в программе один сайт, смотрю треть внутренних страниц имеют вес даже больше целевых внутренних, по которым я проводил анкорную перелинковку и продвижение. Смотрю подробнее, вообще вижу, что эти раздутые по весу страницы - это копии главной. Чей косяк? Мой.. потому что на этапе проектировки не увидел этих страниц. Робот по ним бегает - бегает.. время индексации это занимает - занимает, вес налево уходит - уходит. Значит сейчас по маске все эти страницы в Disallow: а по структуре, надо вносить коррективы во внутренню структуру адресации сайта. Вот программа мне и помогла разглядеть косяк.
С тошнотой - в анализе данных программа подсвечивает кол-во употреблений слов.
Я как раз выше писал об этом, если бы разработчики расширили этот перечень метрик, ну, допустим, до уровня http://advego.ru/text/seo/ - было бы, конечно, здорово.
Внешний ссылочный вес - тоже уже говорил, это очень сложно, ибо связано с парсингом бэков, а это очень ресурсоемкий процесс.
И все равно непонятно. Продвигаемая страница А должна обладать перечнем определенных признаков, как можно в массиве данных искать элемент, который никак не характеризуется кроме того, что он обозначен вами как А.
Это все равно, что - в папке есть 20K файлов. Один из них - А. Как найти тот A, при условии, что этот файл A сам по себе уникален? Как его отличить от остальных - неизвестно.
Я бы так не сказал. Конечно, чем более зрелый сайт, тем дальше те результаты, которые можно получить при программной итерации сайта. Однако, если оптимизатор сталкивается с тем, что при ранжировании в ПС у него часто переназначается страница, то программа поможет выявить неправильную линковку, если она имеет место.
И этап разработки тоже очень важно. У меня считай каждую неделю - новый клиентский сайт на тарифном региональном продвижении. Кажется и работы там неочень, и ссылок там особо не нужно для успешного ранжирования, но по уму все спроектировать и залинковать, чтобы ранжировалось то, что намечено - крайне важно. Сайты разные, большие и маленький, зачастую нет времени, чтобы углубляться в смысловое изучение всех материалов. А с помощью программы сайт проанализировал и уже примерно видишь, где какие вхождения по запросам есть и чего где не хватает.
Не, так мы уйдем в бесконечные дебри умозрительного теоретизирования..
Инструмент помогает решать вопросы проектирования релевантности и линковки, пусть им и остается.
Я согласен с вами, определенный здравый довод в вашем рассуждении есть!
Одно дело общий внутренний ссылочный вес, другое дело внутренний анкорный вес (т.е. какое общее кол-во ссылок ведет на эту страницу и какова их доля по анкорному содержанию).
Я считаю, правильно, это тоже нужно реализовать.
Хотя, опосредованно, в анализе данных видно, по каким анкорам идет линковка. Нужно ли добавить сюда свои метрики - думаю нужно и надеюсь, это будет следующим этапом развития программы.
Давайте попробуем обозначить.
Меня вообще очень радует, что состоялся подробный, обстоятельный разговор, уважемых друг друга оппотентов - это крайне важно для взаимополезного разговора!
И тут тоже с вами согласен! Вы - молодец, задаете правильное направление мысли!
Необходимо, чтобы программа имело несколько режимов - подбирала релевантные страницы и с учетом всех слов в запросе и с учетом запроса целиком (в исходной форме и в вариативных словоформах).
В вашем вопросе - задача с двумя неизвестными. Вы ищете страницу, не зная ее индивидуальных критериев, и хотите потом посмотреть какие ссылки идут с нее. Как же вы хотите, чтобы программа ее угадала? Я лично тоже не понял, что это за страница.
О том, что преимущества веса уходит на страницу с профилем. Происходить это может из-за нарушения общей адресации. Значит нужно смотреть входящие внутренние ссылки на адрес с профилем пользователя и разбираться, почему происходит такой перекос, а главная страница недополучает статический вес.
Совсем нет, к чему такой вывод? Если у вас в итоге ранжируется правильная страница, то по золотому правило seo-шника - "работает, - не трогай!". А вот если вместо целевой морды по запросу "слоны" у вас выходит профиль пользователя - вот вам программы наглядно и демонстрирует, что проблема может быть в распределении статического веса и такого в моей практике было достаточно много.
Ну, дружище, конечно, всех этих условностей программа расчитать не может. Так можно и до выведения общей формулы ранжирования в Яндексе дойти. Программа решает свои узкие задачи.
Есть сайт, у него есть своя структура, программа пробегает по ссылкам и совершает первичную итерацию. В этой итерации накапливаются свои статистические метрики _внутри_ сайта - с ними и работаем, - ни больше, ни меньше. То, что внешнее ссылочное формирует свой анкорный вес и распределяет его по страницам - это дело третье, мы его никак не можем учесть.
А вот то, что я предлагал - сделать сравнение текущего подбора страниц (сравнение релевантности) - с той релевантностью, которая есть в поисковой системе - это необходимо.
Я не тот, кто закидывает камнями, я тот, кто предлагает сесть и спокойно обсудить :)
Конечно, то, что мы сейчас с вами сообща решаем и полемизируем - это очень важный и необходимый этап в развитии программного продукта и автор это, я вижу, отлично понимает!
p.s. Кроме всего прочего, после приобретения программы я планирую написать на своем блоге еще один подробный обзор функциональной значимости программы.
mark3000, спасибо и вам за ваш труд!
Еще ряд вопросов. Вы говорите, что обновления бесплатны в пределах одной версии. Несовсем понятно, а как регулируется линейка версии программы? Допустим, вы посчитаете необходимым каждое обновленное сопровождать выпуском новой версии, как быть? Сориентируйте, пожалуйста, на что можно расчитывать.
Теперь личный вопрос. Я бы хотел приобрести лицензию на два компьютера (на рабочий в офисе и на домашних - для домашних наработок), я могу связаться с вами в личке, чтобы, допустим, через аську решить все орг. вопросы, оплатить напрямую программу и получить два ключа?
С индикацией и демонстрацией данных, понятно, будем привыкать, хотя, конечно, хотелось бы более корректной работы в этом вопросе.
По поводу внешних ссылок. Я лично тоже противник этой идеи, потому что у этой программы своя ниша - работа со статистическими данными целевого сайта. Анализ внешних ссылок - это уже совсем другая история и она будет обязывать вас ко многим других функциональным новшествам. Я не вижу смысла перегружать программу, потому как аналоги для подобных задач есть, например, CS Yazzle.
Лучше направить свои силы в задачи семантической обработки текста, возможно, имеет смысл ввести анализ и выявление дублей контента (например, когда движки типа joomla-а начинают плодить дубли), можно добавить эмуляцию итерации и выводить прогноз накопления ссылочного веса, также имеет смысл добавить генерацию тестовой карты сайты и генерацию sitemap.xml, можно попробовать выводить графическое представление древовидной структуры сайта - тоже было бы очень здОрово. Что еще.. а! можно сделать проверку на уникальность для целевых анализируемых страниц - это тоже первичная и необходимая задача для каждого сеошника. Таким образом, в вашей нише полно теоретически интересных задач, поэтому желаю вам не пытаться охватить все сразу, а сосредоточиться на своей узкий проф. ориентации.
anthony_ добавил 30.06.2011 в 10:47
Линкоскоп :)
Вы неправы :)
Смысл в том, чтобы видеть как распределяется статический ссылочный вес страниц по сайту.
Допустим, запушен новый сайт. Его сделали так, как сделали. У вас как у сеошника стоит задача - продвинуть сайты по запросу "слоны". Допустим, у вас на главной странице нет вообще ничего про слонов, а на внутренних страницах есть такая информация.
site.ru/история слонов.php
site.ru/уход за слонами.php
site.ru/разведение словнов.php
site.ru/болезни слонов.php
Клиент настаивает, допустим, чтобы в серпе ранжировалась страница про разведение слонов, а по умолчанию в области поиска по сайту первой странцией ранжируется "история слонов" - как быть?
Вот загружаете сайт в программу и смотрите, как распределяется статистический вес по эти тематически близки страницам. И видя картину, где какие у вас страницы, проектируете как распределить статически вес страниц, как перелинковать и закрепить результат анкорным весом.
Да. Здесь согласен, господа, обработку редиректных ссылок надо подключить.
Допустим, если я через htaccess принудительно обрабатываю ссылку site.ru/index.php на адрес site.ru - это никакая не ошибка, это техническая склейка!
Так эту функцию программа и выполняет во вкладке анализ данных.
Что значит нет возможности поиска? Если для себя вы знаете какие конкретно страницы хотите подтянуть засчет перелинковки, так и указывайте эти страницы в анализе данных и дополнительно подбираете те, какие второстепенных страницы можно заликновать на целевые.
У любой хорошей программной разработки должна быть качественная перспектива роста и в этой программе она есть. Так или иначе текущую релевантность в ПС определять надо, потому как - какой смысл проектировать релевантность, исходя их статистический метрик программы, если в любом случае каждый ответственный оптимизатор будет сравнивать результаты с теми, что он получает в ПС.
В обозримом будущем - да, а куда деваться-то? Если есть конюктурные требования, должны быть и функциональные предложения ;)
