I would gladly buy the pro version of this if i thought it would significantly benefit my site but I'm struggling to see why this is currently better than VBSEO. Can you sum it up for me (and all the other potential customers) please? Because most of the features seem to be present in VBSEO too. Is it the canonical URLs feature which is supposed to be the big draw to this product?
Pre-sales question: why change from VBSEO to this?
- Status
The main "feature" is the fact that this product is supported. There exists vBSEO exploits that have not been patched, and with no support for that mod, it's a security risk to run it.
That's not to say that I can guarantee DBSEO is 100% free from exploits, but if we receive a report regarding an exploit, we will patch it immediately and send out a security advisory to all our members / release the fix on vB.org.
Secondly, when we switched from vBSEO to DBSEO on this forum (very very early Alpha), we noticed a 33% reduction in resource usage and page load times on forum.php. Other users have reported either no negative impact, or a positive impact on their performance. The one instance where DBSEO performed worse than vBSEO has since been corrected.
Thirdly, and this is somewhat related to point No.2, DBSEO focuses on core SEO features rather than adding extra bloat. We've also opted not to include vBSEO features that are no longer relevant in today's market, such as trackback/pingback. There used to be a time where blogs reblogging your content meant increased search engine rankings, but this is no longer the case. Today, having your content shared to social media sites is what will work for you, due to it not really being possible to automate sharing content to social media sites.
In summation: DBSEO is under constant development, is more secure, may perform better depending on your specific setup, features today's relevant SEO features and doesn't contain features that do more harm to your SEO than good.
That's not to say that I can guarantee DBSEO is 100% free from exploits, but if we receive a report regarding an exploit, we will patch it immediately and send out a security advisory to all our members / release the fix on vB.org.
Secondly, when we switched from vBSEO to DBSEO on this forum (very very early Alpha), we noticed a 33% reduction in resource usage and page load times on forum.php. Other users have reported either no negative impact, or a positive impact on their performance. The one instance where DBSEO performed worse than vBSEO has since been corrected.
Thirdly, and this is somewhat related to point No.2, DBSEO focuses on core SEO features rather than adding extra bloat. We've also opted not to include vBSEO features that are no longer relevant in today's market, such as trackback/pingback. There used to be a time where blogs reblogging your content meant increased search engine rankings, but this is no longer the case. Today, having your content shared to social media sites is what will work for you, due to it not really being possible to automate sharing content to social media sites.
In summation: DBSEO is under constant development, is more secure, may perform better depending on your specific setup, features today's relevant SEO features and doesn't contain features that do more harm to your SEO than good.
Thanks for the helpful reply.
But surely there is more room to improve on VBSEO. A lot of things have changed since VBSEO was last updated, you mentioned the redundant pingback features but as you know there are others. For example VBSEO does nothing whatsoever to help forum images be found in Google image searches, and that is a big omission in my opinion.
But surely there is more room to improve on VBSEO. A lot of things have changed since VBSEO was last updated, you mentioned the redundant pingback features but as you know there are others. For example VBSEO does nothing whatsoever to help forum images be found in Google image searches, and that is a big omission in my opinion.
That's why DBSEO isn't "final" 
Specifically related to images, we have to be careful not to introduce features that are too performance intensive. If at all possible, we want to avoid features that require a Dual CPU with 24GB of RAM in order to handle the same amount of users that can otherwise be handled on a shared host. Obviously hyperbole, but you get my point.
Specifically related to images, we have to be careful not to introduce features that are too performance intensive. If at all possible, we want to avoid features that require a Dual CPU with 24GB of RAM in order to handle the same amount of users that can otherwise be handled on a shared host. Obviously hyperbole, but you get my point.
- Status
Similar threads
- Locked
- Support ticket
