Onderweg naar Seoul - deel 1

Een belangrijk onderdeel van onze websites is een goede SEO-strategie. Als developers krijgen we dan ook regelmatig te maken met het toepassen, wijzigen en (geautomatiseerd) testen van de strategie. 

Niks spannends, zou je denken. Aangezien de website meertalig is, is het een kwestie van het juiste vertaalbestand zien te vinden en de tekst aanpassen. 

Als aanpassingen zich opstapelen is het zelfs aantrekkelijk om het onderhoud te laten doen in een simpel headless CMS.

Maar, zoals met wel meer dingen in ons werk, ligt het niet zo eenvoudig. De vraag beperkt zich namelijk niet alleen tot ‘kan de tekst aangepast worden?’. Meestal moet er ook rekening gehouden worden met bepaalde condities. Hieronder noem ik een aantal (fictieve) voorbeelden:

De aangepaste tekst moet worden getoond wanneer zoekfilter X en Y zijn geselecteerd, maar niet wanneer ook zoekfilter Z is geselecteerd! 

Om het nog leuker te maken zijn er regels voor alle pagina’s op de website, niet alleen op de zoekpagina:

Op de detailpagina moeten we een linkblok met dichtstbijzijnde woningen tonen als de betreffende woning zich in stad X bevindt.

Oké, lastig, maar niet onmogelijk. Er zijn genoeg producten op de markt die je - door het plaatsen van een zgn. javascript snippet op je website - controle geven over alle content die de gebruiker te zien krijgt. Sommige hiervan bieden zelfs mogelijkheden om ze context-afhankelijk te maken door je website een set variabelen te laten meesturen (lees: “context”). 

Helaas, ook dat zal niet afdoende zijn. De content die SEO waarde heeft, moet namelijk server-side gerenderd worden, zodat zoekmachines bij hun eerste scan het direct oppikken. Nu zul je zeggen, “maar een reus als Google kan tegenwoordig toch gewoon javascript uitvoeren om je site te indexeren?”.

En dat klopt tot op zekere hoogte ook wel; alleen is uit eigen onderzoek gebleken dat server-side content nog altijd hoger gewaardeerd wordt door zoekmachines dan client-side content. Kortom, aanpassingen doorvoeren zonder onze server-side code aan te raken lijkt dus uitgesloten. 

Dat raakt meteen het volgende punt; we hechten veel waarde aan goede (integratie) tests. Als de regels van onze SEO-strategie worden uitgevoerd door onze applicatie, zullen er ook (geautomatiseerde) tests geschreven moeten worden om te kijken of de regels goed geïmplementeerd zijn, en blijven.

Dat betekent dat de regels zelf toegankelijk moeten zijn voor de applicatie, en met name in onze CI straat. Kortom, de regels zullen net als de rest van onze code gecommit moeten worden in de repository.

Omdat we als developers niet de expertise hebben om te weten welke regels dat zijn, moet er een GUI komen die toegankelijk is voor niet-developers. Deze interface, die inzetbaar zal zijn voor meerdere websites, heeft de naam Seoul gekregen.

Nu we de belangrijkste voorwaarden hebben bepaald is het tijd om na te gaan denken over een oplossing. 

In het tweede deel van deze serie ga ik de specificatie (lees: het YAML schema) laten zien die we hebben bedacht om de diverse SEO-regels in op te slaan en deelbaar te maken met Seoul.

Ook zal ik kort ingaan op de volgende (nog te maken) functionaliteit:

• Live annotaties: mogelijk maken om vanuit de website direct door te klikken naar de relevante regels in Seoul.
• Preview: mogelijkheid om alle aanpassingen die zijn gedaan te kunnen zien werken op de website, zonder dat de rest van onze bezoekers (en Google) er last van heeft. 
• Export: voorgestelde wijzigingen kunnen exporteren naar een Pull Request op Github.

Wordt vervolgd!

Cas
Software Engineer