Hi kguske
Just wondering out loud if/when there are any plans for a next version of nukeSEO?
I know there was a consnsus of opinion of the need for dynamic meta tags on a per module basis (assuming a per page basis is too complex at this stage) but wondered where/what you were up to on this specific area of increased functionality?

I ask because I have located what appears to be a nifty little class file to create dynamic met tags on the fly based on page word count and other criteria.
I was going to have a play with it but I do not want to waste time with that if you are already making inroads in that direction for nukeSEO.

Dynamic meta tags (or, meta tags by module / page) are definitely on the list for the next release. As I'm over the major humps in my real jobs through the end of the year, I will focus on it now. It's possible that nukeFEED will come first, but part of that will be used in the next release of nukeSEO.
_________________

I would like to suggest also XHTML compliance, which should also help with fixing issues with special characters?

I have been working on getting to XHTML compliance now on my site since I'm using RavenNuke 2.1.0 latest and am almost there with Sitemap, but the special characters are causing me to get a headache.

I tried using htmlspecialchars() around the title tags, but I think a generalized function is really going to be needed as I am finding some of the data is already properly "encoded" and then to throw on it another "encoding" screws it up. But, it really is data driven.

Maybe a minor release is in order? (I know, I know, that is the pot calling the kettle black - think HTML Newsletter...lol)

Already working on the XHTML compliance - seeing how NICE the test version of RN210 looks gave me some encouragement! Thanks for your major efforts on that!

I've been doing some significant work with how things are formatted, which should address the special characters issue. I'd definitely appreciate suggestions for testing, so any scenarios you have are most welcome.

I tried to post from work earlier, but kept timing out (most likely our internet Nazi's keeping me from doing so - lol).

I'd say give RN 2.1.0's backend.php and forumsbackend.php a look-see. There is a function in there that might be useful?

Most of the issues that I have noticed are with the special characters in the link title attributes, such as the " and & characters. These are no-no's in XHTML-land. Strangly enough, I even had an issue with the "&" within the data between the link anchor tags. Again, I think backend.php might help with that with the use of CDATA...

If you ever want me to test anything against my site's data, just shoot me a copy and I'll give her a go.

I'll take a look, thanks! Don't forget all the stuff I've been doing with nukeFEED. I found several interesting limitations / issues with backend and wrote a function for nukeFEED that will be used in the sitemap (and other places, of course!). But it won't hurt to look at what's been enhanced in the RN files.

Nah, you're right. I had forgotten! Yes, doing nukeFEED would force you to have to address all these issues. Very cool.

About time we had a low down on what nukeFEED will do ...

Bumping because I can and I have another consideration, provided the recipe is not already baking in the oven.

As well as using nukeSEO I have also been testing other stand alone tools, some of which have been mentioned in other threads on this site.

Through this testing I may have uncovered a fundamental flaw in most sitemapping software. Well its not actually flaw as it does what it is designed to do but please read on...

There are some area's of phpNuke and its derivatives as well as other content management systems that have open public links to area's which may not have public access.

To use an example; a forum which is set for registered user access (using the forum admin tools) has open public links to functions for reply, quote and post topics, view member profiles etc.
A sitemap will crawl and log these links, quite correctly, as that is what a sitemap tool is designed to do, however, problems arise when these 'mapped' links are subsequently indexed as visiting these links will generate messages. Depending on your phpNuke configuration you may get an 'access denied' or 'this module is not active' or with my own site, where some none registered user accesses an area they are not permitted in, a 403 error.

Obviously the 'flaw' in this case (phpNuke) is a poorly designed forum system that permits visible links to area's which require something other than 'anonymous' access but it would be extremely useful if the next version of nukeSEO allowed some sort of user defined 'list' so that links that contained specific strings did not get mapped.

Most third party mapping software will let you do that but it is rather a tedious process. With something like nukeSEO, if it had this sort of functionality, users could share their 'exclusion lists'.

Edited by G to correct a typo

Interesting coincidence - I am currently working on the sitemap... My thought, however, was to not map things which can't be seen by the viewer. In other words, if an authorized member looks at the sitemap, (s)he should see all links. If a search engine looks, it should not see the links. If the sitemap can do that, why have the extra overhead of checking a table to see what should be excluded? (of course, the existing ability to exclude an entire content type / module from the sitemap will be retained).

But first, a little tweak to make the HTML sitemap expand and collapse...

Hi,

I'm wondering if the next version will adapt to the renamed admin.php and config file. For added security I changed it to something else but it doesnt change for NukeSEO so I returned it to admin.php which is not such good idea

Thnx n keep up the good work!

Yes, we can make it aware of renamed admin.php files. I don't think it has anything specific to the config file, but I'll check that, too.

With the research I have been doing lately, I would definitely rank the following very high on my "wish list":

1. Dynamic page titles - I realize that I already have such a mod, but, given my next priority item, it just makes sense to integrate as the meta tag code is close by... Also, with your proven architecture using classes with module-specific code, I can see having a title method within each class to produce that title... wink... wink... (you were probably already thinking the same).

HOWEVER, again from my reading, I would NOT go back to the old style of dynamic titles where it is built strictly upon something like sitename + module name + category + title.... They should be richer in content, user readable, and wouldn't hurt if had a keyword or two. Not only is this one about page ranking, but it is also about click-through rate (CTR). The page title is a very key part of what the searcher sees on the search results... it needs to stand out as being the most relevant hit from their search in order to get the "click".

2. Dynamic meta tags - page description and keywords. Not sure exactly how one would go about doing this one, but it does seem to be an important element of the equation of "substantially similar pages". What I have been reading is that page title and these meta tags also enter in to this algorithm. The reason being is that the algorithms are trying to replicate "relevance to the end-user". They are trying to bring to the top of the rankings those pages which would be most relevant for the particular keywords that the user placed into the search.

3. Dynamic no-index and no-follow - this one is a bit more difficult to explain, but gets back to the "substantially similar pages" issue. One way to combat that is for a page that one cannot help but be substantially similar, for whatever reason, one could, prior to including header.php, set a constant or something that would cause nukeSEO to put either no-index or no-follow or both if needed.

I'll give you an example (but it might be better discussed in a separate forum post). A nukeFEED HTML preview of a particular news topic or category could look "substantially similar" to a search engine to having gone to a particular topic or category. The kicker: they would have two different links to get to the two substantially similar pages.

Seems to me it would be good for the nukeFEED preview for those two (or News altogether) to be able to tell header.php (or the dynamic meta tags of nukeSEO????) to put in the no-index, no-follow.

I have been thinking that I may be able to use ShortLinks for this as I am already searching and replacing by module, but maybe there is a better way.

4. ShortLinks - No, I am not being self-serving. Just thinking that if we believe these to still be important, why not include within the nukeSEO "package" or maybe it is mentioned as another possible component. BTW, I am thinking that I need to revamp it anyways. The old approach was thinking of this, I think, in terms of simplicity of approach and the need to get something out quickly as back then it was a big, big problem. Been cookin' up some ideas for a 2.0 major release... I want to get away from this type of URL: module-function-nn-nn-nn.html where the nn are just plain numbers. It does look like the industry is still considering descriptive URLs, with a keyword or two, to be helpful (don't ever "stuff" though).

5. Additional Tools? - Cannot really offer up much right now, but was thinking maybe the admin area or maybe a wiki or tutorials on other tools out there to help the web master / marketer with their tweaking. I've got a few from one of the books that I have been reading, but have not had the time to really go review them yet. This number 5) is more of a "concept" for the next version.

Oh well, more later I am sure. I've sat here typing long enough... there goes my coding time. lol.

Not sure why but I woke up this morning dreaming of nukeSEO and a bi-lingual site project that I'm working on (English and Polish) - thats really sad I know...

I was thinking....

Why do we only have ONE meta.php ??
If you have a multi-lingual site you are catering for different languages and thus need to provide SEO for those languages.

What I'm trying to say is that if your native language is English but you also speak fluent German and wish to provide bi-lingual services on your site, you are hardly going to use English words for your search criteria if you are German are you?

I'm not sure what the answer is, unless you are using GEOIP technology to to determine where the user is searching from it's going to be hard to determine which meta data to display to which search engines.
I guess the easiest approach is to use multilingual keywords.

It is worth noting that most good search engines will display their homeapge based on GEOIP technology - for example when my wife brought up the Google homepage in Poland on her laptop she was greated with the Polish Google homepage - food for thought.

I agree that multi-language headers are important and have thought about how it could be implemented. But I think it's too much for the next release. Once we have better way to handle the header tags, we can more easily add multi-language functions.