Meta titles and descriptions shape a searcher’s first impression. They should accurately explain the page, match intent, and give the searcher a reason to click.
Step-by-step approach
Place the primary topic naturally near the beginning, keep the title focused, and use the description to explain a specific benefit. Check both with the SERP Preview Tool before publishing.
Practical example
A clear local title such as “Local SEO Services in Delhi | Skyhoora” is more useful than a vague title such as “Welcome to Our Website.”
A SERP preview shows how your title, URL, and description may look in search results. It helps catch unclear wording and length problems before publishing.
Step-by-step approach
Draft the title and description, add the final URL, review desktop-style presentation, and refine the message for clarity rather than forcing every character.
Practical example
A preview can reveal that a long brand name pushes the important service keyword out of view, helping you rewrite the title before launch.
UTM parameters help analytics tools identify where campaign visits came from. Consistent naming makes campaign reports easier to understand.
Step-by-step approach
Add the landing-page URL, source, medium, campaign name, and optional content variation. Test the final URL, then use the same lowercase naming rules across your team.
Practical example
For a LinkedIn summer offer, use source “linkedin”, medium “social”, campaign “summer_offer”, and content “video_1”.
SEO progress usually comes from doing the fundamentals consistently, not from owning the most expensive software.
Step-by-step approach
Understand customer questions, create useful service pages, improve titles and descriptions, link related pages, compress images, maintain accurate business information, and review performance regularly.
Practical example
A local contractor can publish detailed service pages, answer common customer questions, and improve image performance before investing in additional software.
Small businesses can improve search visibility without buying an expensive software stack. The right free tools help you make better decisions, catch technical mistakes, and publish clearer pages.
Step-by-step approach
Check the elements you control: page titles, descriptions, URLs, headings, content quality, internal links, images, and structured data. Use the Word Counter and Keyword Density Checker for content, Meta Title and Meta Description Generators for snippets, and Schema Markup Generator for structured data.
Practical example
A local service business can optimize one service page at a time: define the service and location, write a genuinely useful page, preview the search snippet, compress images, and add relevant schema.
To generate and validate schema markup, choose a type that describes the visible page, supply accurate properties, generate JSON-LD, check existing markup before implementing it, and validate the published URL. A generator produces a starting point, not a guarantee of Google rich results.
This guide focuses on implementation. If you need the terminology first, read schema markup for beginners. Structured data describes entities and their relationships using a shared vocabulary. JSON-LD is a JSON-based way of expressing those descriptions; Google recommends it for supported search features.
Start by checking what your page already outputs
Inspect the rendered page for application/ld+json scripts. On WordPress, an SEO plugin, theme or custom integration may already describe the article, author, publisher and website. Identify that owner before adding a second implementation.
Two connected entities are not automatically duplicates: a WebPage and its BlogPosting can describe different aspects of the same URL. The problem is redundant or conflicting descriptions of the same entity, such as two independent article objects with different authors or dates. Reuse consistent identifiers where your implementation supports them.
Choose the type and collect the properties
Choose a type for what the page actually represents, not for the search appearance you hope to obtain. Use Schema.org’s vocabulary guidance to understand types and properties, then consult Google’s documentation for the particular supported search feature.
The starter types in Skyhoora’s general generator
Type
What it describes
Implementation caution
WebPage
An individual web page
A generic page description does not by itself qualify for a specific rich result.
WebSite
The website as a whole
Do not create conflicting website identities on each article.
Organization
A real organization
Use its actual public identity; check existing sitewide publisher markup.
Person
A real person
Do not invent an author, biography or credentials.
Make a small property inventory before generation: the entity’s name, canonical URL and accurate description, followed by whatever the intended feature requires. Required properties affect eligibility; recommended properties can add useful detail when the information really exists. The field requirements of a generator are not the same as Google’s feature requirements.
For an editorial page, Google’s Article documentation covers Article, NewsArticle and BlogPosting, including authors, dates, headline and representative images. The general Skyhoora starter dropdown does not generate a complete Article object. Use the existing SEO plugin’s article implementation or another appropriately scoped workflow rather than assuming a generic WebPage export is sufficient.
Select WebPage, WebSite, Organization or Person from the starter dropdown.
Enter the Name, complete URL and a description that matches visible information. Name and URL are needed to run the current starter tool; an accurate description is useful even when the form does not enforce it.
Run the tool, then inspect the resulting properties. Copy or download the output only after checking its values.
Illustrative example, not a real business or a tested result: a fictional guide page at https://example.com/guides/image-export/ could have this basic description:
{
"@context": "https://schema.org",
"@type": "WebPage",
"name": "Image export guide",
"url": "https://example.com/guides/image-export/",
"description": "A guide to choosing image dimensions and export formats."
}
This example deliberately contains no ratings, author credentials or claimed search enhancements. It illustrates the syntax and starter properties only. Replace every value with real page information and use the appropriate type-specific properties for your implementation.
Implement through one responsible owner
JSON-LD is normally included in an <script type="application/ld+json"> element in the HTML head or body. Google can process either location. If your WordPress SEO plugin already owns the relevant article graph, configure that existing implementation instead of pasting another Article script into the post.
For a genuinely missing, separate entity, use a supported plugin field or an approved developer-managed integration with a clear scope. Some editors remove script tags, and caches can retain older HTML. Saving a snippet in the editor does not prove that visitors or crawlers receive it. Never put example values into global Organization or Person markup.
Inspect existing markup→Generate accurate JSON-LD→Deploy once→Check vocabulary AND search eligibility→Verify public URL
Syntax, vocabulary and search eligibility are separate checks; all should describe the same visible content.
Validate vocabulary and Google eligibility separately
Check JSON syntax. Look for missing commas, unescaped quotation marks and mismatched brackets. The JSON Validator can help with syntax; correctness alone says nothing about the truth of the values.
Check Schema.org usage. Use the Schema Markup Validator to inspect detected types, properties and relationships. Review warnings in context; do not invent information just to remove them.
Check supported search features. Use Google’s Rich Results Test for Google-supported rich-result types. “No items detected” for a generic type does not necessarily mean the JSON-LD is invalid; it can mean there is no supported rich-result item in that test.
Test the public URL after saving. Confirm the final HTML, canonical page, current values and absence of conflicting duplicates. If the test cannot fetch the URL, investigate accessibility rather than assuming the markup passed.
Valid schema does not guarantee a rich result. Google applies content, technical and feature-specific policies and decides how to display a page. Follow the general structured-data guidelines: describe relevant visible content and provide genuine information, not hidden claims or fabricated reviews.
Common failures to prevent
Wrong type: select the entity the page represents, then consult that feature’s documentation.
Invented required fields: if the information does not exist, reconsider eligibility or the implementation; do not fabricate it.
Conflicting duplicates: identify the plugin/theme/snippet owner and keep one coherent description for each entity.
Markup missing after saving: check the actual rendered HTML for editor filtering or stale page caches.
Outdated information: update markup when the visible author, headline, business information or representative image changes. Do not refresh dates purely for appearance.
FAQ markup added automatically: questions in an article are not, by themselves, a reason to create FAQPage schema or expect an enhanced search result.
Before considering the job complete, record who owns the markup and what should trigger a review. Keep the generated file or settings snapshot for rollback, and recheck the public page after future template or SEO-plugin changes. Google’s structured-data introduction explains the deployment and testing sequence in more detail.
