WordPress SEO – The Definitive Guide 2016

->SEO
-> 2016

pick only 1


Относно това за friendly URL, препоръчвам да е /%ID%/%postname%/ с цел speed, отколкото PURE post-title.

/ credits към @Noke , преди няколко години го беше пускал като съвет и го спазвам и досега.
 
ReminD каза:
->SEO
-> 2016

pick only 1


Относно това за friendly URL, препоръчвам да е /%ID%/%postname%/ с цел speed, отколкото PURE post-title.

/ credits към @Noke , преди няколко години го беше пускал като съвет и го спазвам и досега.
Увеличете...
Как е по - добре? Не разбрах съвсем.
 
Първо ИД-то, за да се търси в дб-то по-бързо, след това тайтъла, ако има много постове ще е бавно сещаш се, по-бързо се търси по ИД отколкото по тайтъл. Може и дата, ако е блог, по-семантично е и готино на вид и прегледност.


Пример

mnogo-gotin-sait.com/2332/Mega-super-gotin-blog-post
 
Id и title към един и същ запис ли водят? Това е за wordpress нали? Питам с образователна цел. При мен си ги правя по друг начин. статична/статична/динамична/статична примерно. Като статична ми е страница главно с текст, а динамична е да кажем продукт или пост.
 
ReminD каза:
Първо ИД-то, за да се търси в дб-то по-бързо, след това тайтъла, ако има много постове ще е бавно сещаш се, по-бързо се търси по ИД отколкото по тайтъл. Може и дата, ако е блог, по-семантично е и готино на вид и прегледност.


Пример

mnogo-gotin-sait.com/2332/Mega-super-gotin-blog-post
Увеличете...
Примерно в mnogo-gotin.sait.com има 100 поста. Тоест има 100 ИД-та , както и 100 тайтъла. Защо по едното да търси по бързо от другото ? Ако въобще има някаква разлика , тая разлика трябва да е пренебрежително малка.
 
BurnX каза:
Примерно в mnogo-gotin.sait.com има 100 поста. Тоест има 100 ИД-та , както и 100 тайтъла. Защо по едното да търси по бързо от другото ? Ако въобще има някаква разлика , тая разлика трябва да е пренебрежително малка.
Увеличете...
Ако правиш някакви мурафети с лайк, по ид наистина е по бърза заявката уникален/праймъри/инт.
 
BurnX каза:
Примерно в mnogo-gotin.sait.com има 100 поста. Тоест има 100 ИД-та , както и 100 тайтъла. Защо по едното да търси по бързо от другото ? Ако въобще има някаква разлика , тая разлика трябва да е пренебрежително малка.
Увеличете...
Ами 100, 100, ами ако са 10 000?
Иначе
MySQL is faster when working with integers, and furthermore faster when working with an integer in which has and index
Увеличете...
. Знанията ми по MySQL на този етап ( казвам на този етап, понеже я изучвам все още ) са колкото да си правя прости заявки или някакви join, CRUD операции, но със сигурност компютрите се оправят много по-бързо с търсене по integers ( числа ), отколкото стрингове. При 100 поста може и да няма значение, но ако е аутоблог или нещо с много публикации, ще се види разликата между query със стринг и INT.
 
ReminD каза:
Относно това за friendly URL, препоръчвам да е /%ID%/%postname%/ с цел speed, отколкото PURE post-title.

/ credits към @Noke , преди няколко години го беше пускал като съвет и го спазвам и досега.
Увеличете...
Повярвай ми това ти е последното нещо, за което да се притесняваш с WP.

ReminD каза:
Ами 100, 100, ами ако са 10 000?
Иначе
. Знанията ми по MySQL на този етап ( казвам на този етап, понеже я изучвам все още ) са колкото да си правя прости заявки или някакви join, CRUD операции, но със сигурност компютрите се оправят много по-бързо с търсене по integers ( числа ), отколкото стрингове. При 100 поста може и да няма значение, но ако е аутоблог или нещо с много публикации, ще се види разликата между query със стринг и INT.
Увеличете...
А сега малко научно опровержение на градските легенди

10М заявки
Код: 
SELECT BENCHMARK(10000000, (SELECT ID FROM wp_posts WHERE ID = X) );
1 row in set (0.37 sec)

SELECT BENCHMARK(10000000, (SELECT ID FROM wp_posts WHERE post_name = 'XXXXXXXX') );
1 row in set (0.36 sec)
100М заявки
Код: 
SELECT BENCHMARK(100000000, (SELECT ID FROM wp_posts WHERE ID = X) );
1 row in set (3.61 sec)

SELECT BENCHMARK(100000000, (SELECT ID FROM wp_posts WHERE post_name = 'XXXXXXXX') );
1 row in set (3.55 sec)
Тестовете са пуснати върху база с 26К записа във wp_posts.

Извод при търсене с = по индексирано поле няма голямо значение, дали е BIGINT или VARCHAR.

Виж ако се използва LIKE е съвсем друга бира.
 
Torbalan Trolski каза:
Повярвай ми това ти е последното нещо, за което да се притесняваш с WP.


А сега малко научно опровержение на градските легенди

10М заявки
Код: 
SELECT BENCHMARK(10000000, (SELECT ID FROM wp_posts WHERE ID = X) );
1 row in set (0.37 sec)

SELECT BENCHMARK(10000000, (SELECT ID FROM wp_posts WHERE post_name = 'XXXXXXXX') );
1 row in set (0.36 sec)
100М заявки
Код: 
SELECT BENCHMARK(100000000, (SELECT ID FROM wp_posts WHERE ID = X) );
1 row in set (3.61 sec)

SELECT BENCHMARK(100000000, (SELECT ID FROM wp_posts WHERE post_name = 'XXXXXXXX') );
1 row in set (3.55 sec)
Тестовете са пуснати върху база с 26К записа във wp_posts.

Извод при търсене с = по индексирано поле няма голямо значение, дали е BIGINT или VARCHAR.

Виж ако се използва LIKE е съвсем друга бира.
Увеличете...
Всичко е вярно. Затова се мисли преди да се подходи по даден път. И все пак рядко ще се случи да имаме 1М записа. Хубаво е обаче да сме подготвени.
Пример: Работих в една фирма преди време. Там имаха дървовида структура, само че без пари до 3то ниво :), с всяко следващо ниво надолу се плаща и се пишат едни кръпки. Пълен смях не бяха чували за рекурсия...
 
Some might say, hey, just use the year or the year and month! That's cool, go for it. I like that for the most part. Some people feel super strongly that having the date in the URL is vital since it gives people information about when the article was published. I don't feel that strongly. I think that information is vital but it's more important it's visible on the page itself. SEO expert (not kidding, he's the man) Joost De Valk told me dates in the URL's can kill clickthrough rates on Search Engine Results Pages since the content can look old before they even see it.

Personally, I've opted to start my URL's with /%post_id%/ then also use /%postname%/. It looks a little weird maybe, but I don't overly mind it. Performance is more important to me.

What can WordPress (the project) do?
I'd vote that on the Settings page for permalinks, it should at least have a sentence like "It is not recommended that you begin your permalink structure with /%category%, %tag%, %postname%, or %author% for performance reasons."

What about me?! I use /%postname%/. What should I do?
The thing to consider is how many pages you have now, and how many pages you might ever have. If you are pretty sure you'll have very few, like under 20 pages EVER. Then whatever, I think you are probably fine with that structure. If you think you might have more than that, I think you ought to change now before it becomes a problem. Consider one of the date based structures or starting with the %post_id%.
Увеличете...
 
PAGES е ключовата дума поради спецификата rewrite rules във WP. И това е за да се избегнат 404 грешки най-вече.

Иначе всички неща приключват с някое от тези Rewrite Query според структурата на пермалинковете
Код: 
/%category%/%postname%/
category_name=<CAT>&name=<SLUG>
Код: 
/%post_id%/%postname%/
p=<ID>&name=<SLUG>
Код: 
/%category%/%postname%//%post_id%/
category_name=<CAT>&name=<SLUG>&p=<ID>
Няма никакво значение дали ще започнеш с ID или ще завършиш с него. все ще си имаш p=<ID> в Rewrite Query-то.

А както се вижда от бенчмарковете SQL заявките нямат някаква фрапираща разлика, дали ще се търси по ID или post_name. Така, че дали ще включиш %post_id% в пермалинка няма кой знае какво значение за performance.

Отделно както казах в предния си пост последното нещо, което трябва да те притеснява относно скоростта на WP сайт с какви точно rewrite rules са реализирани пермалинковете.
 
Благодаря @Torbalan Trolski . Сега имам малко яснота по WP. Не, че ще започна да се занимавам с тази платформа, но от информативна гледна точка е добре.
 
Трябва да си влезнал или регистриран, за да отговориш тук.

Горе