sffandom

It looks like someone modified the “header.php” script. You could try reinstalling that and then just building the custom menus. The Twenty Twelve Theme works fine with custom menus but you may have to edit the link anchor text in the menus interface.

What you might want to do is rename the “twenty-twelve” theme directory to something like “twenty-twelve-mod” and then upload/download “Twenty Twelve” again, so you know you have an unmodified theme. That way you can learn the ropes before switching to the modified theme and making changes.

You should be able to log in to your SQL database and change your passwords there. WordPress uses MD5 encryption so if you’re using phpMyAdmin you’ll have to open the WP_USERS table, find your login name, select EDIT on that row, and then type the new password into USER_PASS. You use the pulldown box under FUNCTION to select MD5, and then click on GO to save your changes.

At this point you should be able to login with your new password.

If that doesn’t work your database may be corrupted.

I’m an idiot. You have a canonicalization issue. Your Website resolves to heritagelocksmith.com but you have been sharing http://www.heritagelocksmith.com and those really are two separate URLs even though they point to the same content.

You’ll have to verify this version of the site with Google Webmaster Tools. When you do that, you can set your preferences in Google for this site:

http://heritagelocksmith.com/blog/shop/

Make sure all your internal links use the non-WWW format. Then try the “fetch as Googlebot” tool again.

Put a trailing slash after “blog” when you do the “Fetch as Googlebot”.

Although you may see many Websites doing this, Google recently cautioned Webmasters that they may stop indexing any content that the user does not see upon first loading the page.

Use FTP to upload an unmodified copy of “functions.php” to your site.

Such cross-site scripting could be exploited by a malicious third-party.

It would be safer to create a page on your WordPress site and to embed that page in an iFrame on your parent company site. The visitor would see the entire WordPress page (masthead, menu, etc.) in the iFrame.

You might want to hire a developer to write a plugin for you that has some security to prevent or minimize potential exploitation of cross-site scripting if you really just need to embed a lead gen form on the parent site.

I don’t think that’s a good idea.

I run a number of sites on Bluehost and my first step for improving speed on all of them has been to block rogue robots, which use a lot of bandwidth and resources.

For example, you could install the RENAME WP-LOGIN.PHP plugin and use that to hide your login page from the robots. Then in your .htaccess file add the following code:

<Files "wp-login.php">
Order Allow,Deny
deny from all
</Files>

You could probably dispense with the security plugin after doing this.

If you’re publishing a lot of images you may also want to prevent hotlinks from working so you can also add this code to your .htaccess file:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?YOURDOMAIN.TLD(/)?.*$     [NC]
RewriteCond %{HTTP_REFERER} !^http://([^.]+\.)+YOURDOMAIN.TLD(/)?.*$     [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?google.com(/)?.*$     [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?yahoo.com(/)?.*$     [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?bing.com(/)?.*$     [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?ask.com(/)?.*$     [NC]
RewriteRule .*\.(gif|jpg|jpeg|bmp)$ http://SOMEPAGE/ [R,NC]

Since you are using a CDN a lot of your bandwidth should actually be going through their network anyway, not Bluehost.

Even though you’re using Disqus if you have left a lot of spam comments in the WP database you should delete those.

On large sites it sometimes helps to repair the database and optimize it at least once a month, maybe once a week (depending on how much activity the site sees). Getting rid of a lot of drafts, for example, can clear room in the SQL tables. The larger your SQL database becomes the longer it may take to process some queries.

If you’re not using the “xmlrpc.php” script (such as for remote posting) then it would be a good idea to block that in .htaccess via FILES as well.