Forum Moderators: Robert Charlton & goodroi
Here's a topic I almost never hear discussed - a website changelog. I've been getting clients who don't already do this to begin keeping a changelog for their site. Having a record of what you did (and when) has already proven invaluable in trouble shoooting many times. No more searching your memory (or [shudder] your team's memories) for dates and actions.
The degree of granularity is, somewhat, a matter to be tailored to each situation. But certain things seem to me to be essential. Here's what I recommend as a minimum. I'd like to hear other's thoughts and suggestions
Here's my current "must-log" list:
1. every change to robots.txt
2. every change to htaccess (or Internet Services Manager in IIS)
3. site-wide template changes (especially menu changes)
4. DNS and hosting changes
5. new outbound links
6. ad purchases and run-times
What else belongs there?
[edited by: tedster at 6:37 pm (utc) on Dec. 6, 2006]
Version control software maintains a database of your files. To make a change, you "check out", edit, then "check in". When you check-in you typically supply a comment saying what was changed.
Modern team-based software devleopment would be impossible without version control. The same techniques and tools can be applied to a website.
I believe there is a recent post here on the subject.
Verison control packages have tools for listing what changes were made, comparing differences (with some excellent visual differencing and merge tools now available), for retriving or "reverting" to previous versions, etc.
Popular free, open-source version control packages are cvs and subversion (svn). These should be available on most any Linux system, and are available for Windows as well. There are various options for accessing the database via local files, a server, etc. Basically these are a set of command-line tools, but there are numerous visual tools that build on top of these, including plug-ins for software and web-development IDEs (integrated development environments).
cvs is showing it's age - subversion seems to be gaining popularity rapidly.
For things that not files on your website - no problem - just create text files, spreadsheets, wordprocessing documents, databases - whatever makes sense to keep track of things - and put these in version control as well. Capture it in a file somehow, and then make sure it gets into the version control system.
...
Wow, I just read the above. *I use subversion*. I guess I just found another use for it!
Do the above suggestions for version control software provide a log of monitoring the conjoined effects of those changes?To have a good version control system specifically for SEO I would have thought it would be vital to be matched to the effects.
Put your server logs, Adwords reports, Adsense reports, affiliate reports, etc. in version control as well!
Version control won't analyze this for you - but it will at least insure that the data you need to analyze it is available.
Think of version control software as a wayback machine for your web site. But, unlike the Wayback Machine website that takes a snapshot of your site every few months, it captures EVERY change, and lets you capture changes in anything else you'd like to keep track of as well.
Do the above suggestions for version control software provide a log of monitoring the conjoined effects of those changes?
Most version control systems also allow you to tag a series of files or your whole project. i.e. you should create a tag for each major release but you could also create a weekly tag for instance.
You can revert your entire project back to any of the tags at any time, and it's also easy to compare current changes against the code-base from an existing tag. i.e. if something goes wrong, then a version control system should make it easier for you to pinpoint the source of the problem.
The idea of a version control system is interesting, but to tweak it that it automatically accesses all the data sources (server logfiles got mentioned, but even the site itself) sounds a bit impractical to me.
What I thought about was using an (internal) blog for this type of logfile. It can be easily accessed by team members, and via email-to-blog it can receive automated messages too.
my advice is to make 2 separate pages and set the compression on one of them if you can, use the Google webmasters tools, it's got to be a settings issue.
I did some quick research and their could be a problem, but it's return header based. then the next set might be with java or rss feeds.
I would check your server first and confirm that it's properly installed. then go from their.
Mojomike
Check KW density after modifications.
In addition to all of the above, it is also essential to keep a backup of the configuration files for the addon that generates the URLs. I once made a few seemingly trivial changes to the config and the impacts were not obvious until a few days later.... and I could not remember which of the changes I'd made.
It's not just about config management - I've found that some sort of baseline and a blurb to myself about what that baseline is is important.