Meta description - better implementation

colak · 2012-10-02 09:26:57

philwareham wrote:

So I’d rather there was a core description field.

Would that include a meta description for categories, sections and authors pages?

I think that if a meta description field is implemented it should be all encompassing.

philwareham · 2012-10-02 09:30:04

@colak

I guess that would have to be done with a sticky article – how does the <txp:keywords /> tag currently work?

wet · 2012-10-02 09:39:02

philwareham wrote:

So I’d rather there was a core description field.

I wouldn’t mind to add another ‘description’ column for articles but I suspect that this would not satisfy SEO-aware site builders. We’d soon need a field to store the meta “robots” content or OpenGraph tags and what-not. All of these fields fluctuate a lot over time as search engines evolve their requirements and SEOs expand their toolset accordingly; see “news_keywords” for a very recent addition.

Depending on a site’s information architecture, a SEO-aware site builder would need any of these fields for articles, sections, categories, images in a gallery’s details view, as “X-Robots” http header for files, search results, monthly archives, and maybe more.

Which part of these requirements shall we weave into the core, and what would we delegate to implementers?

philwareham · 2012-10-02 09:53:34

Well, the description field can be used for many tasks. I myself need it for the meta description tag and also for Open Graph og:description tag for a start. There’s a fairly good case for it being core.

Robot control meta can mostly be done within page templates for sections, but in the rare case a site needs article level control of robots I tend to use glz_custom_fields to make a <select> menu robots override.

colak · 2012-10-02 09:56:05

philwareham wrote:

I guess that would have to be done with a sticky article – how does the <txp:keywords /> tag currently work?

I am using that for individual articles

<txp:if_individual_article>
<txp:if_keywords>
<meta name="description" content="<txp:keywords />" />
</txp:if_keywords>
</txp:if_individual_article>

As I mentioned earlier, I am also using wet_babble to rename the field to meta_description

philwareham · 2012-10-02 10:21:35

@colak

Clever idea. It’s still trying to fit a square peg into a round hole though I feel – would be better if the function was there already as a core field.

Destry · 2012-10-02 11:58:31

Seems related to another discussion.

For what it’s worth, I think using a custom field is the right way forward, because:

Descriptions are not ‘required’ for seo rankings, and by not catering to them specifically with a dedicated field, we don’t contribute to the misunderstanding about that.
Yet, descriptions are useful, as mentioned by others, for communication in SE results thus becomes closer to real content than information about content (as metadata is). Thus for those who want to use them for content reasons (maybe there’s other use for such descriptions besides expected meta-descriptions), they can treat them like a piece of chunked content. As next…
If the aim, as assumed, was to make unlimited custom fields for other types of content chunks, and be able to define them as textarea fields, and move them into the middle column (where I would want them), then why should a description field be treated any different?
By not having a dedicated field, it’s one less thing in the UI. I suspect more UI elements will appear over time (e.g., markdown filter functionality), so you should be very, very selective about throwing things in there.
Twisties may work to hide things, but they’re still UI elements than can confuse people when they uncover what they don’t need to see.
Instead of creating a Descriptions field since Keywords exists, the logic should be to deconstruct Keywords into an optional/custom field going forward that matches the handling of Description like suggested in #3.

philwareham · 2012-10-02 12:09:54

Good points Destry – maybe this can be covered by the 4.6 core custom fields work. My current gripe starts and stops at having to use plugins to achieve simple tasks.

Destry · 2012-10-02 12:14:49

philwareham wrote:

…My current gripe starts and stops at having to use plugins to achieve simple tasks.

+1. That was my point #7. ;)

colak · 2012-10-02 12:15:21

philwareham wrote:

It’s still trying to fit a square peg into a round hole though I feel

I agree

merz1 · 2012-10-02 14:37:46

Just to give you a hint – my working if/else spaghetti framework – what I use and what I consider to be a good generic meta description solution which works great with search engines.

In header form:

<txp:output_form form="meta_description" />

form=“meta_description”

For my german site
still using the good old txp:chh_if_data – a txp:variable solution using <txp:page_url type="pg" /> would be the modern way to go :)
- TXP 4.6: <txp:page_url type="pg" /> really could output page one optionally, couldn’t it?
- TXP 4.6: <txp:page_url type="pg" /> really needs a language file entry for ‘page’ and ‘pages’ and should use it optionally (How many usage cases for different languages?)
<txp:site_name /> and <txp:site_slogan /> should be fine for a vanilla installation.

<txp:if_individual_article>
<meta name="description" content="<txp:title no_widow="0" /> - <txp:keywords /> © <txp:site_name />" />
</txp:if_individual_article>

<txp:if_article_list>

<txp:if_search>
<meta name="description" content="Suchergebnis f&uuml;r '<txp:page_url type="q" />' (Volltextsuche<txp:chh_if_data>, S. <txp:page_url type="pg" /></txp:chh_if_data>) © <txp:site_name />" />
<txp:else />

<txp:if_section name="tag">
<txp:output_form form="meta_tagtitel" />
<txp:else />

<txp:if_category>
<meta name="description" content="<txp:page_url type="c" /> (Kategorie<txp:chh_if_data>, S. <txp:page_url type="pg" /></txp:chh_if_data>) © <txp:site_name />" />

<txp:else />
<meta name="description" content="<txp:site_name /><txp:chh_if_data>, S. <txp:page_url type="pg" /></txp:chh_if_data> - <txp:site_slogan />" />
</txp:if_category>
</txp:if_section>
</txp:if_search>
</txp:if_article_list>

form meta_tagtitel
(using the recommended txp:tru_tags)

<txp:tru_tags_if_tag_search>
<meta name="description" content="Stichworte: <txp:tru_tags_tag_parameter striphyphens="1" /> <txp:tru_tags_related_tags_from_search wraptag="" break=" " class="" breakclass="" generatelinks="0" setclasses="0" setsizes="0" listlimit="15" cutoff="exact" sort="count" /> (Stichwort) © <txp:site_name />" />
</txp:tru_tags_if_tag_search>

Last edited by merz1 (2012-10-02 14:40:35)

Destry · 2012-10-04 13:04:07

merz1 wrote:

<meta name=“description” content=”<txp:title no_widow=“0” /> – <txp:keywords /> © <txp:site_name />” />

Oh, I like that use of keywords (which I never use otherwise). Clever! When you have lemons, make lemonade. :)

Textpattern CMS

Textpattern CMS support forum

#13 2012-10-02 09:26:57

Re: Meta description - better implementation

#14 2012-10-02 09:30:04

Re: Meta description - better implementation

#15 2012-10-02 09:39:02

Re: Meta description - better implementation

#16 2012-10-02 09:53:34

Re: Meta description - better implementation

#17 2012-10-02 09:56:05

Re: Meta description - better implementation

#18 2012-10-02 10:21:35

Re: Meta description - better implementation

#19 2012-10-02 11:58:31

Re: Meta description - better implementation

#20 2012-10-02 12:09:54

Re: Meta description - better implementation

#21 2012-10-02 12:14:49

Re: Meta description - better implementation

#22 2012-10-02 12:15:21

Re: Meta description - better implementation

#23 2012-10-02 14:37:46

Re: Meta description - better implementation

#24 2012-10-04 13:04:07

Re: Meta description - better implementation

Board footer