This is true, except that it clearly isn’t doing the job.
If that’s true, we could add the blurb in a comment by the meta tag and in theory that should solve the problem.
It’s either that or try to persuade these kinds of sites to update their parsers.
Trouble is, most security plugins have an option to hide the WordPress version as some consider it a security risk. And there’s not much we can do about that.
I added 20 or so sites to the BuiltWith Suggest a Technology page yesterday in the hope that it helps them to improve their detection of CP. But if that meta tag is missing, I think it’s still going to struggle.
EDIT - even some themes (Divi) change the meta tag too. Divi changes it to something like:
<meta content="Divi v.3.19.6" name="generator"/>
Perhaps there is nothing to do to change this situation.
What I do know that is a pyschological fact is that humans, unconsciously, are attracted, for the most part, to where the “herd” is or an increasing number of humans is moving. If they are not one of the smaller percentage of humans who are early adopters, they watch, waiting to see where the herd is moving, congregating, before acting. Small interest numbers increase hesitancy. Growing numbers are stimulating. Huge numbers signal a vote of support that moves masses – and then is accompanied by the inevitable conflict that is always associated with “too big.”
That is why an increasing early adopter number is so very important.
Desperate times call for desperate measures. In some cases, I’ve resorted to adding the meta tag manually into header.php, as follows:
<?php global $cp_version; ?>
<meta name="generator" content="WordPress 4.9.12 (compatible; ClassicPress <?php echo $cp_version; ?>)">
But if it still displays as a WordPress site, what’s the benefit?
Also from BuiltWith.
My site is not on the list and it has the word “ClassicPress” 50+ times on the homepage. I call BS on their whole lot of stats regarding ClassicPress.
It also shows as a ClassicPress site. Hopefully, over time, BuiltWith will begin to recognise this as a ClassicPress site.
Absolutely. But if many of our sites are not displaying the meta tag, because it’s been deleted either by a plugin or a theme, then there’s very little else to distinguish between WP and CP at the moment. But I agree that we should not be giving too much credence to the BW stats.
Since the two easiest ways to determine if a site is Classicpress (the generator tag and the Powered by note) tend to be removed from professional sites, I think devising an internal counter is likely the only way we’ll get accurate numbers for another year or two…or however long/short it takes to get the project into the mainstream.
Certainly seems that way.
We collect some stats - @james drags the data out periodically - but getting these kinds of sites to detect cp is great advertising.
If people don’t disable them, the emoji url will tell you if a site is running cp or wp.
How we get these sites to do a better job is another question.
I’m not sure emojis will be a viable indicator given the popularity of this petition. It seems a lot of people want them out.
Yes, this is a tough question.
Maybe we just need to work with them and agree on some specific meta tag? I’d have thought it’s in their interest as much as ours. It’d be interesting to see what response, if any, @BlueSkyPhoenix got from them.
We already provide the correct meta and use it correctly [1], but if people hide it or the site doesn’t understand it…
[1] We’re going through the same problems IE did when it started; eventually people will know we exist and we can set it to what it really should be - just not yet.
That is true. It is also true that the ClassicPress.net website, itself, returns “a wordpress site” on all of the automated systems I checked. I don’t recall IE having that problem when it started. 
Perhaps the easiest solution is to display on the most visited pages of ClassicPress.net, that “several thousand people are using ClassicPress already.” Perch, a sweet little CMS co-founded by well-known Rachel Andrews, is doing this but while they only have about 2K users, they are displaying in the one auto site I had time to check. I glanced at code with Firefox Inspector, didn’t immediately see a meta, decided to stay focused on my work and get back to looking at Perch stat results later.
I would imagine that a good percentage of WP sites don’t show the “generator” tag so if the the likes of BuiltWith are relying on that alone, then their figures will be a guess at best. So they must use other methods.
From the BW FAQ page:
Every website gives off “signals” that they are using a particular technology. We can track these signals and determine if a site is using a particular web technology from it.
In the case of WordPress, they probably also look for things like wp-content, wp-includes, etc. but again, this is no good for ClassicPress.
I was wondering if we could add a comment in the <head>, something like:
<!-- Built with ClassicPress -->
which might then become another ClassicPress signal to BW et al?
Don’t know. Just thinking out loud.
I think the problem is indeed that there is not much on the front-end that differentiates CP1 from WP4.9. So they have to rely on those few clues or else take the “safer” guess and say its WP4.9
I contacted them and said that their Aust stats were way too low. Just had a response to say “Thanks I added a new method of tracking today!”
We will see what happens.
A typical way to detect WordPress is to request /wp-login.php and to look for ‘wp-…’ in public files (e.g. robots.txt). That’s why CP will be recognized as WP in most cases.
I don’t think we should create any specific injections to match the 3d-party detection algorithms because each service can do it in its own way. Meta generator tag is universal, it’s ok. I think the right way is to contact ‘problematic’ services and give them some additional clues that already present. So they can improve their tracking methods on their side.
For example, searching for ClassicPress in /license.txt is rather reliable. This file is public by default and has no theme/markup/hooks dependencies. Average users don’t hide it.
Excellent!!!
Agree with all of this, especially that contacting services and explaining how to detect ClassicPress is better than adding new clues.
/readme.html is another decent option.