A score can make a metadata review feel finished before the page is ready. You fill in the fields, the number turns green, and the temptation is to copy the output straight into your site.
Meta Tag Forge is most useful when you read that number alongside the individual checks. Its score summarizes a set of rules applied to the information you enter. It does not inspect the published page, measure search performance, or test whether an answer engine will cite you.
Here is how the current calculation works, why the number can change unexpectedly, and how to turn it into a sensible publishing checklist.
What earns points
Every checklist row has equal weight. A passing row earns one point, a warning earns half a point, and a failing row marked bad earns zero. The tool divides the points by the number of rows, multiplies by 100, and rounds to the nearest whole number.
The basic checks cover the title, description, canonical URL, social image, author and publication date. Some inputs add another row:
- Entering a description adds a check for a few opening phrases the tool treats as filler.
- Entering both a primary keyword and a title adds a case-insensitive check for that exact phrase inside the title.
- Choosing FAQ adds a check for parsed question-and-answer pairs.
The number of checks can therefore change as you work. Two scores are easier to compare when the page type and optional fields are consistent.
A worked example: why 79 can become 81
Imagine an Article draft with a title between 15 and 60 characters, a description between 70 and 160 characters that passes the opening-phrase check, and a canonical URL. Leave the keyword, image, author and publication date blank.
That produces seven checks. Four pass: title length, description length, description opening and canonical presence. Three receive warnings: missing image, author and date. The result is 5.5 points out of seven, which rounds to 79.
Now add a primary keyword that already appears in the title. The new passing row brings the calculation to 6.5 out of eight, which rounds to 81. The page text has not improved; the checklist now includes another passing condition.
If you instead enter a keyword that does not appear in the title, that new row earns half a point. Six out of eight produces 75. Use this change to review whether the title names the right subject, rather than forcing an awkward phrase into good copy just to recover points.
Even an otherwise empty Article form scores 25 because the three missing optional details receive half credit. Treat the individual empty-field warnings as the useful information.
Length guidance has two layers
In the current checklist, titles from 15 through 60 characters pass the length rule. Descriptions from 70 through 160 characters pass theirs. Empty values fail, while nonempty values outside those ranges receive warnings.
There is a small display difference to notice: the description counter uses 155 as its maximum, while the checklist allows up to 160. A 158-character description can therefore show an over-limit counter and still pass the description-length check. Read the text for clarity before trimming it solely to change a color.
These ranges are editing heuristics. Google says title links are shortened as needed to fit the device width, rather than enforcing one fixed title-character limit. A useful title should describe the page concisely and distinguish it from your other pages. See Google’s title-link guidance.
The preview is also an approximation. Google primarily creates snippets from page content and may use the supplied meta description when it is a better fit. Different searches can produce different snippets. See Google’s snippet guidance.
What a passing row still needs you to check
Several checks confirm that a field contains something. They do not establish that the information is correct. A filled canonical URL passes the presence check without the tool fetching that address. An image field can pass without proving that the image exists or suits the page.
Review the destination URL yourself. Confirm the author attribution and publication date against the actual page. Open the social image and check that it is relevant and accessible. Never invent an author or date to complete the checklist.
For FAQ content, review every question and answer. The parser looks for a separator between them, but a counted pair does not prove that both sides contain a useful answer. The score cannot evaluate factual accuracy, completeness or whether the answers appear visibly on the page.
The output deserves its own review too. The current JSON-LD generator represents a filled author field as a Person. If the page credits an organization, the generated markup needs an appropriate adjustment before publication. This is a good example of a passing field that still needs human judgment.
Finish with a publishing review
Use the score to find missing information, then review the page as a reader and publisher:
- Confirm that the title and description accurately describe what visitors will find.
- Check the canonical destination, image, author and date against the real page.
- Review the generated HTML and JSON-LD before adding them through your normal site workflow.
- Keep robots.txt changes separate from page metadata and review them against the site’s existing crawling policy.
- After deployment, inspect the live output and confirm that the intended metadata is present.
Correct structured data can help a search engine understand a page, but even valid markup does not guarantee a rich result. Google’s structured-data guidelines explain that distinction.
The most useful outcome is an accurate page with deliberate metadata and a checked implementation. Let the readiness score organize that review, then make the final decision from the evidence in front of you.