how to verify ownership to Yahoo on wordpress.org blog server

The mischief caused by 404.php template is not a problem for authentication, when I stumbled into Yahoo!'s Site Explorer. To claim your site, you were instructed to place a special file with special content under / of the site. This way, one GET will do and have no problem with customized 404 pages. The latter is pretty common in use for sites managed by a CMS (Content Management System) or blogging servers. I wonder how come the smart engineers at Google decide to do two GET instead...

Once I added the required file on my wordpress.org blog server's / and clicked to continue, the next page asked me to keep the file there for 24 hours, till Yahoo's bots take their sweet time to crawl, literally! To a sharp contrast, Google's webmaster tool authenticates site ownership real-time, and sucks in sitemaps real-time too!

Placing a special file under / is the only way to authenticate your ownership on Yahoo Site Explorer. For millions of hosted sites (blogs or otherwise) whereas content owners don't have access to the /, they'd be out of luck. For now, at least. Hopefully when Yahoo! Site Explorer comes out of beta, they'd come up with a way to authenticate sites whose content owner have content-level access (META tokens, maybe?) instead of file-level access.

In comparison with Google's web master tools, Yahoo's site explorer is so spartan right now. Its own blog hasn't been updated for a few months now. I guess it is real beta then.

trial & errors :: SEO Dave's adSense-spiked themes

It's a God-send when I found SEO Dave's themes for wordpress.org blogs. He spiked some default themes with Google's adSense and optimized the placements. I gladly took his words for it, since he is a SEO consultant by trade.  This way, I can get new sites up quickly w/o laboring on SEO first :)

On a new wordpress.org server I set up recently, I attempted to unzip the five theme zip files obtained from his blog. I was surprised to be prompted to overwrite this file and that file. I said 'None'.  It turned out that only "connections", one of five zip files holds everything under a directory, as expected for a compliant theme package, which is to be extracted under /wordpress/wp-content/themes. No biggie, a little command line bash magic, I got it.

/wordpress/themes.php, the admin page to preview and activate a theme,  now showed all of them. Many, however, didn't show preview screenshots. Some of them even reported errors. Long listing of these files on the server revealed that the permission was too restrictive: 0700 for directory and 0600 for files. The root user's umask is 0022, so I am sure the restrictive permissions came from the theme zip, instead of from my sometimes overly-secure setup on the server. A few find and chmod later, all is well again.

There may be a bug in the original or spiked Blix theme, as it treats any new page as top-level, even if it is specified as child page for the ubiquitous About page. Same parent-child page relationship was handled properly by other themes such as Kubrick.

I posted a comment on SEO Dave's site in hope he may check it out, along with a wish of using Google's search box instead of the default search box.