Med detta inlägg kommer jag troligen att bli illa omtyckt av en stor mängd SEO-människor men jag tänkte ändå ta mig tid att skriva om enkelheten i SEO. Jag har jobbat aktivt med SEO i några år och har kommit fram till en väldigt viktig erfarenhet. SEO är logiskt och enkelt.

När det kommer till SEO är det inte värt att satsa på alla trix och specialtekniker. Det finns egentligen bara två saker att tänka på när det gäller SEO:

1, Content! En sida utan innehåll kan inte rankas som relevant innehåll.

2, Skriv om det du vill synas på, inte allting runt om kring.

För att göra det lite mer detaljerat så tänkte jag ge några exempel.
För dessa exempel så målar vi upp senariot att vi har en sida som ska sälja gräsklippare. Vi vill då främst att sidan skall synas högt upp i sökmotorerna på ordet gräsklippare.

OBS! Nu hårddrar jag alla exempel väldigt mycket. OBS!

Exempel 1:
Vi har domänen snabbaklippet.se där vi har 5 bilder på gräsklippare och ett kontaktformulär. Givetvis kan vi vara duktiga nog att sätta titlar och alt-texter på bilderna för att få in ordet gräsklippare men vi har ändå en väldigt brist på innehåll. Hur skall en sökmotor uppfatta att det är gräsklippare vår sida handlar om?

Exempel 2:
Vi har domänen klippare.se där vi skriver massor om olika gräsklippar modeller, om hur snabba de är, hur billiga de är, hur miljövänliga de är. PRoblemet är just att vi aldrig skriver själva order gräsklippare i någon text. Vi kommer säkert synas bra på vissa modellbeteckningar, osv, men inte på de ord vi inte skriver.

Nu är hela detta inlägg väldigt grovt skrivet och jag kommer säkerligen få brännande kritik från många ”SEO-Experter” men SEO handlar egentligen bara om två saker: Mycket innehåll och relevant innehåll.

Detta gäller såväl själva sidan som länkar till sidan, strukturer, osv. Det finns många många saker att göra för att få ett bra SEO-resultat men alla dessa saker faller under antingen ”Mycket innehåll” eller ”Relevant Innehåll”.

Twitter valde nyligen att gå över helt och hållet till oAuth för att säkerställa requests.

Det är här problematiken uppstår. För att kunna använda Twitter ihop med CodeIgniter behöver man sätta uri_protocol till PATH_INFO. Detta för att kunna hantera GET-requests. För att köra CodeIgniter med NginX behöver man sätta uri_protocol till REQUEST_URI.

För att lösa detta kan man då använda sig av $this->config->set_item(‘uri_protocol’, ‘PATH_INFO’); innan man gör Twitter-authentication.

Benchmark av WordPress med W3 total cache på Apache 2 och NginX.

Alla test har gjorts med mjukvaran Siege med 30st samtidiga anslutningar, och 1 min testtid.

Samt följande inställningar för Apache2:

StartServers          5
MinSpareServers       5
MaxSpareServers      10
MaxClients          150
MaxRequestsPerChild  0

Med andra ord debianstables standardinställningar.

Samma inställningar för php5-fpm som är nedladdat från .deb.
och följande för nginx:
worker_processes  4;
worker_connections  1024;

En standardinstallation av wordpress med den här exempeldatan
http://wpcandy.com/wp-content/uploads/2008/09/postsxml.zip tagen från

http://wpcandy.com/articles/easier-theme-development-with-the-sample-post-collection.html

Resultat för Apache 2 med w3 total cache
Transactions:                    1343 hits
Availability:                 100.00 %
Elapsed time:                  60.00 secs
Data transferred:               5.91 MB
Response time:                  1.15 secs
Transaction rate:              22.38 trans/sec
Throughput:                     0.10 MB/sec
Concurrency:                   25.80
Successful transactions:        1343
Failed transactions:               0
Longest transaction:           26.79
Shortest transaction:           0.05

Resultat för NginX med w3 total cache
Lifting the server siege…      done.
Transactions:                    1886 hits
Availability:                 100.00 %
Elapsed time:                  60.24 secs
Data transferred:               8.30 MB
Response time:                  0.84 secs
Transaction rate:              31.31 trans/sec
Throughput:                     0.14 MB/sec
Concurrency:                   26.22
Successful transactions:        1886
Failed transactions:               0
Longest transaction:           29.90
Shortest transaction:           0.05

Apache 2 utan w3 total cache
(Dödade nästan servern…)

Transactions:                      96 hits
Availability:                 100.00 %
Elapsed time:                  60.26 secs
Data transferred:               0.41 MB
Response time:                 17.44 secs
Transaction rate:               1.59 trans/sec
Throughput:                     0.01 MB/sec
Concurrency:                   27.78
Successful transactions:          96
Failed transactions:               0
Longest transaction:           27.50
Shortest transaction:           3.98

Nginx utan W3 total cache
ransactions:                      90 hits
Availability:                 100.00 %
Elapsed time:                  60.10 secs
Data transferred:               0.39 MB
Response time:                 16.57 secs
Transaction rate:               1.50 trans/sec
Throughput:                     0.01 MB/sec
Concurrency:                   24.81
Successful transactions:          90
Failed transactions:               0
Longest transaction:           21.02
Shortest transaction:          15.08

6 hits som skiljer mellan dem.. men det är fast-cgi implementationen av php som ställer till det, inte Nginx. Vi testar med 20st samtidiga anslutningar istället…

20 samtidiga anslutningar apache 2
ransactions:                      95 hits
Availability:                 100.00 %
Elapsed time:                  60.03 secs
Data transferred:               0.41 MB
Response time:                 11.25 secs
Transaction rate:               1.58 trans/sec
Throughput:                     0.01 MB/sec
Concurrency:                   17.81
Successful transactions:          95
Failed transactions:               0
Longest transaction:           19.36
Shortest transaction:           5.43

testa med nginx..
Transactions:                      97 hits
Availability:                 100.00 %
Elapsed time:                  60.29 secs
Data transferred:               0.42 MB
Response time:                 10.52 secs
Transaction rate:               1.61 trans/sec
Throughput:                     0.01 MB/sec
Concurrency:                   16.93
Successful transactions:          97
Failed transactions:               0
Longest transaction:           14.35
Shortest transaction:           8.82

Ja, Nginx och php5-fpm är snabbare, men php5-fpm är något mer krävande.

Tänkte planera ett nytt projekt där vi benchmarkar en serveruppsättning med Apache2, MySQL, WordPress och W3 Total Cache och en serveruppsättning med NginX, MySQL, WordPress och Varnish. Skall bli riktigt intressant att se resultaten.

Återkommer med mer information när testen påbörjats.

CodeIgniter är ett underbart PHP-ramverk som verkligen är en fröjd att utveckla i. För att få det att fungera i NginX lägger du bara följande rewrite-regel i din vhost konf under Location /:

if (!-f $request_filename) {
rewrite ^(.*) /index.php?$1 last;
}

Sen är det viktigt att du har följande satt:

location ~ \.php$ {
fastcgi_pass   127.0.0.1:9000;
fastcgi_index  index.php;
include /etc/nginx/fastcgi_params;
fastcgi_param  SCRIPT_FILENAME  /var/www/example.org/index.php;
}

En bra jämförelse mellan Drupal, Joomla, WordPress och Plone.

http://tips.webdesign10.com/drupal/about-drupal-311.html

1. Installera Apache och PHP (alternativt nginx och PHP)
2. Ladda ner MariaDB här
3. Starta MariaDB (mariadb kommandon heter samma som mysql)
   $sudo /etc/init.d/mysql start
4. Anslut till din MariaDB
   $mysql -u username -p
5. Skapa databasen du skall använda
   create database drupal default character set utf8;
6. Ladda ner Drupal till din webbroot och följ det vanliga installationsförfarandet

När vi startade Stockholm Next Generation Web så tittade jag runt i timmar efter något nytt CRM-system. Jag hade ännu ej hittat något som gjorde det vi ville men som inte gjorde 10,000 saker över det vi ville. Vi testade vTiger som är ett väldigt bra verktyg men kanske aningen för komplext för ett företag under 10-15 personer. Vidare hade vi erfarenhet av Fortnox som också det är ett väldigt bra system men vi vill hosta vårt eget system och ha full kontroll.

Till slut löste jag situationen genom att installera en Drupal 6 med Invoice-modulen. Invoice-modulen gör inte mycket mer än lägger upp fakturor och gör om dem till PDF men det var en bra grund att bygga på. Efter att ha patchat modulen aningen (stöd för svenska tecken, ändringar i pdf-genereringen, med mera) kändes det som om jag hade ett väldigt basic system att bygga vidare på. Några saker som jag såg som ett krav var möjligheten att fakturera, skapa/visa leads, skapa/visa projekt, dela lite interna uppgifter samt hålla en varaktig skriftlig kontakt med mina kollegor och se vad vi alla gjort inom företaget på senare tid.

Efter några timmars jobb var detta system fött. Genom att använda Drupal + Invoice + Views + CCK var systemet nu klart för använding.

Hade på något ställa i koden på ett gammalt projekt varit lat och/eller slarvig vid något tillfälle och skrivit <?=$variable?> istället för <?php echo $variable ?>. Denna förkortningstyp är ej att rekommendera då man ska använda sig av riktig och bra strukturerad kod. Till min lycka så fungerar inte <?=$variable?> alls i php5-fpm/fastcgi. En liten men bra detalj som tvingar folk att skriva bättre PHP kod.

Vikten av att specificera server-namn är viktigt. Om du pekar example.org mot en apache2 server och surfar till http://example.org kommer detta (om du inte konfat om apache2 själv) att ge samma resultat som http://www.example.org. När man då skall vara lite SEO-petig brukar man göra en 301:a från den ena till den andra. T.ex från www.example.org till example.org. Detta för att undvika att bli betraktad som duplicate content.

Om du då pekar samma domän mot en nginx server som kommer nginx bara att svara på det namn du satt i konfen. Om du t.ex lägger en vhost med server name http://www.example.org så kommer nginx inte att ge samma resultat om du surfar till http://example.org. Den kommer givetvis att svara men som en egen vhost.

Sätt därför alltid båda två som server names för att undvika strul.

Få igång URL-omskrivning i WordPress vid användning av Nginx är lätt. Använd följande regel i din vhost så kommer det att rulla på hur smidigt som helst.

location /wordpress/ {
      index index.php index.html;
      if (!-e $request_filename) {
        rewrite ^/wordpress/(.+)$ /wordpress/index.php?q=$1 last;
      }
}

Du måste även använda dig av nginx Compatibility som ”lurar” wordpress lite i sökandet efter mod_rewrite t.ex.