When hyperlinking a noun in a webpage (or in an application), which is a part of a longer text/sentence, should a grammatical article (such as "a" in English) be a part of a link anchor text?
I.e., which of the following is correct from a point of view of native English speaker?
A cat is a mammal.
A cat is a mammal.
I'm not sure if this may vary with a language. In my native language, there are no articles. It may actually be a trivial question for native English speaker.
In carefully edited text, the choice to include the article depends on the meaning. Examples:
I saw a newt yesterday, dark with blue spots. Can anybody help identify it?
— Article not included: the reader guesses that the linked page is about newts in general.
I saw a newt yesterday, dark with blue spots. Can anybody help identify it?
—Article included: the reader guesses that the linked page is about that specific newt.
Sometimes it makes no difference:
—The meaning of “a newt” and “newt” in this case is the same. Regarding usability, the longer form is a bit easier to click, but also a bit more distracting.
Usually an article need not be a part of your link.
Except in the cases when it makes a difference in meaning. Usually it will be a definite article, like "The Times", "El Salvador", "Al Jazeera".
Sometimes you can see Portugal city Porto spelled as O Porto. This is because porto means just "port" in Portuguese, so the city is not just Port, but "The Port".
Strictly speaking, Los in Los Angeles is also an article, but you definitely don't want to exclude it.
For indefinite articles, like a in English or un/une in French, you can treat them as a numerical "one":
one mammal.
Rarely it needs to be together with your main word in a link.
(This is my own hack for English articles as I'm also not a native speaker).
As the search bots don't give importance for this stop words (the, a, an...) you don't need to hyperlink them.
What's Stop Words on Wikipedia:
In computing, stop words are words which are filtered out before processing of natural language data (text). Stop words are generally the most common words in a language; there is no single universal list of stop words used by all natural language processing tools, and indeed not all tools even use such a list. Some tools avoid removing stop words to support phrase search.
Any set of words can be chosen as the stop words for a given purpose. For some search engines, these are some of the most common, short function words, such as the, is, at, which, and on. In this case, stop words can cause problems when searching for phrases that include them, particularly in names such as "The Who", "The The", or "Take That". Other search engines remove some of the most common words—including lexical words, such as "want"—from a query in order to improve performance.
In SEO terminology, stop words are the most common words that most search engines avoid, saving space and time in processing large data during crawling or indexing. This helps search engines to save space in their databases.
I believe that the decision to hyperlink a word never should be related to a grammatic and yes for SEO. Because for a user it doesn't matter if you add on the whole phrase, on click here or on a single word. For them, you must need to be clear that they have a link to another content.
I would encourage including the article: not for SEO, only partially for grammar, but to increase accessibility .... if it's a mouse-based user-base or mobile app where finger-actions are most important. Larger targets are easier to click.
However, for screen-readers, I would encourage not only not omitting the article, but (when possible) allow links to have different first letters.
Screen Readers such as JAWS (what I am most familiar with) allow the user to press a key-combination that brings up a Links List. (In JAWS it's INSERT+F7). Within this list, they can arrow down to find the link they want, or they can navigate by typing the first letter until the one they want is read. So then "mammal" would be preferable to "a mammal" -- there are fewer ones beginning with M, so it makes navigation faster.
Bonus accessibility tip from a bad experience: Don't start link or form-field names with unicode characters such as ✉ or ☖ . JAWS reads the second one as "White Shogi Piece" (that was before the word "Home" in all links on the screen) -- it was the only instance for that character, but a user can't type that! And every checkbox began with ✉ or 📱 to indicate emails or text-messages being sent -- in tables with almost 100 entries! (Again, screen readers use a Select-a-form-field dialog list, which would have allowed first-letter-navigation, if not for these characters.)
